Render Blocking Resources Test

What is it?

Render-blocking resources are JavaScript and CSS files that the browser must download and process before it can render any visible content. Each one extends the critical rendering path with another network round trip and another parse step, and on a slower mobile connection the cumulative impact can mean seconds of blank screen before the user sees anything at all. This test identifies the render-blocking files on your page along with the estimated time each one delays first paint, so you can defer, async, or inline them to unblock the rendering path.

Why render-blocking resources matter

The critical rendering path is the sequence of steps the browser takes from receiving the HTML to painting the first pixels. Every render-blocking resource extends that path with another network round trip and another parse step. On a fast desktop connection these costs are small, but on a mobile connection they accumulate quickly: three or four blocking resources can mean three or four extra round trips before anything appears on screen.

The modern playbook for unblocking the rendering path is well established. Inline the critical CSS needed for above-the-fold content directly in the HTML, then load the full stylesheet asynchronously. Defer non-critical JavaScript with defer or async attributes so it does not block parsing. Add font-display: swap to @font-face rules so text renders immediately in a fallback font. Each of these changes is small in isolation; combined they can dramatically improve First Contentful Paint and Largest Contentful Paint scores.

Common sources of render blocking

Single large stylesheet blocking render entirely; inline critical CSS, load the full stylesheet asynchronously.
Synchronous third-party scripts in the head: add defer or async, or move them to the end of the body.
Web fonts blocking text rendering: add font-display: swap to font-face rules.
Render-blocking @import in CSS: replace with separate <link rel="stylesheet"> tags so the browser can fetch them in parallel.

This test reports the resources that block rendering on your page along with the estimated time each one delays first paint. The fix guide below covers critical CSS extraction, deferring scripts, font-display strategies, and preloading the critical request chain.

Pass rate:

Top 100 websites: 15%
This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
All websites: 9%
This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.

Pass rates of Top 100 US websites
2021	29%
2022	14%
2023	10%
2024	15%

100

How do I fix it?

This test fails when JavaScript or CSS resources block the browser from rendering visible content. Each render-blocking file delays the first paint, and on slower networks the cumulative impact can be severe. Fixing this issue means inlining the truly critical CSS, deferring or asynchronously loading non-essential scripts, and removing unused code.

Example

<head>
  <!-- Inline only above-the-fold critical CSS -->
  <style>/* critical styles here */</style>

  <!-- Load full stylesheet asynchronously -->
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">

  <!-- Defer non-critical scripts -->
  <script src="/scripts/app.js" defer></script>
</head>

Where to make the change

Application code or templates: identify the CSS and JavaScript needed for the initial render and load only those synchronously. Defer the rest.
Build pipeline: use a critical CSS extractor (such as critical or penthouse) to generate the above-the-fold styles automatically.
WordPress: performance plugins offer "delay JS execution" and "load CSS asynchronously" options that handle most of this without code changes.
Headless or framework sites: use the framework's preload and code-splitting hints to control what blocks rendering.

Common causes and how to resolve them

Single large stylesheet blocking render: inline critical CSS for the first viewport, load the full stylesheet asynchronously.
Synchronous third-party scripts in the head: add defer or async, or move them to the end of the body.
Web fonts blocking text rendering: add font-display: swap in @font-face rules so the fallback font shows immediately.
Render-blocking @import in CSS: replace with separate <link rel="stylesheet"> tags so the browser can fetch them in parallel.

Best practices

Use defer for scripts that need the DOM: they execute after parsing but before DOMContentLoaded.
Use async for fully independent scripts: they execute as soon as they download, in any order.
Preload the critical request chain: tell the browser early about fonts and key assets with <link rel="preload">.
Audit with Lighthouse: the Render-blocking resources audit lists every offending file with the estimated time saved by deferring it.