WordPress started a performance team to improve its Core Web Vitals scores. I read their pagespeed optimization spreadsheet and boy do I have an opinion regarding their performance backlog.
In October 2021, WordPress announced starting a performance team. They even publicly shared a pagespeed optimization spreadsheet of their own. That's quite awesome.
Bad WordPress habits from the past
However, when browsing through their backlog, I see remarks that might not come with the result they want to achieve. Especially as some of them could become a footgun and starting to negatively impact specific metrics. And maybe even overall performance.
WordPress image lazyloading
This already happened when WordPress implemented lazyloading themselves. This did not turn out to be the best strategy as WordPress sites started to lazyload all images. However, you might not want to lazyload above the fold images. A mistake with big consequences from an Largest Contentful Paint perspective.
Unused resource hints
Another example is resource hints. This can be found on their list as well. But it's perfectly doable to achieve good UX results without ever implementing any resource hints. In my opinion, this should not become part of the WordPress core. Maybe you've come across these resource hints without ever being used by the website itself:
<link rel="dns-prefetch" href="//s.w.org">
<link rel="dns-prefetch" href="//s0.wp.com">
<link rel="dns-prefetch" href="//s.gravatar.com">
As long as the community itself isn't involved nor addressed in their performance strategy, I'm a bit concerned if this will actually pay off, or if it will only pay off for those that already are into pagespeed optimization. But if they're really into pagespeed, it's quite likely they turn their backs to WordPress already.
Critical CSS
Critical CSS is the art of inlining CSS in the head section of your HTML document. This can already be done using plugins, and the WordPress performance team wants to implement it in the core.
It does have the potential to improve FCP by 300 milliseconds at the 75th percentile, but this totally depends on device and especially connectivity conditions. Moreover, there are a lot of other factors that could prevent critical CSS from actually being an improvement.
Before, I wrote about whether Critical CSS is a must have, or not. In my opinion, it should not be part of the core.
WordPress' incorrect pagespeed priorities
Images is an ever changing field. And the need for optimizing images really depends on your audience. Some of those optimizations could even be achieved using CDN solutions. Which they feel should not be part of the Core. So why would you make image optimization part of the core, next to some easy optimizations such as resizing and creating responsive images for hero images.
WordPress is putting focus on font loading as well. However:
- Web fonts also is an ever changing area. Remember webfontloader.js?
- then, we started using display: swap;
- and a new method already is supported by Chromium browsers.
Already a first reason to let developers do this themselves. And for developers it's too easy to override font loading behaviour anyway. And some might have their own opinion on how text should behave and thus which strategy should be used. It would not be my advice to priorizite this in the WordPress core performance optimization strategy.
Better WordPress performance ingredients
These just are a few examples of wrong focus and priorities. There are a few ingredients though that will come with a big impact. And I would advice the WordPress performance team to give their current backlog another thought.
Forbid any resources loaded from other domains
Resources served from different domains don't get to benefit from HTTP/2. So, using public domains to embed (icon)fonts or JS libraries will introduce latency in the form of DNS lookup and TLS + TCP handshake. This especially is harmfull within the critical path. Such setup should be prevented, or just removed by WordPress.
Such measure would already prevent third parties from getting a high priority. No exceptions should be made here. Even when third parties claim to be concerned with the performance of your site.
Forbid any non-deferred/asynced Javascript
I know you want your USP ticker or image slider to start as soon as possible. However, perceived performance is more important. And it's ok to just show the first USP or slider image, without already starting the slide animation in the first few milliseconds.
This obviously involves a change in developer mindset and also involves a different CSS approach to prevent layout shifts, but it will boost (perceived) performance and most pagespeed metrics (FCP, LCP, CLS) by a lot.
Forbid large CSS files
Unlike HTTP/1, browsers don't limit the amount of simultaneous requests. So, no need to obsessively merge multiple files into one file. As a matter of fact, the render blocking bottleneck will be as big as your biggest resource.
And with JS out of the way already, this will be the biggest CSS file. Too many CSS files still isn't ideal either. Merging all custom CSS into one file, and leave bigger CSS libraries (such as bootstrap of fontawesome) untouched would be a good start already.
Load JS on demand
Loading JS on demand isn't too hard to implement. At least when the performance hygiene of the rest of the site is ok-ish. As CPU nowadays is more of a performance bottleneck than the amount of kilobytes involved, this will come with great wins towards LCP, but also more JS related metrics such as TTI, TBT (lab data metrics), FID and Page Load (field data metrics).
When JavaScript is only needed below the fold, they should just be prefetched on those pages to then execute them at the right time using the IntersectionObserver API.
Server side caching at the core
To apply server side caching, you need to implement a CDN or install plugins. WordPress obviously values their contributors in providing the community with additional features via plugins. However, implementing server side caching within the core will open up new optimization possibilities. For example, prefetching pages without introducing anti-patterns.
Addressing theme + plugin providers
And then the most important part: any theme that does not comply with the above, should not be allowed to provide the community with themes and plugins. Quite a harsh measure, but this one really is needed if WordPress wants to keep up with competition, instead of falling behind.
Want to be kept in the loop of what they're doing already? Be sure to regularly visit their performance projects page on github.
