How To Eliminate Render-blocking Resources
-
Table of Contents
- What are Render-Blocking Resources?
- Why Should You Eliminate Render-Blocking Resources?
- How To Identify Render-Blocking Resources on Your Website?
- How To Eliminate Render-Blocking Resources
- How to Reduce Render-Blocking Resources in WordPress with SiteGround Speed Optimizer
- Checklist for Eliminating Render-Blocking Resources
This article was originally written and published on March 28th, 2022, by Cal Evans. It has been updated on March 20th, 2025, to reflect the latest developments in techniques for eliminating render-blocking resources.
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 Speed Optimizer plugin.
What are Render-Blocking Resources?
“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.
Every resource that is loaded into your website has the potential to be a render blocking resource. This includes:
- Large images
- JavaScript code that has to execute in the <head> of your page
- Large CSS that your page can’t display until it is all loaded
- Any resource from another site that is slower than yours
- Plugins that each have their own CSS and JavaScript files
In short, anything that you have in your HTML to be loaded is potentially a render-blocking resource.
Why Should You Eliminate Render-Blocking Resources?
When a visitor lands on your website, their browser wants to show them the page as quickly as possible. But if there are too many render-blocking resources, the browser has to hit the brakes and wait for those files to download and process before showing anything useful.
This creates what we call a “slow first paint” – that awkward pause where users stare at a blank or half-loaded page. Not ideal, right?
Here’s why it matters:
- Better User Experience – Fast-loading pages feel smooth and polished. A slow-loading page, on the other hand, can frustrate visitors and make them leave before they even see your content.
- Improved SEO – Google and other search engines consider page speed as a primary ranking factor. If your pages are slow because of render-blocking resources, it will hurt your position in search results.
- Higher Conversions – Whether you’re running an online store, a blog, or a portfolio site, faster-loading pages often mean higher conversion rates. A snappy page helps keep people engaged.
- More Efficient Use of Resources – Eliminating unnecessary or poorly optimized assets reduces bandwidth usage and server load, which can save you money and reduce strain on your hosting environment.
With Interaction to Next Paint (INP) replacing First Input Delay (FID) as a core web vitals metric, it’s even more important to reduce render-blocking resources.
Optimizing how quickly users can interact with your page will not only improve perceived performance but also positively impact your web vitals score.
At the end of the day, your website’s goal is to communicate something quickly and clearly. Render-blocking resources get in the way of that by delaying when visitors can actually start interacting with your content.
Now that you know the “why,” let’s dig into how to spot these slowpokes and streamline your website’s loading process.
How To Identify Render-Blocking Resources on Your Website?
There are plenty of tools to help you see how your website loads. We suggest these options for identifying render-blocking resources:
Using Browser DevTools
This is one of the tools that can show you a “waterfall” view of how a page loads. All modern browsers include this feature.
Right-click anywhere on your webpage, select “Inspect”, then head to the “Network” tab.
Reload the page, and you’ll see something like this:
On the right side, you’ll spot the waterfall chart. The colored bars show how long each resource takes to load. The thin blue line marks when the page starts rendering.
If you notice a lot of resources loading before that line, it could mean there’s room for improvement.
This built-in view is great for quick checks, but it only tells you how the page performs on your current setup. If you’re developing locally, results might be faster than real-world conditions.
For deeper insights, you can turn to online tools like WebPageTest.
WebPageTest & Other Performance Testing Tools
WebPageTest gives you a clearer picture of how your site performs globally. Plus, you can customize tests to match real-world conditions.
Pro tip: If you want a quicker overview, tools like PageSpeedInsights also flag render-blocking resources.
The typical method is:
- Start with a desktop test
- Pick a server location that’s distant from your website’s host
- Stick with Chrome unless you have a reason to choose another browser
You can adjust these under the “Advanced Configuration” tab.
Hit “Start Test” and review the results.
You’ll now see a more detailed waterfall chart. Clicking it opens a full-sized version where you can spot render-blocking JavaScript and CSS files.
In this example, there are 32 render-blocking resources—mostly CSS files, with a few JavaScript files mixed in.
It’s easy to see why JavaScript can block rendering, but CSS can do the same. The browser can’t fully display the page until it has all the styles it needs. If an important CSS rule loads late, your page might pause until it’s ready.
This is why streamlining CSS and JS delivery is key, and exactly what we’ll cover next.
How To Eliminate Render-Blocking Resources
Over time, web developers have experimented with various methods to reduce or eliminate render-blocking resources. Today, there are several reliable techniques you can use to speed up page rendering.
1. Optimizing JavaScript Loading
JavaScript is one of the most common culprits when it comes to render-blocking. Luckily, there are several techniques to control how and when your scripts load, so your page can display faster.
1.1. Understanding Async vs. Defer
To prevent JavaScript files from blocking page rendering, you should use the DEFER or ASYNC attributes in your script tags.
<script defer src="https://example.com/script.js"></script>- DEFER downloads the script while the page is rendering and executes it only after the HTML is fully parsed. It preserves the order of scripts.
- ASYNC downloads and executes the script as soon as it’s ready, regardless of the page’s rendering state. This can cause scripts to execute out of order.
Generally, DEFER is the better choice, especially when your scripts depend on each other or on the DOM. It allows the browser to focus on painting the page before running scripts.
1.2. Handling Third-Party Scripts Efficiently
Third-party scripts, like analytics or social sharing widgets, are common render-blockers. If possible, load these scripts using DEFER or ASYNC.
Some non-essential third-party scripts can also be moved to load after the page has finished rendering entirely, using event listeners like window.onload.
1.3. Lazy Loading Non-Critical Scripts with IntersectionObserver
For scripts that are only needed once a user interacts or scrolls to a certain section (e.g., chat widgets or embedded videos), you can lazy-load them using the IntersectionObserver API.
const observer = new IntersectionObserver((entries) => {
if (entries[0].isIntersecting) {
// Dynamically load script here
}
});
observer.observe(document.querySelector('#lazy-element'));This tells the browser to load these scripts only when the related elements come into view, reducing the upfront workload for the browser.
2. Optimizing CSS for Faster Rendering
CSS tells your browser how to style your page, but it can also slow down how fast that page shows up. Let’s look at how to make your CSS work with you—not against you—when it comes to performance.
2.1. Inlining Critical CSS for Above-the-Fold Content
Browsers block rendering until they’ve processed CSS. To speed up the first paint, Google suggests identifying your “critical CSS” (the styles needed for the above-the-fold content) and inlining them directly into your HTML.
<style>/* Critical CSS goes here */</style>This eliminates the need for the browser to wait for external stylesheets before displaying content above the fold.
The easiest way to identify and inline critical CSS is by using tools like the Chrome Coverage Tool to see what styles load during initial rendering.
It will show you the CSS that you are loading that is non-critical (red bar) and critical (green bar).
By pulling the critical CSS out and placing it inline, you can remove the CSS as a render-blocking resource.
2.2. Deferring Non-Critical CSS
For non-essential styles, such as those affecting the footer or elements below the fold, you can defer loading by using the media attribute with a value like print and switching it back to all after the page loads:
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">This trick allows the browser to prioritize critical resources and load the rest after the page is visually complete.
2.3. Preloading Key CSS Files
Another tactic is preloading CSS files you know are crucial but don’t want to inline. Preloading helps the browser discover these resources earlier in the rendering process:
<link rel="preload" href="important.css" as="style" onload="this.rel='stylesheet'">It’s useful for important stylesheets that impact the look and feel of above-the-fold content but are too large or complex to inline.
3. Progressive Rendering Techniques
Beyond scripts and stylesheets, there are some additional strategies you can use to progressively load content and speed up your website’s first paint.
3.1. Server-Side Rendering (SSR) and Static Generation
Server-Side Rendering (SSR) and static generation can help deliver fully-formed HTML to the browser, reducing the reliance on client-side scripts for initial rendering.
This means content becomes visible sooner because the browser doesn’t have to wait for JavaScript to build the page structure.
Frameworks like Next.js or Gatsby make SSR and static generation easier to implement.
3.2. Optimizing Fonts and Images to Improve Load Times
Fonts and images can also block rendering if not handled correctly. To optimize them:
- Use the font-display: swap CSS property to prevent font files from blocking the first paint.
- Lazy-load images below the fold using the loading=”lazy” attribute.
- Preload key fonts or hero images with the <link rel=”preload”> tag to prioritize them.
Together, these strategies improve your site’s performance by letting browsers display content as early as possible while loading non-essential assets in the background.
How to Reduce Render-Blocking Resources in WordPress with SiteGround Speed Optimizer
If you’re using WordPress, the SiteGround Speed Optimizer plugin offers an easy way to reduce render-blocking resources without touching your code.
Even if you don’t host with SiteGround, this plugin can still help optimize your website’s performance.
Warning:
When making these changes, it’s important to proceed carefully. We recommend adjusting one setting at a time and then checking your site in a different browser to make sure everything is still working correctly.
This way, you can identify any potential issues and fix them immediately before moving on to the next optimization.
1. Optimizing JavaScript
First, go to the JavaScript settings in the plugin. Here are the key optimizations:
- Minify JavaScript Files: This removes unnecessary characters from your JavaScript code. This makes it smaller and faster to load.
- Combine JavaScript Files: Combining JavaScript files reduces the number of requests the browser needs to make, speeding up the load time.
- Defer Render-blocking JavaScript: This important option adds the DEFER attribute to your JavaScript files, allowing the page to render before executing JavaScript.
2. Optimizing CSS
Next, head to the CSS settings:
- Preload Combined CSS: This setting makes sure that your combined CSS file is loaded early in the process, so it’s available when the page starts rendering.
- Minify CSS Files: This removes spaces, new lines, and comments from your CSS, shrinking the file size and improving load times.
- Combine CSS Files: Combining CSS files helps reduce render-blocking by lowering the number of HTTP requests.
By applying these optimizations, you can significantly reduce render-blocking resources on your WordPress site and make it faster.
If you want to dive deeper into WordPress optimizations, check out our video on How to Speed up Your WordPress Website Like a Pro.
After going through all these steps on our test site, we are down to 24 render-blocking resources from 32. That’s a really good start.
The next step is to locate all critical CSS and in-line it. Then defer all other CSS and apply the other optimization techniques we discussed above. That will remove almost all of the remaining render-blockers.
Now, let’s go over a final checklist of all the techniques we’ve explored.
Checklist for Eliminating Render-Blocking Resources
By now, you’ve learned that render-blocking resources don’t just slow things down—they can directly impact user experience, SEO, and conversions.
To help you put everything into action, here’s a checklist you can follow:
- ✅ Identify render-blocking resources using browser DevTools or tools like WebPageTest.
- ✅ Add defer or async attributes to non-critical JavaScript files.
- ✅ Optimize third-party scripts by loading them asynchronously or deferring them when possible.
- ✅ Use IntersectionObserver to lazy load scripts that aren’t needed immediately.
- ✅ Inline your critical CSS (above-the-fold styles) directly into your HTML.
- ✅ Defer non-critical CSS or load it asynchronously, and remove unused CSS.
- ✅ Preload important CSS files to give the browser a head start.
- ✅ Implement progressive rendering techniques like Server-Side Rendering (SSR) or static generation where it makes sense.
- ✅ Optimize fonts and images to remove hidden bottlenecks.
- ✅ Use performance optimization plugins like the SiteGround Speed Optimizer to automate many of these tasks easily.
Eliminating render-blocking resources may feel like fine-tuning. Each of these steps chips away at those frustrating pauses during page loads. Apply them consistently, and you’ll create a faster, smoother experience for your visitors.
From improving user experience to boosting SEO, every optimization counts. When your pages load quickly, visitors stick around longer and search engines take notice of that.
The best part? With а tool like the SiteGround Speed Optimizer, you can automate a lot of these steps and get faster results without much hassle and coding knowledge.
In the long run, every little improvement adds up—and that’s what keeps your website fast, reliable, and ready to perform.
Comments ( 2 )
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.
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 our official channels of communication.
Leave a comment
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 our official channels of communication.