Render Blocking Resources Test
The Render Blocking Resources Test inspects every CSS and JavaScript file the browser must download and parse before rendering the page, then ranks them by how many seconds they delay First Contentful Paint and Largest…
- Results in seconds
- Pass / fail + fix guidance
- No account required
The Render Blocking Resources Test inspects every CSS and JavaScript file the browser must download and parse before rendering the page, then ranks them by how many seconds they delay First Contentful Paint and Largest Contentful Paint. Render-blocking resources are the single biggest cause of slow paint metrics — and almost every blocker has a specific fix: defer the script, async the script, inline the critical CSS, or split the stylesheet.
What This Tool Checks
- All synchronous <script> tags in <head>
- All <link rel="stylesheet"> blocking initial render
- @import directives inside CSS files
- Per-resource delay contribution to FCP / LCP
- Critical vs non-critical CSS opportunities
- Async / defer attribute usage on scripts
Why It Matters for SEO
Render-blocking resources are the most common cause of poor FCP, LCP and Speed Index. Every blocking script delays first paint by however long it takes to download, parse and execute. Every blocking stylesheet delays paint by however long it takes to download and parse. Removing blockers — by inlining critical CSS, deferring non-critical CSS, and adding async / defer to scripts — typically cuts paint times by 30-60%.
How to Fix It
Inline the critical above-the-fold CSS in <style> tags inside <head>. Load the rest of the CSS asynchronously (rel="preload" + onload swap). Add async or defer to every <script> in <head>. Use font-display: swap on web fonts. Re-test until the critical render path contains only HTML and inlined critical CSS.
How It Works
Headless Chrome captures the network waterfall and identifies every resource on the critical render path. Each blocking resource is annotated with the time it added to FCP and LCP, plus a specific fix recommendation (inline, defer, async, or split).
Common Mistakes to Avoid
- Loading entire CSS framework synchronously when only 5% is used above the fold
- Synchronous <script> in <head> blocking parse and paint
- @import in CSS chaining additional blocking requests
- Web fonts loaded with default font-display (FOIT blocks paint)
- Forgetting that even small blocking scripts add hundreds of ms on slow networks
Quick Checklist
- Critical above-the-fold CSS inlined in <head>
- Non-critical CSS loaded async
- No synchronous <script> in <head>
- Web fonts use font-display: swap
- Lighthouse "Eliminate render-blocking resources" passes
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
Any CSS or synchronous JavaScript file the browser must download and parse before it can render the page. Each blocking resource adds its download and parse time to your First Contentful Paint metric.
Add async (script can run any time after download) or defer (runs after parse, in order). For third parties, load them after first paint via dynamic import or after the load event.
Inline the critical above-the-fold CSS directly in <head>, then load the rest asynchronously via a preload link with onload swapping the rel from preload to stylesheet.
Yes by default. Use font-display: swap so text renders immediately with a fallback font, then swaps when the web font arrives. Use font-display: optional for the fastest-feeling experience.
Yes. Render-blocking resources directly hurt FCP, LCP and Speed Index — three metrics Google measures and one of which (LCP) is a Core Web Vital ranking input.