Render-blocking resources.

Render-blocking resources are the style and script files the browser cannot do the first paint without downloading and processing.

Before painting a page, the browser needs two things: the document’s structure and the styles to apply to it. With styles missing it does not paint — because what it painted could change completely a moment later, and the user would see a “flash of unstyled content.” Stylesheets are therefore blocking by definition.

Scripts block for a different reason: a classic script tag halts document parsing, because the script may modify the document. Not knowing what will happen, the browser waits.

Three kinds of blocking

1. The stylesheet — always blocking. Constrained by a media query, it does not block while that condition does not apply.
2. The synchronous script — halts parsing through both download and execution. The most expensive.
3. The deferred script — download in parallel, execution after the document is ready. Does not block and preserves order.
4. The async script — download in parallel, execution the moment it arrives. Does not block but guarantees no order.
5. The module script — behaves deferred by default.

The practical rule: no script should be synchronous. The exception is a very small piece of code that directly affects the first paint and whose delay would produce a visual jump — and even that can usually be solved another way.

On the style side, removing the blocking is impossible; reducing it is possible. Two paths: lowering the file count and lowering the file size.

Measured and closed on this site

On this site the blocking was measured and closed; the process is on record. In the mobile Lighthouse run, two separate stylesheets were blocking render: one for 821 milliseconds, the other for 221. Two files meant two requests.

The first fix was merging: the two files were gathered into one and the request count fell from two to one. The second was stripping — a notable share of the source file was comments, and comments should not reach the user.

The measured result: 67.4 kilobytes of source, 12.4 after gzip. An 11.4-kilobyte gain on the render-blocking file. The stripping was deliberately kept conservative — only comments and indentation; selectors and values were never touched.

The rationale for the conservatism was measured too: aggressive stripping gained only 747 more bytes and carried the risk of breaking descendant-pseudo patterns. Gain and risk were put side by side and the decision made.

You do not risk breaking a selector for 747 bytes — the gain is measured, and so is the risk.

Third-party blockers

After optimizing your own resources, the largest remaining blocker is usually someone else’s code. Tag managers, font providers, A/B testing tools and chat bubbles — all are usually added synchronously and at the top of the page.

These scripts also go to an external domain, carrying the cost of an extra DNS resolution and an extra connection setup. On most sites the total cost exceeds that of the site’s own stylesheets.

On this site there are no third-party scripts, and the content security policy blocks external resource requests anyway. The decision is as much about privacy as performance — and the verification suite measures that no external request is made at page open.

Measurement and audit

Finding the render-blocking resources takes a few minutes and needs no special tool. The browser’s performance panel lists the resources arriving up to the first paint; every stylesheet and synchronous script on that list is a blocker.

1. How many stylesheets come down — more than one is a merge candidate.
2. Any synchronous scripts — can they become deferred or async?
3. Any external domains — each one costs extra resolution and connection.
4. Are media queries used — a print-only stylesheet must not block the screen.
5. Is compression on — is the server really sending compressed?

The fourth item is a cheap win: styles needed only under certain conditions, with the condition declared, are downloaded by the browser at low priority and do not block the paint. Print styles are the classic example.

The fifth item is not to be assumed. Cases where compression is believed on but is not are common — especially in custom server configurations. The check takes a one-line request, and the effect covers all text resources.

On this site the styles sit in one file, the scripts are deferred, there are no external resources, and the content security policy blocks external requests anyway. All five checks are closed at the configuration level.

A practical checklist

Turning this page into an audit step, here is what to check for blocking resources. The list is kept short because long lists do not get walked; six items fit in one sitting.

1. How many resources come down before the first paint?
2. Any synchronous scripts — there should be none.
3. Is the stylesheet count one?
4. Any requests to external domains?
5. Any styles that could be constrained with a media query?
6. Is compression really on?

On this site all six checks are closed at the configuration level: a single stylesheet, deferred scripts, no external resources, and a content security policy that blocks external requests anyway.

Compression is not assumed on; it is measured.

An ordering suggestion to close: cleaning the render blockers should be performance work’s first step, because its effect goes straight to the first paint and its cost is low. Image optimization and code splitting are more visible jobs, but if the first paint is already blocked, both have limited effect.

And a maintenance note: the blocker count grows over time. A new font, a new analytics script, a new stylesheet — each looks small on its own, and together they drag the first paint back. The checklist should therefore not be walked once and dropped; it should be bound to a test so the growth shows at deployment time.

One last technical note: there are ways to make a stylesheet non-blocking, but each carries a trade-off. Loading a style late means the content it would style appears unstyled for a while — and a flash of unstyled content can disturb more than a slow load. No style touching the first visible area should therefore be deferred; deferral makes sense only for styles used deep in the page.