Why and how to eliminate render-blocking resources

Why and How To Eliminate Render-blocking Resources Easily

In the early days of the web, the first web pages were built in a simplified version of XML called HTML. White with black text. If you saw a phrase with a blue underline you knew you could click it. If it was purple you knew you had already clicked it.

Life was simple.

These days the HTML is usually the smallest part of any web page. When a browser requests a page, it gets the HTML but then has to part it and download the resources.

  • CSS
  • JavaScript
  • Images
  • Fonts
  • …and other external files needed to provide the user experience

Not all resources are created equal. Some resources that have to be loaded can actually slow down the display of the web page. These resources are called “Render Blocking Resources” and this article will show you a few tactics you can use to reduce the number of render blocking resources on your website and how to apply them manually or using the SiteGround Optimizer plugin.

What Does Eliminating Rendering-blocking Resources Mean?

“Render” is the technical term for “display”. In this article, whenever we talk about rendering, we mean the process of displaying your website on a screen. 

With that in mind, render-blocking is anything that pauses or slows down that process.

In the early days of the web, everything was loaded in the order that it was coded in the HTML. If your HEAD had 5 JavaScript tags that all had to be loaded, compiled, and executed before the HEAD was done then those could potentially slow your site down. This is why we started putting JavaScript tags in the footer, so they wouldn’t stop the page from displaying.

Types Of Render Blocking Resources

Every resource that is loaded into your website has the potential to be a render blocking resource. 

  • If an image is large and takes time to load it is potentially a render blocking resource
  • If JavaScript has to execute in the <head> of your page then it is potentially a render blocking resource
  • If your CSS is large and your page can’t display until it is all loaded then it is potentially a render blocking resource.
  • If you load any resource from another site and that site is slower than yours then that resource is potentially a render blocking resource.
  • If you have a lot of plugins that each have their own CSS and JavaScript files, those are potentially render blocking resources.

In short, anything that you have in your HTML to be loaded is potentially a render-blocking resource.

How Can I Test If My Website Has Rendering-blocking Resources?

There are a lot of tools on the web to show you how your website loads. My favorite ones are these two:

The “Inspect Element” option from the browser:

My preference is for a tool that shows me a “waterfall” display of how my page has loaded. All modern browsers will show you a basic version of a waterfall display. Simply right click on a web page, click on “Inspect”, and then find the “Network” tab.

Once you have that, reload the page. You should see something like this:

Inspect element network tab to eliminate render-blocking resources

The right side of the above image shows the “Network” tab. The little bars on the far right are the “Waterfall” display. They tell me how long it takes to load any given resource. The thin blue line running down the page tells me when the page actually started rendering. So, a lotof my resources on this page load before the page loads, and that’s probably not great. That means on this particular page, I may have some room for improvement.

This view is great when you are just tinkering around but really all it tells you is how fast things load on your computer. That may not be a real metric. For instance, I do all my development locally. How fast things load into my browser from a server running on the same computer doesn’t tell me much at all.

That’s why when I get serious about measuring things, I use online tools like https://www.webpagetest.org/


If you go to WebPageTest and enter your URL, you will get a much better picture of reality. Additionally, you can tinker with the settings to get the exact test you want.

For the most part, I recommend you do the same as I do: 

  • Test desktop first
  • Select a server that is not near where your website is hosted
  • Select Chrome unless you have a specific need for another browser

You can adjust those settings in the “Advanced Configuration” tab.

WebpageTest Tool to eliminate render-blocking resources

Then, click on “Start Test”.

WebPageTest results to eliminate render blocking resources

Now, you get a much more useful waterfall display. It’s a bit small so click on it and it will take you to a larger version. One of the things it will show you is a list of the render-blocking resources.

waterfall display from WebPageTest to eliminate render blocking resources

In this case I have 32 render-blocking resources. Almost all of them are CSS files, the last few are JavaScript files.

JavaScript files are easy to understand but why would CSS files be render-blocking? The page can’t display until it knows all of the CSS necessary to display what is on the screen. Therefore if your site is loading a lot of CSS files and near the bottom of the list is a CSS rule that is used in displaying the first element on your page, then your page has to wait until that rule is loaded before the browser can continue to “paint the display”. This is how CSS can be a render-blocking resource.

How To Eliminate Render-Blocking Resources

Over the years, techniques have come and gone for reducing or eliminating render blocking resources. There are some techniques that have been proven to work. 

How To Eliminate Render-Blocking JavaScript

To eliminate a JavaScript tag from being a render blocking resource, you can now use the DEFER or ASYNC attributes

<script defer type=’text/javascript’ src=’//ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js#038;ver=2.2.4′ id=’jquery-js’></script>

  • DEFER tells the browser to download files as the page is being rendered and execute files in sequential order once the page has finished rendering.
  • ASYNC tells the browser to download files as the page is being rendered and execute files as soon as they are available.

The best of these two is DEFER if possible. This way the display can finish painting and then the JavaScript can execute. As you can see in the example above, I defer the loading of jQuery until the page is painted. Then, once it loads, it will execute. Since jQuery is a large library, deferring it will help the paint, unless my page has something that requires jQuery.

How To Eliminate Render-Blocking CSS

