There is a lot of conversation around the efficiency of web sites at the moment, not least due to the impending ‘Core Web Vitals’ changes to the Google search engine algorithm, which are due to make user experience an important factor in how it ranks sites.
There are several strands of improvements that can be made, and one of the major players – and one that can easily trip site owners up – is render blocking. If you have ever run a technical site audit using a tool like Google PageSpeed Insights you may have noticed something to the tune of “Eliminate render blocking resources” marked as a negative against the site. But, what on earth does this mean? Let’s quickly break it down…
What is render blocking?
Rendering is a technical term which, in this context, essentially means “display the web page to the user”. When a user types a web address into their browser, or clicks through from a link, the browser downloads all of the code, styles, images, videos, and scripts which are needed in order to show, or render, the page on the screen. However, several of these downloadable elements can actually prevent the browser from performing this render until they have been fully downloaded and processed and, when this happens, it is known as “render blocking”. The more render blocking your site has, the longer it will take to render, and therefore the longer a visitor will need to wait until they see the web page they have requested. And the longer a visitor has to wait, the more frustrated they will be, and the lower Google will rank the page.
What causes render blocking?
There are a few culprits, but normally the prime suspect is the site styling. The browser always starts by downloading the HTML web page, which contains all of the text content and instructions for downloading all of the page assets such as images and videos.
However, things like the font sizes, colours, the arrangement of the content blocks on the page, alignment etc. are normally all handled by styling files (called CSS, or Cascading Style Sheets – although you don’t need to understand what these are in order to understand why they block rendering) which are downloaded separately. But, until these styling files have downloaded, the browser has no idea how to display the content, and so it waits until the files have downloaded and the browser has processed them before showing anything to the user.
Ideally these styling files will be as small as possible and the delay will only be fractions of a second, but fractions of a second actually do impact the end user. Google certainly will take note of them, and if a competitor site takes fewer fractions of a second, then it is likely that they will be viewed more favourably by the search engine.
The other culprits for render blocking are script files (normally JavaScript) which the browser is told to load right at the beginning of the page load. Again, the browser will likely wait until these files are downloaded and processed until beginning that first render, resulting in further delays to a visitor seeing the web page on their screen. Unlike the styling files, however, there are very few scripts which actually need to be loaded right at the beginning of the page load, as they have no meaningful impact on the page until after it has loaded anyway.
Ultimately, in order to minimise the amount of time your visitors are waiting for your site to load, you need to reduce the amount of downloads that cause render blocking to the absolute minimum.
How to minimise render blocking
What steps you can take to minimise render blocking, and how easy these will be to implement, will depend on how your site has been built, but the first step should be to stop scripts from being render blocking.
If you are using a CMS like WordPress or Drupal, then there are plugins that can help with this, but care needs to be taken to ensure that applying these plugins doesn’t affect functionality, or negatively impact optimisation, in other areas. These plugins, although very cleverly written, also tend to be quite unsubtle in their application, and the way that a website theme or other plugins have been written may mean that unexpected or undesirable results might occur so make sure you test thoroughly before you deploy. Alternatively, if these plugins aren’t available or suitable for any reason, there are manual steps you can take, which I’ll cover a little later.
The more difficult step is to reduce the time the browser takes to download and process the styling. In most cases, the styling required to display every single page on the website is contained within the single file that is loaded right at the beginning of the page load, and every piece of styling information is processed by the browser to determine whether it is needed or not. This means that reducing the styling to only that which is relevant to content that will be displayed on a specific page – or even only relevant to the content within the user’s browser window before they scroll – will have a big impact on the length of time the browser will be blocked from rendering.
Another option is to actually include the styling information in the same file as the HTML, which means that the browser will not need to download anything additional and will be able to immediately start processing the styling information.
Neither of these options are straightforward and will either need some kind of existing theme support for this splitting or embedding, or will require a developer to make changes to the source code for the site.
Do you really need to worry about this?
As with so many of these kinds of optimisations; the answer is “it depends”:
- If you complete a Google PageSpeed Insights test and you are getting a high score already, then you probably don’t need to do anything.
- If you complete a Google PageSpeed Insights test and you want to improve your score, and there are more important things to fix, certainly try to fix those first before looking at render blocking issues.
- If you complete a Google Insights test and render blocking is your biggest issue, then you should definitely consider making some changes. If you have a CMS, investigate what is available to you to fix this via plugins, ask for some development support from a web developer or agency, or (if you know your way around HTML) take a look yourself and see what amendments you can make.
The main thing to remember is that you don’t need to get to the level of having no render blocking at all. Reduce it as much as possible to get the scores you want, and don’t agonise over those last few milliseconds; the likelihood is that they will not make a meaningful difference in the grand scheme of things.
What does this look like technically?
The structure of the HTML in a typical web page looks like this:
<html>
<head>
<!-- styling and some scripts are loaded here -->
<!-- this is the area where render blocking happens -->
</head>
<body>
<!-- this is where all the content for the page goes -->
</body>
</html>A browser runs through this code from top to bottom and executes each piece of information as it goes. It is, of course, a little more complicated than that but, in principle, if the browser comes across a render blocking piece of content as it’s reading through the code, it stops until that render blocking is resolved. So, the aim is to ensure that the browser only stops when it absolutely needs to.
As noted above, in most cases, the most impactful render blocking involves content between the head tags, because all of this is processed before the browser starts to process the content to display on screen. So the first thing to do is make as much of that non-render blocking as possible.
Scripts are the easiest thing to do this with. Adding a “defer” attribute to each script tag will tell the browser to download the script at a lower priority than other files, and to not wait for the file to download before starting to render the page.
<script defer src="/assets/js/site-actions.js">You might not want to do this for all scripts, so do some investigating and see if there is anything which legitimately needs to block the render of the page. For example, if the script changes some content on the page before displaying it to the user, then it should be downloaded and processed by the browser prior to that first render. However, in most cases, this will not be the case.
If the script is doing something simple, then you can also opt to place the code “inline”. This means moving the code from the external file and putting it directly into the HTML file:
<html>
<head>
<script>
document.getElementsByTagName('html')[0].removeClass('no-js');
</script>
</head>
<body>
<!-- this is where all the content for the page goes -->
</body>
</html>Styling, as noted previously, is more difficult. Because the styling needs to be loaded before the web page can be displayed, the browser will always need to process at least a little of it before showing the visitor anything at all. It is possible to do exactly the same as the scripting and add a defer attribute to the styling tag, but this will likely result in the user seeing a version of the page without any styling at all, which is less than ideal.
So, what really needs to be done is for the browser to load and process only the styling that is needed to display the part of the web page the user is viewing and, because of different screen sizes, this is an imprecise art.
One option is to only load the styling needed for the current page, rather than all of the styling for the whole site. Common content management systems like WordPress and Drupal provide tools to do this and so, as long as each module of the site is contained in a separate styling file, the CMS will only load the files that are needed to support the modules used for that specific page.
Another approach is to actually embed all of the styling directly in the HTML page. How your site is set up will dictate how difficult this is, but it could look something like this:
<html>
<head>
</head>
<body>
<style>
.header {
min-height: 80vh;
background-image: url(...);
background-position: center;
background-size: cover;
...
}
.header h1 {
font-size: 3.2rem;
...
}
</style>
<header class="header">
<h1>The site title</h1>
</header>
</body>
</html>If the site is relatively small, and the pages are quite simple, then this can work quite well, but it does have the downside of making every page a little larger. Often things like server-side compression can compensate for this but, if the site becomes large, or there are a lot of different components, then keeping control of the styling can be quite difficult.
The final option is to use a solution like Critical CSS. This combines the best of both worlds; ensuring that the styling needed to render the top portion of the web page is provided within the HTML (and therefore has no real render blocking impact) and loading the remainder of the styling with the defer attribute set.
There are a large number of tools and plugins available which allow this to be done either manually or automatically, but they all work in broadly the same way: a “height” is specified (which represents the maximum height which a user could reasonably be expected to have their browser set to) and the tool or plugin then works out all the styling rules that are needed in order to render the page down to that height.
Using this information, that styling is then bundled up and injected inline into the top of the HTML page.
<html>
<head>
<style>
.header {
min-height: 80vh;
background-image: url(...);
background-position: center;
background-size: cover;
...
}
.header h1 {
font-size: 3.2rem;
...
}
</style>
<link defer rel="stylesheet" href="/assets/css/complete-styling.css">
</head>
<body>
<header class="header">
<h1>The site title</h1>
</header>
</body>
</html>In the example above, the content between the <style> tags is what has been created using the Critical CSS approach, and then the styling for the full page is loaded using a deferred stylesheet link.
This should mean that the header is displayed immediately, with all of the styling intact, and the browser will then load and apply the remaining styling as soon as it can. The potential downside to this is that the user may scroll down the page very quickly and therefore see unstyled content before the browser has completed the deferred loading.
However, if the browser is able to locally cache the complete styling for the page then this should only really be a concern during the first page load of a user’s visit to the site, after which the styling should load almost instantaneously.
In summary
As with so many web performance improvements, there is no one-size-fits-all approach to addressing render blocking, and precisely what can be done will be down to the environment a site is built on, how much of an improvement is needed, and what themes or plugins a site is already using. However, as described above, there are some quick wins that can be made (such as deferring scripting as much as possible) and so a process of progressive trial and error should ensure at least some improvements can be made to any site.
If you’re looking for guidance to help you understand whether render blocking is an issue for your site and identify your next steps, talk to a member of our team today. Having delivered performance improvements for clients such as Dexerto – as well as boosting the scores of our very own website – we can help you identify quick efficiency wins, alongside longer-term performance improvement plans.
