Probably the single most common “opportunity” you’ll get when testing your WordPress site using PageSpeed Insights (or Web.Dev) is the infamous “eliminate render-blocking resources.”
And how scary does this sound:
According to Google, If you’re not loading 90% of the content on your site in 100 ms or less, there’s nothing for users to see and it creates a poor user experience. (wp-rocket.me)
Let’s get into this.
- What are render-blocking resources?
- Three Steps to Eliminate Render-Blocking on a WordPress Site
And before I dive into the article, if you like the content you see on WP🐹, please consider subscribing below. No spam, I promise. Just me casually sending you an email when I create something new (or have some crazy idea I’m excited to share).
What are render-blocking resources?
Rendering is when the visitor's browser is downloading and "painting" the layout/design of your page in front of the reader. Those articles you write, the blocks of paragraphs, headings, etc... they get streamed to your reader and put on their screen.
The browser compiles all the styles (CSS), HTML, scripts, and media to show your page to your reader.
Obviously you don't want anything to slow that down, or interrupt the visitor's experience on your site -- and render-blocking will do that.
Render blocking can also cause search engine optimization (SEO) issues for your articles if Google's new web vitals report considers your site slow.
According to John Mueller's answer in a Google Webmaster Help thread, anything over 2 seconds is considered too slow. (premium.wpmudev.org)
Plus you'll have the addon problem of a lower conversion rate too. Nobody likes a janky site.
What exactly is render-blocking?
When something needed to render your page on the reader's browser doesn't load quickly, or when something not needed during a render is loaded -- it's considered render-blocking -- and is a problem for both performance and user experience.
In other words, it's interrupting your reader's user interface because their browser will take longer to show your page to them. They may see parts of the page loaded but other parts taking a long time. Or the whole UI will be "stuck" while assets like style sheets and scripts download.
You've likely experienced this before yourself, especially on mobile.
Perhaps I can better explain this with a quick explainer video:
Images are not render-blocking
I'd like to point out, while images do add a tiny bit to the DOM (described below), they are not render-blocking. But it is vital to optimize images for a high-performance website.
Alright, with that out of the way, let's move on to the three steps you can quickly go through to improve your site performance and cure your render-blocking ailments.
Three Steps to Eliminate Render-Blocking on a WordPress Site
Now we get into the meat and potatoes of this guide. In the next few sections, I am going to show you how to begin eliminating the "eliminate render-blocking resources" message from Pagespeed Insights (aka Web.Dev). And although you'll probably never completely win this battle, you can make it so minimal it doesn't matter.
1. Eliminate Unnecessary HTML Elements
HTML elements are the paragraphs, headings, containers, sections, images, etc... the come together to form the Document Object Model (DOM).
A verge large, deeply-nested DOM can cause some minor rendering issues, especially if there are scripts on your site manipulating the DOM.
Now I will admit, this is a minor optimization. It will really depend on your situation — I simply wanted you to be aware of it. If you have a script heavy site this becomes more important.
Avoid page builders
Really there are a couple of reasons to avoid page builders if you are seeking to build a very fast website.
First, they often load a whole bunch of extra style code that may not actually be used. For example, button styles when you don't even have a button on the page.
Second, they typically add lots of extraneous HTML "wrappers" that adds complexity to the DOM -- and the more complex the DOM the longer the reader's browser will take to render it.
Particularly when there are scripts using the DOM.
But as I mentioned at the start of this section, this is a minor win. Browsers are so fast you probably won't have to worry too much about this -- especially if you are not using a page builder.
Use a quality theme
The theme can make or break your efforts to reduce the DOM size. You could spend all day scouring your articles to remove unnecessary nested elements, etc... but if your theme is poorly built, you'll still have issues (minor issues... there are some bigger fish to fry later in this article).
A very high-quality theme I always recommend is GeneratePress. You can't go wrong with it -- and their support is fantastic.
2. Load Critical CSS First
Critical CSS, if you watched the video above, is precisely the CSS needed to render the initial view the reader sees on your WordPress website. Nothing more.
In fact, if any other CSS loads that is not needed in the initial render, it is considered render-blocking.
This is where it gets tricky. Each of the pages on your site will likely have different critical CSS so it is difficult to create the critical CSS once and be done with it.
There are tools out there to help. Many caching plugins like WP-Rocket or Litespeed Cache have the ability to generate the critical CSS for you.
But there is a catch, you have to enable asynchronous CSS at the same time. Which means the CSS loads separately (albeit quickly). Instead of render-blocking you could end up with a Flash of Unstyled Content (FOUC).
You know you are experiencing the FOUC when the page loads a white background with text and other things not seemingly styled at all.
That's essentially the browser using the default browser style to render the first paint -- until your site's CSS loads to re-style it.
Google's new web vitals rule "Cumulative Layout Shift" will also let you know if your readers are experiencing the FOUC issue. If you see something other than zero, and you know you are attempting to use critical CSS, there could be a FOUC issue.
Here's WP🐹's cumulative layout shift score:
Zero is exactly what you want -- but I don't use critical CSS, I accept the fact there are a few kilobytes of render-blocking CSS. Plus, my theme, Bear Metal, reduces the CSS size so much that I don’t need to worry about it.
But some are!
This means you should test it. Set everything to deferred, then go back to your site. If something doesn't work, stop deferring scripts until you find the ones that need to be loaded initially.
Yes, it can be time-consuming.
Watch out for jQuery
A big hint though, jQuery is often the culprit when you have JS errors after marking everything deferred. Stop deferring jQuery first to see if that clears up your issues.
Here on WP🐹 my JS optimizations look like this in the Litespeed Cache plugin (at the time of writing this):
My scripts are minified, combined, and being deferred -- except for jQuery. This is probably the settings you'll use as well (though you may choose to not combine them either).
As you can probably tell I kind of nerd out about WordPress/web performance. There’s just something artistic almost about a really fast loading website, versus an overly designed experience.
both have their places, but for a site like mine where I am giving you information, guidance, and tips – do you want the content as quickly as possible.
I imagine you care much less about just how beautiful the page looks, as long as it looks good enough while you’re getting the content you want.
I hope you found this guy helpful and take some of the advice back to your site to make it load faster for your readers.
Stay tuned as I develop new WordPress plug-ins, themes, and more guides to help you improve your site in the future.