Before the browser paints a single pixel, it has to download and parse every stylesheet and synchronous script in your <head>. A site can have a fast server, a lean HTML document and a CDN in every region, and still show a blank screen for two seconds because one file is making the browser wait. That is a render-blocking resource, and to eliminate render-blocking resources you only need a few targeted changes.
What Render-Blocking Resources Are
A browser parses HTML from top to bottom. When it reaches a <link rel="stylesheet">, it will not paint anything until that CSS has downloaded and parsed, because it needs the full styles to lay out what it is about to draw. A synchronous <script> is worse: it stops HTML parsing entirely until the script downloads and runs, since the script could change everything below it.
Neither is wrong in itself. A page genuinely needs its critical CSS before it can paint correctly. The problem is render-blocking resources that are large, slow to fetch, or not needed for what is visible in the first viewport.
How to Find Render-Blocking Resources
- Performance audit. The "Eliminate render-blocking resources" finding lists every stylesheet and synchronous script loaded before first paint, with the estimated time each one costs. It is the fastest starting point.
- Network waterfall. In DevTools, filter to CSS and JS and check which requests finish before the first paint marker. Anything upstream of that line is a candidate.
- Coverage panel. Run "Show Coverage" in DevTools to see how much of each CSS and JS file is actually used. A render-blocking stylesheet that is 90% unused is a far better target than a small one that is mostly applied.
How to Eliminate Render-Blocking Resources
1. Defer non-critical JavaScript
With defer, the script downloads in parallel with HTML parsing and runs only after parsing finishes, in document order. It is the right default for almost every script that is not needed before first paint.
2. Use async for independent scripts
async also downloads in parallel but runs as soon as the file arrives, out of order. That suits self-contained snippets such as analytics that do not depend on anything else on the page.
3. Inline critical, above-the-fold CSS
Extract only the CSS needed to render what is visible without scrolling, inline it in the <head>, and load the full stylesheet asynchronously. This trades a blocking network request for zero-latency inline styles for what matters first.
4. Scope non-critical stylesheets with a media attribute
A stylesheet with media="print" or a breakpoint that does not match still downloads, but at low priority and without blocking the screen render.
5. Remove the CSS you do not use
Framework bundles often ship far more CSS than a page needs. Purging unused rules shrinks what the browser must parse before it can paint, whatever loading strategy you use. Purging at build time, with a safelist for classes added by JavaScript, is usually safe.
6. Split JavaScript bundles
One large bundle blocks on all of it even if only a fraction is needed for the first render. Split by route, or by above- and below-the-fold usage, so the browser only waits on what is actually blocking. Modern build tools (Next.js, Vite) do this by default; a render-blocking finding is often a manually added third-party script that bypassed that pipeline.
7. Move legacy scripts to the end of the body
For older code that cannot use defer, placing the script just before </body> means the parser has already built the page above it before it blocks.
When It Is Not Worth Fixing
A few hundred bytes of inlined critical CSS blocking render for a few milliseconds is the mechanism working as intended. The audit flags a cost, not a verdict. Spend your effort on render-blocking resources that show up as hundreds of milliseconds in the waterfall, not on reaching an empty list for its own sake.
How Scanverra Detects Render-Blocking Resources
Scanverra's performance audit runs a lab test against your live URL and reports every render-blocking stylesheet and script with the estimated savings from deferring or removing it, in the same run that scores LCP and TTFB. The Core Web Vitals test shows how much of your Largest Contentful Paint time is attributable to render-blocking resources versus the rest of the chain, and the Core Web Vitals guide explains that chain in full.