When trying to improve PageSpeed Insights scores on a website, a common task you will need to do is Eliminate render-blocking resources.
However, neither of these methods are enough to gain a good PageSpeed Score, which is important for SEO.
This quick guide will show you how to Eliminate render blocking resources, improving your PageSpeed grade by a significant margin as a result.
First, let’s explain what a Render Blocking Resource actually is. As detailed by web.dev, it is a:
1) Script tag that:
2) A style tag that:
The next step is to check which specific resources are render blocking. The easiest way to do this is to check the PageSpeed Insights report.
For a more granular analysis, use the Coverage tab in Chrome. Right-click to open dev tools > Sources > Coverage.
For each resource, the blue portion of the bar represents the percentage of the code that is critical and needed to paint the first content on the page. The red sections are code that isn’t required to paint the first content that appears or code that isn’t used at all.
Fortunately, script and CSS files are easy to work with and three proven methods can be used to prevent resources being Render Blocking.
Read on for more information on each of these techniques.
This is the easiest win. If code is not being used, just remove it. Refer to the coverage chart mentioned above and if something is 100% red with no blue sections then that code is not used on the page. A common cause of unsed code is developers downloading the entire Bootstrap and jQuery libraries. Often, only a small portion of those frameworks will be needed and you can customise the build to limit the components that you need.
Be careful though. If you decide to remove the code, make sure it’s still loaded on the pages where it needs to be loaded rather than globally deleting it or parts of your site will break.
An equally simple method is to delay the loading of resources until after the critical elements are rendered on the screen. First, extract any code from the files that is needed to render the critical content leaving only the code that is used for non critical content.
Once that’s done, a few tags just need to be added to the remaining resources. For script tags, just add the defer attribute:
<script src="demo_defer.js" defer></script>
and for style tags add the preload attribute.
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="styles.css"></noscript>
These attributes utilize inbuilt browser functionality that allows it to skip these resources in the initial page load and process them after the critical content has been painted on the screen.
This will also improve FCP which is part of Web Vitals.
When code is inlined, the browser doesn’t have to make additional HTTP requests to fetch the contents so it can be processed immediately to style the HTML on the page. Of the three techniques discussed, this will have the greatest impact to your overall score.
Add an inline style block just before the closing head tag and insert your compiled CSS within:
That's it. This will successfully Eliminate render-blocking resources and remove the warning from PageSpeed Insights. You can leave it here or read on for more details on how we go about implementing this on a technical level.
The change is simple and the results are immediate but it will present two issues that require some thought before proceeding:
We use Larvel Elixer to build our .scss and .js modules as it is a nice wrapper around gulp that allows us to easily inject the CSS and JS into the head by configuring the tasks and running the gulp command.
Hopefully, you have already split everything into modules that are compiled into a single minified JS or CSS file. This will allow you to change the location that they are compiled to from a file to a partial or include that is injected into the head tag.
For reference here is what our Elixir task looks like:
styles.htm is a partial that is then included in the head:
Wordpress sites can benefit from the Autopmise plugin, which does this automatically without any technical work.
If you have individual CSS or JS files that everything is dumped into, pasting the contents into the head tag will work for now but you need to find a way to automate the process to save time and effort in the future.
Impact on users
The second consideration is that user experience may decrease slightly.
As the code is inlined, it cannot be cached and has to be downloaded by the user's browser each time they load a new page.
This was an intense source of internal debate for us as higher search rankings are only useful if users receive a pleasant experience when they land on your site. If pages don’t load in three seconds, users will leave, which will increase your bounce rate and cause more damage than anything a good PageSpeed score can offset.
To settle the argument, we carried out vigorous testing with GTMetrix and WebPageTest before and after inlining the JS and CSS. We found milliseconds of difference in load time from applying this change, which gives us the confidence to inline the assets without worrying about damaging our search rankings.
You have to decide which is more important, Eliminating render blocking resources to boost PageSpeed score or providing a top of the line user experience.
Is This Good Practice?
Most technical guides say that Eliminating render-blocking resources is not important and instead you should focus on serving static assets from a CDN close to the user. Web Performance purists will disagree with this tutorial but the PageSpeed scores don’t lie and with that comes better search rankings.
The results of our tests showed that more data has to be downloaded on each request than loading assets in external files. This isn’t an issue for users on WiFi but if you have a lot of mobile traffic on a 4G connection, the site may consume more of their data than it should, depending on the size of your CSS.
Eventually, this could become an issue for SEO as Chrome dev tools now show the amount of unused code in each request. This suggests Google may be planning to penalize sites that serve bloated responses in the future.
While it isn’t a problem, for now, there is no guarantee it will stay this way forever. SEO is not a set and forget task because the web changes and Google are constantly editing their recommendations for best practice in response. It is not uncommon for them to penalize something that they previously encouraged, leaving website administrators scrambling to roll out a fix.
To demonstrate the impact our changes had, we performed it on one of our client sites, vuelify.com.
Firstly, here are the PageSpeed Insights results before the change:
It already has a decent score because we Serve Static Assets With An Efficient Cache Policy and Enabled Compression on the server
Here are the results after deploying the change and running the site through PageSpeed Insights again:
As you can see, we no longer have the warning to Eliminate render blocking resources in above-the-fold content.
This guide explains at a high level how to remove render blocking resources in above-the-fold content, without going into platform specific approaches.
PageSpeed is important and inlining is a very effective method for improving your score but it comes with side effects. The answer is simple but it’s worth explaining the process and impact it will have on other parts of your application. Hopefully this post offered balanced views from both sides of the discussion so you can arrive at a suitable choice yourself.
If you are interested in Technical SEO, sign up for PageSpeedPlus.com to run Pagespeed Insights scans in bulk across all pages of your website. This will identify how many pages need to Eliminate render-blocking resources to achieve good PageSpeed scores. The best part is scans can be automated so you can set them to run without having to manually trigger things yourself.