Why and How To Eliminate Render-blocking Resources Easily
Table of Contents
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:

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/.
WebPageTest:
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.

Then, click on “Start Test”.

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.

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.
Comments ( 2 )
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through
Dom
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
Mila Kanazirska Siteground Team
Hello Dom, we have reported this to our developers, and they will further look into it, thank you.
Start discussion
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through