Just last month I was complaining about how WordPress needs to do more on Core Web Vitals. While the Automattic team has included several changes to speed up WordPress over the years, it’s obvious that it was never an overriding concern. Otherwise, they would never have decided to include a huge CSS styles file for every single block regardless of whether it was used or not! But with Google now saying that performance on this metric is linked to ranking, they have little choice but to make it a top priority.
And just like that, they are delivering in a big way. Here’s how.
Bulk Loading of CSS Styles
If you’re like me, you constantly check your speed metrics on sites like web.dev and others. Even though these don’t accurately measure your website’s performance, they can give you valuable information about your structural problems.
These are issues that can’t be solved by solutions like caching. So even though NameHero uses Litespeed servers with in-built caching, you can still suffer because of the way your site is coded. One of the issues I’ve had ever since I started using a CMS like WordPress way back in 2008, is the inclusion of styles that are almost never used. For example, here’s a screenshot of the web.dev report for my site WP-Tweaks:
You can see that the vast majority of my CSS styles are unused. Out of 22.3 KB, only 4 KB are used for stuff actually on my site!
It’s Not the CSS Size that Counts
In modern web browsers, a wasted 18 KB of data is practically nothing. When your download speed is several Mbps, it makes little difference that you’re downloading a bit of extra CSS. So what’s the big deal?
The real problem comes because of the browser rendering time. It takes a lot of computing power to sort through all the unused styles and compute the values for only those which your site uses. This browser execution time slows down your page and the subsequent rendering. So it’s not bandwidth that’s the bottleneck.
Gutenberg 10.1 Takes on Bulk CSS Loads
Prodded on by the community, the WordPress team has finally decided to improve the way the Gutenberg editor loads styles. The changelog for 10.1 includes the following quote:
Improve loading method for block styles
A bit of digging leads to a pull request from September 2020, where the idea was first introduced to separate out the various CSS styles for blocks in Gutenberg and only load the necessary ones. This is dovetailing with the effort to make WordPress an FSE platform – meaning Front End Editing. The idea is to eventually allow users to deploy blocks not just in their post and page content, and but also in the header, footer, and other places that were previously accessible only to themes.
It appears that WordPress might soon be competing with actual page builders like Elementor and the like! And one of the requirements down that path, is to speed up the rendering by loading CSS styles selectively. Good for us!
WordPress Is Evolving with the Times
Back in 2019, I’d given an opinion on why WordPress will remain the dominant CMS because of its strong financials and open-source nature. I’m happy to know that WordPress has responded so quickly to the gauntlet thrown down by Google regarding page load time. This shows that the Automattic team is keeping their ears very close to the ground, and they have a strong vision for what WordPress is going to need in the future.
For WordPress geeks like us here at NameHero, it’s about to get very exciting!
I’m a NameHero team member, and an expert on WordPress and web hosting. I’ve been in this industry since 2008. I’ve also developed apps on Android and have written extensive tutorials on managing Linux servers. You can contact me on my website WP-Tweaks.com!