Wordpress recently wrote about the performance impact of jQuery, but it seems like they are choosing to not call out the real pagespeed bottleneck.
A bit more than a month ago, we already learned that Wordpress is finally going to focus on performance from within the Wordpress core. A good move by core contributors that started kicking of with a Wordpress performance team.
is jQuery to blame for bad performance?
Before kicking off with a performance team, an article by another Wordpress contributor got shared on make.wordpress.org. And it's actually telling us that either Wordpress it too shy to call names or isn't aware of what really is impacting performance.
The performance impact of using jQuery in WordPress themes
In the article, we can read about jQuery being a performance offender and not being needed anymore. Not gonna argue with jQuery nowadays not being needed anymore. And any JS that isn't used, is good JS.
So, why is it still being used by WP, but actually also non-WP sites? The answer obviously applies to any framework that becomes redundant in the eyes of others: jQuery just still exists due to technical debt or (third party) dependancies. However, the conclusion of the article is not as nuanced as it should've been.
Fast websites with jQuery
To support this:
- without jQuery, people would still want to introduce the same website features, needing them to still use JS libraries. Preventing them from using jQuery might just mean that's one JS library down. But maybe developers end up using other dependancies instead;
- So, it isn't about jQuery, it's about how it is used. This can be supported with (real) UX data as well.
The following is a screenshot of 4 websites that have a sufficient amount of pageviews to get Core Web Vitals data. The screenshot depicts the mobile FCP metric and its distribution per domain.
For those with a sharp eye: this screenshot was taken prioir to the recent PageSpeed Insights layout change. But the more important part: All sites are having an optimal FCP metric, as each of them is below 1 second. Google's recommended FCP threshold actually is 1.8 seconds, so this means these all are very comfortable.
And guess what: the above websites are all using jQuery. These are just the FCP metric, but additionally they all pass the desktop + mobile Core Web Vitals assessment as well.
A bold claim
So, jQuery isn't the bottleneck here, but it is when being part of Wordpress. Does this mean I could claim WordPress is the real bottleneck?
Such conclusion would be as simple and incorrect as the one in the article. The article lacks elaborating on the fact that it's the developers that don't know what they're doing. Or actually Wordpress that is allowing them to use jQuery in a harmful way.
Nuancing the article
To be fair: the Wordpress article discussing jQuery is always talking about jQuery in relation to Wordpress themes. And it could very well be that the jQuery issue is more severe when used in Wordpress themes. However, the article unfortunately refuses to call out the real bottleneck.
The real Wordpress + jQuery bottleneck
Pagespeed and performance often is more nuanced. But the article might give you the feeling that jQuery is a big culprit. I've got a different view on the matter.
Both the Wordpress core as well as the knowledge of people (both theme vendors + agencies) using Wordpess should be questioned even more than jQuery. That should've been emphasized too. But this would obviously be a bit too harsh towards your own community, so no one is going to write that down on a Wordpress community website.
Difference in pagespeed knowledge
Don't get me wrong though: There are very good Wordpress agencies out there, but due to the easiness to get started with Wordpress website- or theme-selling business, average Core Web Vitals numbers are lacking behind. This is because browser, pagespeed and performance knowledge isn't the same across al those Wordpress agencies and theme builders.
That's where the real challenge is. If someone would mess up repairing your teeth, it's likely you would blame the dentist or how they are using a tool, instead of just the tool itself. Basically the same also applies to PWA. It's not the technology that will make or break technical UX. It's about how it's used.
Their article is at least raising awareness regarding jQuery usage. That's good. But the community should've been actively addressed as well to really get them involved. Now everyone will just wait for WP to make a change and other theme + plugin contributors nor web development agencies might get to learn they should do a better job themselves as well.