For this post, we’ll look at how to eliminate render blocking resources for both technical and non-technical users. Before that, it’s important to give you context on what this Google Lighthouse Opportunity means and how to test for it.
What it means to ‘eliminate render blocking resources’
Render blocking has a hugely negative impact on your site’s loading speeds. In order to understand why this is (and by extension, what render blocking means) consider how a web page loads:
- You’ll visit a site, at which point the browser begins to render the page from top to bottom.
- Once the browser finishes and loads the element in question, it will then carry on to the next part of the site.
Note that not all resources like this block page render. In fact, what constitutes a render blocking resource can sometimes be complex. It’s better to consider whether a resource is necessary for the first contentful paint (FCP) of a page. If so, it should load first – otherwise, you’ll get a Flash of Unstyled Content (FOUC). Everything else can load later, once the first paint finishes.
How to test for render blocking resources on your site
The quickest way to test for render blocking resources is to jump onto PageSpeed Insights or even the in-browser version of Google Lighthouse. Once you run a test, you’ll want to look at your list of Opportunities further down the report. These are aspects of your site that can improve the experience, but have little to no effect on your audit scores.
Here, you’ll spot a dedicated Eliminate render blocking resources section that gives you a list of resources to investigate:
Within a Chromium-based browser, you can open the DevTools and head to the Coverage tab to see the same information:
Here, you’ll see the various resources that load, and an associated color. Green means the resource is critical to first paint, while red is non-critical. From here, you can begin to investigate.
Why you should eliminate render blocking resources from your site’s loading processes
👉 Optimizing the CRP can improve your page loading speeds and the overall UX. Here’s more information on these benefits:
- First, you get to reduce your page loading speed. What’s more, if you can load the critical elements of a page first, the visitor will have less reason to leave.
- If the first paint only concentrates on critical rendering elements, your content will display faster. This improves your user experience, which is important for the usability of your site. Your site’s experience is more of a factor in modern analytics tools such as Google Lighthouse, so it’s an area you should focus on for better performance.
As such, it should be clear by now why you’d want to eliminate render blocking resources. However, you’ll need to pull together a bunch of different pieces of advice to fix any non-critical render blocking.
A great place to start is Google’s own advice:
Google’s advice on how to eliminate render blocking resources
The Google Lighthouse documentation is a fantastic way to understand what different aspects of a report mean. As such, you should arguably head here first, as you’ll find out exactly what the Google developers want you to do to reduce a metric.
It’s also important to realize that eliminating render blocking resources doesn’t affect your Lighthouse scores in a direct way. Even so, it’s still important to control it, even if you see good audit scores within Lighthouse.
👉 As for what Google suggests, here’s a quick summary:
<script>tag within your page’s HTML.
- It’s the same for any CSS URLs: you’ll use an inline
<style>tag and move critical CSS to there. You might also want to use media queries to split the styles into various files, which will only block rendering based on the user’s device, rather than loading all of the code regardless.
However, we can do more than this to eliminate render blocking resources, especially for WordPress websites. Best of all, you might not need to crack open a code editor either. Next, we’ll look at this in detail.
How to eliminate render blocking resources (regardless of your development knowledge)
Over the rest of the article, we’ll look at how to eliminate render blocking resources. We’ll take a look at some technical front-end tricks and tactics to handing non-critical render blocking, then quickly discuss how you should load fonts – another render blocking resource to note. At the end of the article, we’ll look at the non-technical ways to eliminate render blocking resources using WordPress plugins.
Front-end development 👨💻
Because render blocking resources are common, you’ll have a number of ways to solve these issues with code. You’ll often need to treat
- 👉 Defer. This attribute lets you download a script before it becomes a render blocking resource, and still have it access the Document Object Model (DOM). If you also have situations where consecutive scripts rely on each other, deferring them will be the best approach.
Both of these let you keep scripts in the head of your HTML, yet process them at a more convenient time. You only need a single attribute within your
<script> tag to take advantage of either of these:
<script src="script01.js" async></script> <script src="script02.js" defer></script>
If you choose to load fonts from third-party services such as a Content Delivery Network (CDN,) you’ll often call these using a
<link> tag in the
<head> of your HTML. This will (of course) cause those fonts to be a render blocking resource. What’s more, a typical font will have lots of
@font-face rules – many of which you won’t need. Instead, there are two ways you can combat this drain on your resources:
- 👉 Load local fonts rather than use a CDN. You’ll want to serve file types such as WOFF and WOFF2, and you’ll also need to download the relevant font files. Remember that these will need to live on your site’s server too.
- 👉 Serve system fonts for your site. This approach is our favorite, for a multitude of reasons. For example, the browser will render text in a familiar typeface for the user, and you won’t have to deal with any render blocking.
However, you might wonder why you can’t simply load fonts using async. This is possible, but comes with some risks. Much like FOUC, the main concern here is a Flash Of Invisible Text (FOIT.) This can lead you down a rabbit hole, as you’ll need to employ more code to prevent FOIT. Unless this is something your project requires, we’d recommend you look at other options to load your font files.
WordPress plugins 🔌
The good news is that you don’t need to crush computer science to eliminate render blocking resources. WordPress has plenty of plugins to help in a number of ways. While there isn’t only one plugin to help you, you can mix and match solutions based on your needs.
We won’t need to show you how to install WordPress plugins, as we have a full guide on the subject. Though, you’ll need to know what plugins to install.
There are a few different options to consider:
Unfortunately, you might not find a plugin that can help you defer CSS, as this can be a complex task. Even so, with minification, removal of unnecessary code, and optimization, you can still eliminate render blocking resources. It could be that you already have plugins to help.
For instance, your caching plugin could have the functionality you need. W3 Total Cache, LiteSpeed Cache, and WP Rocket all include this. WP Fastest Cache also provides Google Fonts async, too:
However, a caching plugin may not perform as well as you need, which means you’ll want some dedicated plugins. CSS JS Manager is a little-known plugin that can achieve
defer with a lot of power under the hood:
Do you have any questions about how to eliminate render blocking resources? Ask your questions in the comments section below!
Don’t forget to join our crash course on speeding up your WordPress site. Learn more below: