Stylesheets and scripts stop the page from rendering

MediumConfirmedQuick winperf.assets.render-blocking-resources

What this check looks for

‹count› resource(s) in the head of this page must be downloaded and processed before the browser is allowed to draw anything. Until they arrive, the visitor sees a blank screen.

Why it matters

This is usually the single largest and cheapest win available on a slow page, because the files rarely need to block at all — most of them are one attribute away from not blocking.

When the check passes, your report says: “Only what the first paint needs sits on the critical path”.

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: confirmed
Status when triggered: warn
Deduction: 10 points
Family cap: performance.render · 10
Category: Performance
Module: Perf assets
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 until ‹count› files in the head have arrived and been processed, and most of them 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 — off 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.
curl -sS https://‹host›/ | sed -n '/<head/,/<\/head>/p' — every <script src> in the output should carry defer, async or type="module"
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›.

‹summary›

‹detail›

**How this was measured, and what it could not see.** We fetched the page and then the subresources its HTML declares, and read what the server sent back. No browser was involved, so nothing here depends on how fast our machine is — but equally, **a resource that a script loads after the page arrives is invisible to this check**. A page that assembles its own asset list at runtime will look lighter here than it is. The number of subresources the page declared, and how many of those we asked about, are both stated in the page-weight finding; where they differ, this section examined a prioritised sample rather than the whole page.

**How each one was classified.** Two element shapes block, and both are defined by the HTML specification rather than by a judgement of ours. 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 src> in the <head> with neither defer nor async and without 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. A module script is deferred by default and is not counted.

**What is deliberately not counted.** A stylesheet carrying a media condition we cannot evaluate without a viewport — anything other than no media, all or screen — is set aside rather than counted, and the page-weight finding says how many. It may still block on some devices. A <script> in the <body> is also not counted: it does block the parser where it sits, but by then the browser has usually painted, and flagging it would contradict the advice on this very page to move scripts there.

**We report no millisecond figure for this.** How long a blocking resource delays a paint depends on the visitor's connection and device, and a number measured on ours would be a fact about us. The file list and its sizes are what you can act on.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the perf assets checker