Editor’s note: This article was updated by Timonwa Akintokun on 23 April 2024 to include information about using CMS plugins and efficiently managing third-party scripts and resources, as well as to provide some practical steps to execute the strategies explored in this article.
What are render-blocking resources?
Render-blocking resources are static files, such as fonts, HTML, CSS, and JavaScript files, that are vital to the process of rendering a web page. When the browser encounters a render-blocking resource, it stops downloading the rest of the resources until these critical files are processed. In the meantime, the entire rendering process is put on hold.
On the other hand, non-render-blocking resources don’t postpone the rendering of the page. The browser can safely download them in the background after the initial page render.
However, not all resources that the browser deems render-blocking are essential for the first paint. It all depends on the individual characteristics of the page.
There are best practices you can use to turn these noncritical render-blocking resources into non-render-blocking ones. Besides, you can also decrease the number or size of render-blocking resources that are still critical and can’t be eliminated.
In this article, I will review the top tips and tricks for eliminating render-blocking resources.
Why eliminate render-blocking resources?
If you reduce the number of render-blocking resources, you can shorten the critical rendering path and reduce page load times, thus improving the user experience and search engine optimization.
There are three ways to reduce the number and impact of render-blocking resources:
- Make them non-render-blocking resources by deferring their download
- Decrease the total number of render-blocking resources using techniques such as bundling (this also means fewer HTTP requests)
- Reduce the size of a resource via minification so that the page has fewer bytes to load
Render-blocking resources and Core Web Vitals
Even though the elimination of render-blocking resources has always been an important performance optimization technique, Google’s Core Web Vitals performance metrics make it even more important.
Since Core Web Vitals are included in Google’s search algorithm, you simply can’t ignore them if you want your site to rank highly in Google. Render-blocking resources can negatively impact the Largest Contentful Paint (LCP), one of Google’s three Core Web Vitals. The other two are Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP).
LCP measures the rendering time of the largest image or text block that’s visible in the user’s viewport. If your critical rendering path is too long — in other words, if you have too many render-blocking resources, or the files are too large — the largest content element will take longer to load.
So, for a better LCP score, it’s recommended to keep the number and weight of your render-blocking resources in check.
Types of render-blocking resources
As a rule of thumb, the browser treats everything it finds in the <head> section of an HTML page as render-blocking. This includes:
- CSS stylesheets
- JavaScript files added in the
<head>section - Fonts added from either CDN or a local server
- HTML imports (even though HTML imports are now obsolete, you might still encounter them on legacy pages)
Images, media files, and <script> tags placed at the bottom of the <body> section are treated as non-render-blocking resources.
Now, let’s dive into some strategies for eliminating or reducing the number and impact of render-blocking resources.
1. Identify your render-blocking resources
This tip may seem obvious, but it’s important to start here. Whether you have an existing website or it’s still in the development phase, the first thing you should do do is find your render-blocking resources so that you can decide how to handle them.
Luckily, these days, there are many free performance metrics tools you can use for this purpose. The most notable ones are:
- Lighthouse, which is now part of Chrome DevTools
- PageSpeed Insights and GTmetrix, two free web apps that use the Lighthouse library to measure page speed, Core Web Vitals, and other performance metrics
However, in Lighthouse, you’ll only see the Eliminate render-blocking resources flag in the Opportunities section of your performance report if your render-blocking resources cause performance issues on your site.
For instance, here’s Lighthouse’s warning for BBC’s homepage:
If you want to get feedback about your render-blocking resources anyway, use one of the aforementioned web apps. In addition to identifying your render-blocking resources, they also provide you with useful tips on how to eliminate them.
For example, here’s the relevant part of GTmetrix’s report for LogRocket’s blog page. You can see that the Eliminate render-blocking resources recommendation has low priority, but the files that “may be contributing to render-blocking” are still listed:
To identify render-blocking resources using these tools, you should do the following:
- Select your preferred performance tool
- Enter your website’s URL into the provided field on their site
- Review the generated report for any warnings or recommendations regarding render-blocking resources
- Implement suggested optimizations based on the tool’s recommendations
- Monitor your website’s performance metrics to track improvements
After following these steps, you still might not have totally eliminated the render-blocking resources on your site. If that’s the case, you can proceed apply some of the following techniques to further improve your page load times and Core Web Vitals scores.
2. Don’t add CSS with the @import rule
There are two ways to use CSS styles on your pages:
- The
<link rel= "stylesheet">tag that you need to add to your HTML file - The
@importrule that you need to add to your CSS file
However, to optimize CSS loading, it’s a best practice to avoid using the @importrule and instead utilize <link>tags in your HTML file. The @import rule, while convenient for organizing CSS dependencies within a CSS file, can slow down the rendering process as it requires the browser to download imported files before rendering.
To transition from using the @import rule to <link> tags, follow these steps:
- Identify all CSS files imported using the
@importrule within your CSS file - Move each imported CSS file to the HTML file and directly reference them using
<link>tags in the<head>section
For example, the following CSS @import:
@import url('style.css');Becomes this instead:
<head> <link href="style.css" rel="stylesheet"></head>
By default, the browser treats all CSS files as render-blocking resources. However, if you add the media attribute to the <link> tag, you can indicate the presence of a conditional CSS file to the browser.
Conditional CSS only applies under certain conditions, such as below or above a given viewport size or on a print page. With the media attribute, you can define a specific media condition for a CSS file. You can use any value that you would use for a media query in a CSS file. For example:
<link href="print.css" rel="stylesheet" media="print"><link href="large.css" rel="stylesheet" media="screen and (min-width: 1500px)"><link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">
Even though these files are still downloaded on all devices, they become non-render-blocking resources if the condition evaluates as false. However, they will still be render-blocking if the condition evaluates as true.
For instance, the mobile.css stylesheet in the above example will be render-blocking on mobile devices with a maximum viewport width of 600px and non-render-blocking on viewports larger than 600px.
If you have an existing CSS file with one or more media queries, you can extract all @media rules and save them as separate files using this PostCSS plugin.
4. Defer non-critical CSS
All the CSS files that you place into the <head> section of your HTML page are automatically treated as render-blocking resources. However, you don’t need all of this code to render the critical part of your page: above-the-fold content.
Splitting CSS into critical and non-critical parts is a performance optimization technique that has gained a lot of popularity since the introduction of Core Web Vitals, as it also improves LCP scores — i.e., the rendering time of the largest content element above the fold.
Luckily, you don’t have to find your critical-path CSS manually — even though it’s possible to do so. You can use online tools, such as the Critical Path CSS Generator or Addy Osmani’s Critical library, to extract the CSS rules that are related to your above-the-fold content.
Critical Path CSS Generator, for example, allows you to enter the URL of your website on their website and returns as outputs two generated downloadable CSS files: a “critical” and a “combined” one.
You can either add the critical CSS file as an external resource to the <head> section or inline it using the <style> tag to also reduce the number of HTTP requests:
The combined CSS file includes all your CSS rules, and you need to move it down before the closing <body> tag so that it will become a non-render-blocking resource. You can read the instructions in detail below the generator, but here’s how your optimized code should look:
Optionally, you can also use JavaScript to dynamically load below-the-fold CSS after the browser finishes downloading the page.
This technique is also detailed under the Critical Path CSS Generator (method number two) and will further improve your site’s performance. However, it won’t contribute to the elimination of render-blocking resources as non-critical CSS has already been moved out of the <head> section.
For web pages built with WordPress or other content management systems (CMS), deferring non-critical CSS can be achieved through plugins specifically designed for optimization. Plugins like Autoptimize for WordPress offer features to aggregate, minify, and defer CSS files, improving page load times and overall performance.
Using these tools can help eliminate render-blocking resources without manual coding, making them accessible to a broader range of users, including those without extensive technical knowledge.
5. Use the defer and async attributes to eliminate render-blocking JavaScript
Similar to CSS, JavaScript files added to the <head> section of the document are also treated as render-blocking resources by default.
You can remove them from the critical rendering path by placing the <script> tags right before the closing </body> tag instead of the <head> section. In this case, they only begin to download after the entire HTML has been downloaded.
However, because the download of these scripts starts later, the elements they load — such as ads, animations, or dynamic functionalities — might load later than the rest of the frontend, especially if it’s a longer script. This can result in noticeable delays and lagging UIs on slower connections, which is bad for the UX.
The defer and async attributes of the <script>tag offer a solution to this problem. Both are Boolean attributes which means that if you add them, they will fire without any further configuration.
They also make scripts added to the <head> section of an HTML document non-render-blocking, but in a different way. Deferred scripts respect the document order while asynchronous scripts are independent of the DOM.
The defer attribute instructs the browser to download the script in the background so it won’t block the rendering of the page. The deferred script executes once the DOM is ready but before the DOMContentLoadedevent fires:
<script src="script01.js" defer></script><script src="script02.js" defer></script>
Deferred scripts follow the document order, just like non-deferred, default scripts. For example, in the above example, script01.js will be executed first, no matter which script loads first.
Note that you can’t add defer to inline scripts. It only works with external scripts that specify the script’s location using the src attribute.
On the other hand, the async attribute informs the browser that a script is completely independent of the page. It will download in the background as a non-render-blocking resource, just like deferred scripts.
However, unlike deferred scripts, async scripts don’t follow the document order, so they will execute whenever they finish downloading — which can happen at any time.
For instance, in the below example, we can’t be sure which script will run first. It solely depends on which one downloads faster — usually, this ends up being the smaller one. Remember, async scripts are independent of both the document and each other, so the document order won’t impact them in any way:
<script src="script03.js" async></script><script src="script04.js" async></script>
The defer attribute is recommended for scripts that need the DOM, but you want to begin to download them before the document loads, without making them a render-blocking resource. You should also use defer rather than async if the document order is important — for instance, when consecutive scripts depend on each other.
The async attribute is recommended for independent third-party scripts, such as ads, trackers, and analytics scripts. For example, Google Analytics recommends adding the async attribute to support asynchronous loading in modern browsers.
While implementing the defer and async attributes for third-party scripts can be more complex due to limited control over them, some optimization plugins may offer features to manage third-party scripts more effectively. For instance, in WordPress, you can use the Async JavaScript plugin to add these attributes to JavaScript files.
However, it’s essential to exercise caution when modifying third-party scripts, as they may be required for the functionality of external services or integrations on your website. Test your website thoroughly to ensure that you don’t negatively impact its functionality or performance after implementing defer and async attributes for third-party files.
6. Find and remove unused CSS and JavaScript
Besides deferring non-critical CSS and JavaScript, check if you have any unused CSS or JavaScript on your site. You can do so with the help of code analysis tools such as PurgeCSS that check your CSS code and remove any unused selectors from it, including the ones added by third-party libraries or frameworks such as Bootstrap.
For JavaScript, you can use bundle analysis tools like webpack-bundle-analyzer and linting tools like ESLint to identify and remove unused code, resulting in smaller bundle sizes and improved website performance.
A bundle analysis tool will generate an analysis report for you, which you can use to detect unused packages or modules included in your webpack bundles. On the other hand, linting tools identify unused variables, functions, or imports within your JavaScript files, allowing you to maintain a lean and efficient codebase.
Popular content management systems also have cleanup plugins that let you remove your unused CSS and JavaScript automatically.
7. Split code into smaller bundles
You can use module bundlers such as webpack, Rollup, and Parcel to split your code into smaller bundles and load each bundle on demand and even in parallel.
Many of these smaller bundles are non-essential resources that can be safely lazy-loaded after the web page has been rendered. You might also have code that you only need to load if the user wants to use a specific part or feature of your page.
Even though it’s possible to perform code splitting and create smaller bundles manually, automation makes the process straightforward, safe, and fast. These days, most bundling tools come with zero-configuration code splitting functionality that works out of the box, but they also let you tweak the configuration manually if you want to.
8. Minify CSS and JavaScript
In addition to code splitting, you can also minify both render-blocking and non-render-blocking resources. Since minified files are lighter, initial page rendering will finish sooner. Plus, it will also take less time to download non-render-blocking resources in the background.
There are numerous tools available to help you perform minification according to best practices, including Minify, CSS Minifier, Minify Code, and PostCSS. Build tools, such as webpack, Parcel, and Rollup, also come with built-in minification functionalities that enable you to quickly reduce the weight of render-blocking resources.
For third-party libraries, most of them minify their code before distribution to improve performance and reduce file sizes. Library developers commonly practice this optimization to ensure efficient loading and usage across various websites and applications.
Some CMS platforms also provide code minification plugins, allowing website owners to easily minify CSS and JavaScript files within their CMS dashboard. This simplifies the optimization process and improves overall site performance.
9. Load custom fonts locally
Because custom fonts are called from the <head> section of the document, they are also render-blocking resources. For instance:
<link href="https://fonts.googleapis.com/css2?family=Lato&display=swap" rel="stylesheet">
You can reduce the impact of custom fonts on initial page rendering by adding them locally rather than pulling them from a content delivery network such as Google CDN. Font providers tend to add multiple @font-facerules, many of which you won’t need.
For example, Google Fonts adds @font-face rules for all the character sets a typeface comes with, such as Latin, Cyrillic, Chinese, Vietnamese, and others.
Let’s say, for instance, that the online CSS file you add with the <link> tag includes @font-face rules for seven different character sets, but you only want to use one. However, Google Fonts doesn’t download the font files for all the character sets; they just add many redundant @font-face rules to the CSS file.
If you add fonts locally, you can also minify your font-related CSS and bundle it together with the rest of your CSS. You can use the google-webfonts-helper to generate local @font-face rules for Google Fonts quickly. For instance, this is what you need to add to include the Lato Regular font face:
/* lato-regular - latin */@font-face { font-family: 'Lato'; font-style: normal; font-weight: 400; font-display: swap; src: local('Lato Regular'), local('Lato-Regular'), url('../fonts/lato-v16-latin-regular.woff2') format('woff2'), url('../fonts/lato-v16-latin-regular.woff') format('woff');}Note that google-webfonts-helper doesn’t add the font-display: swaprule — I added it myself to the above declaration. This is a descriptor of the @font-face rule that lets you specify how the browser should display the font face on the page.
By using font-display with the swap value, you instruct the browser to immediately begin to use a system font and swap it with the custom font once it downloads. This rule is also added when you pull the font from Google’s CDN. This enables you to avoid invisible text on the page while the custom font is still loading.
When you load fonts locally, make sure you serve compressed font formats for modern browsers, such as WOFF and WOFF2. Remember that lighter files reduce the impact of render-blocking resources too. In addition to generating the @font-face rules, google-webfonts-helper also lets you download a zipped file that contains all the font formats you need.
Why you shouldn’t load custom fonts asynchronously
Some articles about render-blocking resources recommend using TypeKit’s Web Font Loader to load custom fonts asynchronously. It was a decent tool once upon a time, but it hasn’t been updated since 2017 and it has many unresolved issues. I wouldn’t recommend using it.
Although loading fonts asynchronously shortens the critical rendering path, you should always do it carefully. If fonts load later than the page content, the page can produce a common UX problem called flash of invisible text (FOIT).
There are various ways to handle FOIT, such as using third-party libraries or the aforementioned font-display: swap rule. Make sure to check the browser support for font-display, and note that using it with the swap value just turns FOIT into a flash of unstyled text (FOUT) but doesn’t completely eliminate the issue
Still, you’ll want to spend time considering whether it’s really worth going the async route performance-wise. Think of factors such as the weight of extra scripts, potential issues, users with disabled JavaScript. In the last case, you still need to add the static <link> element within <noscript> tags to support them.
10. Using CMS plugins
For websites built with CMS, plugins offer a convenient way to optimize and manage render-blocking resources without extensive manual coding. Here are some examples of plugins available for different CMS platforms:
- WordPress: Autoptimize, W3 Total Cache
- Joomla: JCH Optimize, Cache Cleaner
- Drupal: Advanced CSS/JS Aggregation, Asset Injector
- Shopify: SEO Manager, MinifyMe
These plugins can optimize various aspects of your website, including aggregating, minifying, and deferring resources, as well as improving caching mechanisms and enhancing overall performance.
To use these plugins effectively:
- Install and activate: Search for the desired plugin in your CMS’s plugin directory, install it, and activate it
- Configure settings: Adjust plugin settings according to your website’s needs. Some plugins offer options to aggregate, minify, and defer resources, while others may provide additional optimization features
- Test and monitor: After configuring the plugin, test your website’s performance using tools like Lighthouse or GTmetrix. Monitor performance metrics to ensure the plugin is effectively reducing render-blocking resources without causing any issues
11. Managing third-party scripts and resources
Third-party scripts and resources, such as analytics, ads, or social media widgets, can contribute to render-blocking issues. While these scripts are often necessary for website functionality, they can also impact performance if not managed properly.
Here are some tips for handling third-party scripts and resources efficiently so that they don’t become render-blocking resources:
- Evaluate necessity: Review all third-party scripts and resources to determine if they are essential for your website’s functionality and user experience
- Optimize loading: When possible, use
asyncordeferattributes for third-party scripts to prevent them from blocking page rendering. - Use content security policies (CSP): Implement CSPs to control which external resources can be loaded on your website, reducing the risk of malicious or unnecessary scripts
- Monitor performance: Regularly check performance metrics to identify any third-party scripts causing performance issues. Consider removing or replacing scripts that are not contributing significantly to user experience
By carefully managing plugins and third-party resources, you can effectively reduce render-blocking issues and improve your website’s performance.
Practical considerations for implementation
While these strategies can help you eliminate render-blocking resources, thus improving web performance, it’s important to remember that some challenges may arise while implementing them. Here are some considerations to keep in mind:
- Some techniques, like deferring non-critical CSS or asynchronously loading JavaScript, may be difficult to apply with third-party integrations. As it can be challenging to determine which resources are critical, always prioritize testing and monitoring to ensure everything on your website still works as expected
- When it comes to code splitting or removing unused code, a comprehensive understanding of the website’s technology stack and development environment is essential. This knowledge helps you avoid the accidental removal of critical code, ensuring the website’s functionality remains intact
- As websites often rely on third-party scripts, stylesheets, or services for functionality like analytics, advertising, or social media integration, the website’s ability to load or minify third-party resources may be limited by the requirements or limitations imposed by these external dependencies
- Optimizing web performance by eliminating render-blocking resources is a task that requires time, expertise, and development effort. However, it’s important to remember to balance these efforts with other development tasks. This ensures a holistic approach to website development, where all aspects are given due attention
- Eliminating render-blocking resources may involve trade-offs or considerations that need to be carefully evaluated. For example, deferring non-critical CSS may improve initial page load times but could impact the perceived performance or user experience. Understanding these trade-offs is essential for making informed decisions
Summary
In this article, we discussed various strategies for eliminating render-blocking resources. To summarize:
- Identify your render-blocking resources
- Don’t use CSS imports
- Load conditional CSS with
mediaattributes - Defer non-critical CSS
- Use the
deferandasyncattributes to eliminate render-blocking JavaScript - Find and remove unused CSS and JavaScript
- Split code into smaller bundles
- Minify CSS and JavaScript files
- Load custom fonts locally
- Use CMS plugins
- Manage third-party scripts and resources efficiently
To improve overall page load times, you can also use resource hints and the preload directive. They don’t eliminate render-blocking resources per se, but you can use them to improve page load times.
Render-blocking resources won’t stop the fetching process of preloaded resources, and you can also pre-connect to Google CDN to make web fonts load faster if you don’t want to load them locally.
For an in-depth guide to browser rendering, check out “How browser rendering works — behind the scenes.”
LogRocket: Debug JavaScript errors more easily by understanding the context
Debugging code is always a tedious task. But the more you understand your errors, the easier it is to fix them.
LogRocket allows you to understand these errors in new and unique ways. Our frontend monitoring solution tracks user engagement with your JavaScript frontends to give you the ability to see exactly what the user did that led to an error.
LogRocket records console logs, page load times, stack traces, slow network requests/responses with headers + bodies, browser metadata, and custom logs. Understanding the impact of your JavaScript code will never be easier!
Try it for free.
