Like it or not, Google is the unlikely champion of website speed. By integrating CWV speed and usability metrics as ranking criteria in the SERPs, platform creators are finally starting to take the issue seriously. As a user and fan, WordPress often frustrates me with their lackadaisical approach to speed issues. For the longest time, WordPress casually injected jQuery scripts into the header. They even added their bloated emoji script, which a lot of us had to remove manually.
Add to that, there was no in-built support for inlining critical JavaScript. Wholesale loading of entire CSS libraries just to accommodate a few style elements shows that speed simply hasn’t been on WordPress’ radar. I’d written in the past about how WordPress needs to do more for speed. Well, it looks like WordPress heard the feedback. WordPress engineers are now conversing with Google for ideas on how to implement basic speed techniques.
Changing it Ourselves Isn’t Easy
If you read the Google documentation on how to fix speed issues on your site, you’ll see suggestions that you simply can’t implement if you’re an ordinary WordPress user without the help of plugins. For example, inlining critical CSS is a great idea. But it’s not an option for WordPress themes out-of-the-box. If you didn’t want to add another plugin to your site, I posted a workaround for inlining CSS using a “code-only” approach.
But these techniques are way out of the reach of most users who just want a solution that “works”. The max they can do is install a plugin.
But Plugins Contribute to the Problem
The key problem here is that WordPress’ strength – a huge selection of plugins – is also its weakness. Plugin authors load JavaScript and CSS in the <head> element willy-nilly and make copious use of jQuery (also in the head). Solving this will be incredibly hard without breaking backward compatibility. You want to keep existing sites working. But for that to happen, plugin authors will need to update their problematic plugins. And if development is abandoned, it will never occur.
A New WordPress Performance Team
Some WordPress contributors are now pushing for a separate performance team with participation from Yoast and Google. Why Yoast? Earlier this year, the Gutenberg engineer Riad posted a big data analysis of how plugins affect the Gutenberg editor speed. This doesn’t impact end-users as much as it does writers and contributors. But it’s still important, and Yoast wants to reduce its speed footprint.
First Step – Name the Offending Plugins and Themes
The first thing WordPress can do is to implement a system where it shows us which plugins are making our site unhappy by adding JavaScript to the head and making use of front-loaded jQuery. Once we have that information, website owners can do a cost-benefit calculation to see if the plugin is worth it, and/or pressure the author to make changes.
I think providing this transparency will go a long way towards fixing the problem. WordPress could also give plugins a “speed rating” where they change the color of the rating from green to red depending on how severely it’s misbehaving.
Performance Framework for New Plugins
The next step will be to provide plugin authors with a framework for new plugins where the approach is more structured. The idea is that we want all plugins to defer their JavaScript, and perhaps specify which CSS should be inlined. We’ll have to do this in a way that doesn’t make plugin development harder, to not scare away new plugin authors.
The road ahead will take a lot of work, but it must be done. It’s way past time for WordPress to take speed seriously, and now with competing platforms improving their CWV metrics, this is a task that can’t be deferred (pun intended!) further.
