You ran your home page through PageSpeed Insights and near the top of the list sat a warning to eliminate render blocking resources, followed by a dozen file names you did not recognise: the theme stylesheet, something from your page builder, jQuery, a Google Fonts address, a few plugin files. Maybe you then switched on every “optimise CSS” and “defer JavaScript” box in your caching plugin, and the mobile menu stopped opening.
It happens a lot. The warning is real and worth acting on, but it bundles several different problems together, and the fixes have to happen in a sensible order. Each technique has its own post. This one is the map, starting with what the browser is actually waiting for.
What “render-blocking” means in plain terms
When a browser receives your page, it reads the HTML from the top. Before it paints anything, it needs to know what the page should look like, so it builds two things: a structure of the content and a set of style rules. Only when it has both can it draw the first pixels.
A render-blocking resource is any file the browser decides it must download and process before it is allowed to show the page. Until that file arrives, the visitor stares at a white screen, even if the text of the page has already been delivered. On a fast office connection the wait is short. On a phone with a weak signal, each blocking file adds a round trip to a server, and the blank screen lasts noticeably longer.
Recent versions of Lighthouse, the engine behind PageSpeed Insights, present this under a “render-blocking requests” insight rather than the older wording. The idea has not changed: these are the files standing between the visitor and the first paint.
CSS and JavaScript block the page differently
The two kinds of file get lumped together in the report, but they hold the page up for different reasons. Knowing which is which tells you what kind of fix is even possible.
Stylesheets block painting
A normal stylesheet linked in the head of the page is render-blocking by design. The browser refuses to paint until it has the CSS, because painting first would show unstyled text that then jumps into place. That is a deliberate choice by browser makers, not a fault in your site.
So you cannot simply “turn off” blocking CSS. You can make less of it block (send only the styles needed for the first screen), make it smaller, or make sure the browser is not waiting on styles for things that are not on this page at all. A stylesheet marked for a media type that does not match, such as print, does not hold up the screen render.
Scripts block reading the page
A classic script in the head, without any loading attribute, does something worse: it stops the browser from reading the rest of the HTML. The browser has to fetch the script, run it, and only then carry on, because the script might change the page. If that script is large or sits on a slow third-party server, everything below it waits.
Scripts are more flexible than CSS. Most of them can be told to load in the background and run later, using the defer or async attributes, or be moved so they do not load until they are needed. The catch is that some scripts depend on each other, which is where sites break.
How to see which files are actually blocking
Start with the list PageSpeed Insights gives you, but read it as a starting point. For each file it shows the size and the time it is estimated to cost. Then confirm what you see with one more view.
- A waterfall chart from GTmetrix, WebPageTest or your browser shows every request in order. Files that load before the first paint and sit early in the chart, with nothing much happening alongside them, are the ones holding things up.
- The page source (right-click, View Page Source) tells you where each file is referenced. Stylesheets and scripts in the head without
deferorasyncare your blocking set. - The Coverage panel in Chrome DevTools shows how much of each CSS and JavaScript file is used by the page you are on. A big stylesheet that is mostly unused on this page is a strong candidate.
Write down the list with sizes, and note which plugin or theme each file belongs to. The folder name in the file path usually tells you: anything under a plugin’s folder belongs to that plugin.
What a typical WordPress head contains
On a typical small business WordPress site, the blocking list is made of the same few groups:
- The theme’s main stylesheet, sometimes with a second one for a child theme.
- Page builder CSS, often split into a general file plus a per-page file.
- The block library stylesheet that WordPress loads for blocks, even on sites that barely use them.
- Plugin stylesheets for things like forms, sliders, popups and social icons, loaded on every page whether or not that page uses them.
- jQuery and the scripts that depend on it.
- A Google Fonts stylesheet, which then triggers downloads of the font files themselves from another server.
- Tracking and marketing tags: analytics, an ad pixel, a heatmap tool, a chat widget.
Each group has a different fix. That is why one checkbox rarely solves the whole warning.
How to eliminate render blocking resources in a safe order
The order matters because the early steps are low risk and shrink the problem, and the later steps are fiddly and easier once there is less to manage. Take a backup or use a staging copy, and test after each step rather than at the end.
- Remove what this page does not need. A contact form plugin loading its files on your blog posts, or a slider script on pages without a slider, can often be switched off per page. Our posts on how to trim stylesheets your pages never use and stop scripts loading where they do nothing cover the tools and the risks.
- Move scripts out of the way. Most scripts can load with
deferso they no longer stop the HTML from being read. Which scripts can take which attribute, and why jQuery is the usual trouble spot, is explained in the difference between defer and async. - Deal with fonts. A remote font stylesheet blocks rendering and then starts a second chain of requests. Cutting families and weights, or serving fonts from your own server, often removes one of the slowest items on the list. See why Google Fonts can slow a page.
- Look hard at third-party tags. Old pixels, a heatmap tool nobody checks, or a tag manager loading in the head can cost more than your own files. Auditing those tags is a job of its own, covered in our post on third-party scripts.
- Only then, consider critical CSS. Sending the styles for the first screen inside the HTML and loading the rest later is the step that removes CSS from the blocking list. It is also the step most likely to cause a flash of unstyled content and needs looking after when the design changes. Read how critical CSS works before switching it on.
Minifying files belongs near the end too. It makes files a little smaller, which helps, but it does not change whether they block.
Mistakes that cause more trouble than the warning
Sites that break during speed work usually get there in one of these ways:
- Turning on every option at once. When the slider vanishes you cannot tell which of six settings did it. Switch one on, clear the cache, test, then move on.
- Deferring jQuery while inline code still expects it. A theme or plugin prints a small piece of JavaScript in the page that runs immediately and calls jQuery. If jQuery now arrives later, that code fails and a menu, tab or form stops working.
- Testing while logged in. Many optimisation plugins skip logged-in users. Test in a private window, and on a phone.
- Forgetting the other caches. After changing settings, purge the plugin cache, any server cache, and the CDN, or you will be testing the old version.
- Chasing the last item. Some files will always block, and should. The theme stylesheet has to arrive before the page looks right. The goal is a short, small blocking list, not an empty one.
If a change has broken something and you are not sure which setting caused it, undo the most recent change first, purge every cache, and check again before touching anything else.
What to measure before and after
The warning is a lab estimate. What you are really trying to move is how soon the visitor sees something. Before you change anything, run PageSpeed Insights three or four times on the same page and note the middle value of First Contentful Paint and Largest Contentful Paint for mobile. Repeat that after each step.
Also look at the page on a real phone over mobile data, with the cache cleared. Does text appear sooner? Does anything jump around or appear unstyled for a moment? A lower number with a page that flickers is not a good trade.
If you want a quick look without opening several tools, our free website speed test gives a starting snapshot. For how this fits with server time, images and caching, the wider website speed guide puts render-blocking files in context alongside everything else that slows a page.
Frequently asked questions
Can I remove every render-blocking file from my page?
Not sensibly. The browser needs some CSS before it can paint without the page looking broken, so at least the styles for the first screen will always hold rendering up. The realistic aim is a short list of small files, with scripts deferred and anything unused for that page removed.
Will a caching plugin fix this warning on its own?
Partly. Plugins such as WP Rocket, LiteSpeed Cache and Autoptimize can defer scripts and minify or combine files, and some can generate critical CSS. They cannot know which plugin files a page truly needs, and their aggressive options can break menus and forms, so they still need careful setup and testing.
Why does the warning appear on mobile but not on desktop?
PageSpeed Insights tests mobile with a slower simulated connection and processor. Each blocking file costs more time there, so files that are under the threshold on desktop cross it on mobile. The files are usually the same; the cost of waiting for them is what changes.
Does a page cache get rid of render-blocking files?
No. A page cache makes the HTML arrive sooner, but the browser still has to fetch the same stylesheets and scripts before it can paint. Caching and render-blocking fixes work on different parts of the load, so a well-cached page can keep showing this warning until the files themselves are reduced, deferred or removed.
A long blocking list usually takes several careful passes rather than one setting. Our website speed optimisation service works through CSS and JavaScript changes one at a time, each agreed with you first, and re-tests the page afterwards so the numbers can be compared side by side.
All guides in this section
- How to Reduce Unused CSS Without Breaking Your Site
- How to Reduce Unused JavaScript on WordPress
- Minify CSS and JavaScript: What It Saves and What It Risks
- Defer vs Async JavaScript: Which to Use and What Breaks
- Critical CSS Explained: Faster First Paint, Fewer Surprises
- Are Google Fonts Slowing Your Website? What to Cut First
- How to Host Google Fonts Locally on WordPress
- Font-display Swap Explained: Stop Invisible Text
- Are Third-Party Scripts Slowing Your Website?
- Is Your Live Chat Widget Slowing Your Website?
Next in this series: How to Reduce Unused CSS Without Breaking Your Site
