Core Web Vitals: How to Eliminate Render Blocking Resources

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.
• When it reaches a point in the site’s code that includes CSS or JavaScript, it will stop to parse that information.
• Once the browser finishes and loads the element in question, it will then carry on to the next part of the site.

At the point where the browser is looking at CSS or JavaScript, no other elements of the site load. This will mean the elements of the site lower down that don’t use those resources won’t load either.

For example, consider a site using JavaScript below the fold to create interactive content. These scripts will sit at the top of your page files, and the browser will look to load your JavaScript before any other content. This can make it look as though your site is slow, when really, you’ll need to eliminate render blocking resources, such as unnecessary CSS and JavaScript. This doesn’t include images though, and you should still carry out typical image optimization.

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

In a technical sense, to eliminate render blocking resources shortens the critical rendering path (CRP.) This refers to the sequence of steps the browser takes to load and render the page. It includes fetching and parsing HTML, CSS, and JavaScript, as well as rendering the content on the screen.

👉 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:

• For scripts, move any critical JavaScript code to an inline <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 👨‍💻
• 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 <script> and <link> – read JavaScript and CSS/fonts – tags with a different process. For instance, JavaScript has a few methods to help you defer parsing, but you’ll likely use one of two options:

• 👉 Async. This lets the browser download scripts while it also renders the HTML. Once the browser downloads the script, it will pause the HTML rendering to execute your JavaScript. You’ll use this for third-party scripts such as ads, analytics, and. trackers.
• 👉 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>

When it comes to CSS, you have more of a manual investigation to undertake. This is because you’ll need to understand what CSS you need to retain above the fold, move them inline, then use media queries to split your styles. Any CSS that remains will need you to use JavaScript to either async and defer it.

You may also want to minify your JavaScript and CSS code, too. Although there are manual ways to do this, you’ll likely get a greater return with automation, especially if you run a WordPress website. However, before we move onto non-technical ways to eliminate render blocking resources, let’s give some attention to how you load fonts.

Loading fonts

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:

• A plugin to minify CSS and JavaScript code.
• You’ll want a plugin that can help you defer JavaScript.

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 async and defer with a lot of power under the hood:

If you want something more well-known, both Jetpack Boost and Autoptimize let you defer JavaScript, with the latter giving you the tools to move critical CSS inline.

Conclusion 🧐

Many of Google Lighthouse’s Opportunities are easy to understand, but there are a few that can be difficult. The ‘eliminate render blocking resources’ Opportunity basically means you need to remove JavaScript and CSS from your HTMLs head section. While you can do this with code, WordPress plugins can help you too. Even better, you may already have the plugins you need within your toolbox.

Do you have any questions about how to eliminate render blocking resources? Ask your questions in the comments section below!