Stylesheets and scripts stop the page from rendering

MediumHigh confidenceQuick winperf.lab.render-blocking-resources

What this check looks for

‹count› resource(s) on this page must be downloaded and processed before the browser is allowed to draw anything. Removing them from the critical path would save an estimated ‹savings ms›.

Why it matters

While these are in flight the visitor sees a blank screen. This is usually the single largest, cheapest win available on a slow page, because the files rarely need to block at all.

When the check passes, your report says: “Nothing in the critical path holds up the first paint”.

What it costs your score

When this check fails it removes 10 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.render family ceiling of 10 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: high
Status when triggered: warn
Deduction: 10 points
Family cap: performance.render · 10
Category: Performance
Module: Perf lab
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Take stylesheets and scripts off the critical rendering path.

The browser is currently forbidden from drawing anything for an estimated ‹savings ms› while it fetches and processes files that mostly do not need to block.

Add defer to every <script> in the <head> that does not have to run before parsing continues; type="module" defers by default. Use async only for genuinely independent scripts, since it can still interrupt the parser.
Inline the small amount of CSS the above-the-fold content needs, and load the rest with a non-blocking pattern so it applies as soon as it arrives.
Split stylesheets by media where they apply conditionally — media="print" and unmatched media queries do not block rendering.
Delete what is unused. Most render-blocking CSS on a typical site is a framework bundle of which a few percent is used on the page.
Move third-party widgets — chat, analytics, tag managers — below the critical path entirely; they are frequently the blocking resources.

How to confirm it worked

Re-run this scan and confirm the render-blocking count has dropped.
In Chrome DevTools, Network → filter by 'Doc, CSS, JS' and check nothing before the first paint marker is marked as blocking.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Page HTML

<!-- Blocking the parser. -->
<script src="/app.js"></script>

<!-- Not blocking: runs after parsing, in document order. -->
<script src="/app.js" defer></script>

<!-- Non-critical CSS, loaded without blocking the first paint. -->
<link rel="stylesheet" href="/rest.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/rest.css"></noscript>

The media="print" swap is a well-worn trick, not a hack the browser dislikes: a stylesheet whose media does not match is fetched at low priority and never blocks rendering. The <noscript> fallback keeps the page styled with JavaScript disabled.

Technical detail

Render-blocking resources found: ‹count›, estimated saving **‹savings ms›**.

‹detail›

This came from **one page load we performed**, not from your visitors. A lab measurement is reproducible and tells you exactly which bytes and which resources are responsible — which is why the numbers below are byte counts and resource lists rather than a score. What real visitors experience is in the field-data section, which is the evidence this report scores Core Web Vitals on.

A <link rel="stylesheet"> in the <head> blocks rendering by design: the browser will not paint until it knows the styles, or it would flash unstyled content. A <script> without defer, async or type="module" is worse — it blocks the **parser**, so nothing after it in the document is even discovered until the script has downloaded and executed.

The estimated saving is our model of how much sooner the first paint would occur if the resource were not on the critical path. Treat it as a ranking signal between opportunities rather than a promise of a specific number of milliseconds.