CSS is a little tricky to arrange. When the browser sees a CSS element in the code, it has to reference the rules it has loaded so far and see if it has that rule. If it hasn’t yet loaded that rule, then it has to pause the rendering until that rule is loaded. 

Google has coined the term “critical CSS”. Critical CSS is the CSS that is referenced in the part of the page that you can see when the page displays. For instance, if you have a footer in your page that has a CSS rule styling it, if that footer isn’t visible until your viewer scrolls down the page, then that CSS rule is not critical. 

Google recommends that you pull out all of your critical CSS and put it inline in the HTML. This removes the CSS from being a render blocking resource because the browser has all of the CSS it absolutely has to have to display the visible part of the page.

This is tricky because this means you have to look at all of your CSS and pull out pieces. The best way is to use the Google Chrome Coverage Tool. It will show you the CSS that you are loading that is non-critical (red bar) and critical (green bar)

Chrome coverage tool to Eliminate Render-Blocking CSS

By pulling the critical CSS out and placing it inline, you can remove the CSS as a render-blocking resource.

This sounds easy but in reality, refactoring your CSS like this can be very difficult, as this is an advanced technique.

How to Reduce Render-Blocking Resources In WordPress With The SiteGround Optimizer Plugin

One of the things you can do that doesn’t require you to refactor your code or hand-edit your HTML is to use the SiteGround Optimizer. Even if you don’t host with SiteGround, this plugin will help reduce the render-blocking resources on your page.

There are a couple of things you can do with the plugin

1) Enable Memcached

First, if you are hosting with SiteGround, make sure you go to your Site Tools and turn on Memcached. That’s not related to render-blocking resources but it will really make a difference.

Memcached activation on SiteGround to eliminate render-blocking resources

Next, go to the plugin’s settings menu and select “Frontend”

Now, the settings we are about to play with can mess up your site if you aren’t careful. I recommend changing one thing at a time and then reloading your site (in a different browser). Make sure everything is still working. Then and only then, make the next change. 

2) Optimize your CSS

In the CSS section, select “Minify CSS files”. This optimization is safe and straightforward. It will remove the obsolete empty spaces, new lines, comments, etc from the code lowering the size of your pages.

minify css files with SiteGround Optimizer plugin

Next, Select “Combine CSS Files”. This is probably the #1 thing you can do to eliminate render-blocking resources. Nevertheless, you should use it with caution, as not in all sites might perform the same way.

Combine CSS files with SiteGround Optimizer Plugin

If that works, then also, turn on “Preload Combined CSS”. This will force the CSS to be loaded early in the process so your CSS is there when you need it.

Preload combined CSS with SiteGround Optimizer Plugin

3) Optimize your Javascript

Next, go to the JavaScript tab.

Let’s take the same actions:

  • Minify JavaScript Files
Minify JavaScript files with SiteGround Optimizer
  • Combine JavaScript Files
Combine JavaScript files with Siteground Optimizer
  • Defer Render-blocking JavaScript
Defer render blocking JavaScript with SiteGround Optimizer

Usually, there are many fewer problems combining JavaScript than CSS. On every site I tried it, it worked. That last one is important, it will add the DEFER tag to the combined JavaScript. 

When you’ve done all you can on your test site, you down to 24 render-blocking resources from 32. That’s a really good start.

Your next step on this site is to locate all my critical CSS and in-line it. Then defer all your other CSS. That will remove almost all of the remaining render-blockers. 

Wrap Up

After you’ve picked the low-hanging fruit in speeding up your website:

  • Caching
  • Compression
  • Database Optimization

Then it’s time to start looking at the small tweaks. These are the small tweaks. That doesn’t mean they are unimportant. Remember, search engines have stated that the speed at which our pages load factors into our SEO ranking. If you want to improve your SEO ranking, improve your page load speed. Every little bit helps, and it is even better when you have the right tools to make things easy such as the SiteGround Optimizer plugin, that you can download for free here.

Access email sent!

Sign Up For
More Awesome Content!

Subscribe to receive our monthly newsletters with the latest helpful content and offers from SiteGround.


Please check your email to confirm your subscription.

author avatar

Cal Evans

PHP Evangelist

One of the most admired people in the PHP community, who has dedicated more than 16 years to building the amazing PHP community and mentoring the next generation of developers. We are extremely honored that he is a very special friend of SiteGround too.

Comments ( 2 )

author avatar


Nov 12, 2022

Hi Cal and many thanks for all your contributions (blogs, podcasts, seminars, etc.). I have been using SG optimizer plugin from start and I'm a big fan. Just to let you know about a con, that I found out today, when using either the GTM debug, or when using G tag assistant & G tag legacy; by enabling the Defer Render-blocking JavaScript feature in SG Optimizer, it creates an extra strip with "my.GA.id.tag"+"#038;siteground-async=1 ... In other words, if using GA, the script shows twice. This was not preventing my GA to work, but this is not ideal I think. Perhaps Hristo & team will find a way to fix this in the future. Best, dom

author avatar

Mila Kanazirska Siteground Team

Nov 15, 2022

Hello Dom, we have reported this to our developers, and they will further look into it, thank you.


Start discussion

Related Posts