How To Fix & Eliminate Render Blocking Resources

More Page Speed Tips
Reconfigure The Loading Process For Speed

Eliminate the render blocking effect of low priority or non-critical CSS, JavaScript and other resources for a powerful strategy to maximize page speed and improve user experience.

Along with more page speed tips, get up to speed with the fundamentals of website performance optimization:

Full Guide

What Is Render Blocking?

If you've run a website loading speed test like Google's PageSpeed Insights, you may have seen an opportunity noted in the test results like "Eliminate render-blocking resources". Avoiding or eliminating render blocking resources altogether is an important strategy to maximize website speed and ace speed tests.

To make the needed changes and get the best results, it can help to take a closer look at render blocking and why it matters.

Render blocking refers to the way some website resources - typically external CSS and JavaScript files - interrupt the loading process while they load and apply to the page.

Conventional, render blocking CSS and JavaScript references look like this:

HTML
<!-- other <head> stuff -->

<link rel="stylesheet" href="styles.css">

<script src="scripts.js"></script>

</head>

When a web browser loads a page and examines the HTML code, CSS and JavaScript files referenced in the HTML are downloaded and applied to the page. Conventional CSS <link> and JavaScript <script> references are considered render blocking because the process of otherwise loading and displaying the page is paused until those files are downloaded and interpreted by the browser.

The result is a delay in the display of the page to the user. Eliminating render blocking resources minimizes this delay so the page can load and display content as soon as possible.

Critical vs Non-Critical Resources

On most webpages, the majority of the total CSS and JavaScript loaded by the browser isn't needed to display only the initially-visible or above-the-fold parts of the page, so it makes sense that these resources should be loaded with appropriate priority.

Eliminating render blocking resources is important for both CSS and JavaScript, but most (if not all) JavaScript can be safely deferred to load in the background and run toward the end of the loading process. CSS however can benefit from an extra step - identifying and separating high and low priority resources and loading them accordingly. This is often also called critical vs non-critical CSS.

Get the full scoop about how render blocking impacts the loading process and how to structure the way resources are loaded to avoid a negative impact on page speed:

Loading Structure

Lean = Fast

The fastest loading files are the files that don't load at all.

Before putting any of these strategies into practice, it's a good idea to carefully review any included resources and make some shrewd decisions about what should and shouldn't be included.

This is often best done by taking a close look at each content element, feature and included resource and asking yourself, "Is this good for the user?"

Underused or superfluous features, plugins and other files can be good candidates for removal or adjustment. For example, while banner-style image rotators can seem like a good idea, if most users scroll past before seeing more than one or two slides, it may not be worth the extra resources. Instead, a single static image with a clear, focused headline may deliver a stronger and more effective message, with less page weight.

Custom fonts can also be a good source of page weight reduction and even an opportunity to refine the design. Custom font systems like Google Fonts make it easy to add stylish and eye-catching text styles and it can be tempting to use them too liberally - at the expense of both tasteful design and page speed. For most applications, 4-6 custom font variants yields a good balance of design style and page speed.

For the resources that remain after a prudent spring cleaning, the strategies below will help limit or fully eliminate the render blocking impact during the loading process.

CSS

Loading CSS styling for above-the-fold content before the page is displayed avoids the unpleasant potential user experience of seeing unstyled content before the CSS is applied - sometimes called a flash of unstyled content.

So how do you eliminate render blocking CSS if it's necessary to properly display the page?

The answer is to separate critical CSS from non-critical CSS.

A typical setup for critical and non-critical CSS looks like this:

HTML
<!-- other <head> stuff -->

<!-- very small file for critical CSS (or optionally inlined with a <style> block) -->
<link rel="stylesheet" href="critical.css">

<!-- async non-critical CSS -->
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.onload=null;this.removeAttribute('media');">

<!-- no-JS fallback for non-critical CSS -->
<noscript>
    <link rel="stylesheet" href="non-critical.css">
</noscript>

</head>

Don't let render blocking CSS resources slow down page speed. Explore strategies to load low priority, non-critical CSS in the background and get the finer points of async CSS techniques:

Asynchronous CSS

JavaScript

Eliminating render blocking JavaScript resources is usually easier than CSS because in most cases little to no JavaScript is critical to the initial rendering of the content on screen.

(Even if JavaScript is used to populate 3rd-party widgets or other features, these typically shouldn't be considered critical and can be loaded in the background without render blocking and then executed slightly later in the loading process.)

The simplest way to eliminate render blocking JavaScript resources is with the purpose-made defer attribute:

HTML
<!-- other <head> stuff -->

<script defer src="non-critical.js"></script>
<script defer src="jquery.js"></script>

</head>

The similar async attribute can be a good option as well, but may interrupt rendering to execute.

Learn the difference between async and defer, how to deal with inline <script>s that are dependent on defer'd resources, plus other tips to streamline the loading process:

Loading Structure

Google Fonts

Custom, stylish fonts are an easy way to add visual interest, establish branding and give your website a unique look, and Google Fonts makes it as easy as adding one line of code to include one or more fonts to the page.

That one line is a <link> reference to a CSS file, which by nature is render blocking. This means that the render blocking effect of Google Fonts can be eliminated with the same asynchronous CSS technique that's commonly used for other non-critical or low-priority CSS resources.

But don't stop there! Combine async CSS loading with the preconnect and preload resource hints to speed up Google Fonts even more:

Async Google Fonts

Google Analytics

Whether you prefer to use the conventional asynchronous snippet or the Global Site Tag version of the tracking code, Google Analytics can also be reconfigured to avoid render blocking and minimize the impact on page speed.

As with other JavaScript resources, Google Analytics can use the defer attribute on the external <script> reference to load in the background without interrupting the loading process. The inline JavaScript snippet can also be moved to a defer'd external file for the same effect.

Eliminate the render blocking effect of Google Analytics with two simple steps:

Defer Google Analytics

jQuery

As with other JavaScript resources, jQuery can be effectively eliminated as a render blocking resource with the purpose-made defer attribute to load the file in the background while the page continues to load.

HTML
<!-- self-hosted -->
<script defer src="jquery.min.js"></script>

<!-- from a CDN -->
<script defer src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>

It's generally good practice to move all inline <script>s to an external file for deferring and caching, but if you can't avoid inline JavaScript and those <script>s rely on a defer'd file like jQuery, the inline content can be wrapped in an appropriate event listener:

HTML
<script>
document.addEventListener('DOMContentLoaded', function(){
    // jQuery-dependent stuff
});
</script>

The inline JavaScript/jQuery will now run immediately after the DOMContentLoaded event and after any defer'd files they may depend on like jQuery are executed and ready.

Loading Structure

From non-critical CSS and low-priority JavaScript to third-party files from Google Fonts and Google Analytics, these steps to eliminate render blocking resources are a great way to streamline the loading process and minimize the impact on page speed.

Refine the loading process even further with strategies like asynchronous CSS and resources hints and other tips to improve page speed. Get started with an overview of HTML structure and how to configure the loading process for speed:

Loading Structure