Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance - wp admin ***/analysis.js = 450kb*** #14778

Open
wpsumo opened this issue Apr 7, 2020 · 7 comments
Open

Improve performance - wp admin ***/analysis.js = 450kb*** #14778

wpsumo opened this issue Apr 7, 2020 · 7 comments

Comments

@wpsumo
Copy link

wpsumo commented Apr 7, 2020

Is your feature request related to a problem? Please describe.

Found out that the analysis script loaded in the editor and wp-admin is 450kb. It’s huge, and for reasons take time to load slowing down wp-admin.

Today there are many competitors to Yoast having a much slimmer framework. Please consider improving the performance as well. I wish to stay with Yoast.
450kb
/wp-content/plugins/wordpress-seo/js/dist/analysis-1341.js?ver=13.4.1

197kb
/wp-content/plugins/wordpress-seo/js/dist/components-140.js

Yoast also loads a lot of ofter scripts with a total footprint of +550KB.
I don’t know what all scripts are doing and needed but I assure it can be optimized. Sounds to me some things don’t need to load if features as content analysis etc is disabled.

Does the wp-seo-structured-data-block-1341.js need to load if not used? Even if Yoast Gutenberg block is not defined as an allowed_block with the filter?

add_filter( 'allowed_block_types', 'custom_allowed_block_types' );

As I see there is a lot of room for improvements to not bloat wp-admin and to slim the code down for users to unload assets that aren’t enabled/used.

Describe the solution you'd like

By disabling Yoast wp-admin page edit loading time dropped down 2.4seconds, worthy o mention how big footprint Yoast has on wp-admin.
Running a stable tuned server so the host and server is not a problem here, just want to make that clear and that I want to keep using Yoast, but performance and backend and keep on getting slower and never considered a cleanup and “slimup”.

Maybe code-splitting instead of loading high chunks of 450kb js would be a great idea. What is even in all those lines of javascript? I can't imagine how a seo plugin could need that much js to be loaded to do what is necessary on edit and publish a page. But explain to me if I'm missing something.

As far as I know, not even Gutenberg needs that much js.

Why do you think this feature is something we should consider for the Yoast SEO plugins?

Ther are other SEO plugins for Wordpress doing a great job with more features with less impact of wp-admin performance and smaller footprint.

Read below, it's great but it's targeting server-side related improves. I'm targeting wp admin and files here.
https://developer.yoast.com/upcoming-release-yoast-seo-14-0-indexables/

@wpsumo
Copy link
Author

wpsumo commented Apr 28, 2020

@Djennez thanks, just to follow up if there is any reply to my ticket or discussion. Have no idea how Yoast effectively can need and use 450kb javascript in wp admin/edit?

@wpsumo
Copy link
Author

wpsumo commented Sep 7, 2020

Any feedback on this?

Just see here from your competition:
https://theseoframework.com/changelog/4-1-1/

In this major-minor update, we improved browser performance by up to 99% (not a typo) by exchanging over 300 jQuery calls for vanilla JS ones. We also added two new options for oEmbed, freed a dozen bugs that got stuck in the UI and generators, and improved accessibility.

Performance:

  • Up to 99% quicker browser rendering times and interaction (admin-area):
  • Yes, 99%; because there’s a cache pollution bug in jQuery (in combination with Safari’s WebKit) we no longer interact with.
  • We exchanged jQuery event handlers for native JS in various places, improving browser load time drastically (even further than v4.1.0 did).
  • This also improves compatibility with non-jQuery driven APIs.
  • We exchanged jQuery NodeList handlers for native JS in various places, improving browser load time drastically.
  • This also resolves an issue where jQuery’s cache was polluted for unknown reasons (good luck debugging jQuery’s code), in combination with ACF Pro’s Flexible Content types, where the browser could hang for several minutes.
  • We reduced the number of events marginally by exempting hidden fields from change listeners.
  • Up to 0.2% faster server response times (admin and front):
  • We looked at the PHP engine’s code and found that we could reduce the number of opcodes (CPU instructions) by adding backslashes to various internal PHP functions.
  • 0.2% isn’t much. We spent (wasted) 14 hours on that. However, sometimes scrutiny really pays off, as was shown with the 4.0 and 4.1 releases.
  • Nevertheless, we believe this will translate well into the PHP 8.0 release, especially on servers where the upcoming JIT compiler is implemented.

@Djennez
Copy link
Member

Djennez commented Nov 2, 2020

I believe 14.2 has introduced some changes that should have lowered the impact of these files somewhat.

@wpsumo
Copy link
Author

wpsumo commented Nov 2, 2020

Only db and sql related not releated to static assets.

@Djennez
Copy link
Member

Djennez commented Nov 2, 2020

I meant 15.2, but the changes are in 15.1 and 2 I believe. Several resources have been split into separate files.

@wpsumo
Copy link
Author

wpsumo commented Nov 3, 2020

Not much of a difference you still run huge scripts for a reaosn I don't understand. If i don't need Yoast to scan content etc I could most probably cut 95% of all scripts used.

@Perytons
Copy link

Facing the same problem, but for me the analysis.js file size is 750KB and adds 650msec to site load time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants