Render-blocking resources

Render-blocking resources are the files, almost always CSS and synchronous JavaScript in the <head>, that the browser must download and process before it will paint a single pixel. They sit directly on the critical rendering path, so however fast the rest of your page is, the first paint cannot happen until they finish. “Eliminate render-blocking resources” is one of the most common opportunities PageSpeed Insights flags.

Why the browser blocks at all

It blocks on purpose, for two different reasons:

CSS blocks rendering. Painting before the styles are known would show a flash of unstyled content, then a jarring re-layout. So the browser waits for every blocking <link rel="stylesheet"> before it paints.
Synchronous <script> blocks parsing. A plain <script src> in the <head> stops HTML parsing entirely while it downloads and executes, because the script might rewrite the document. Everything after it waits.

Stack a few of these and the browser spends the first crucial second fetching files instead of showing the visitor anything.

CSS or JavaScript depends on who built the site

Both kinds block, but which one dominates is close to a platform signature. From our snapshot of audited sites (2026-07-23), the share where we found blocking scripts against blocking stylesheets:

Platform	Blocking scripts	Blocking stylesheets
Wix	30 of 30	0 of 30
Duda	49 of 49	4 of 49
Squarespace	33 of 37	36 of 37
Webflow	24 of 32	31 of 32
WordPress	14 of 57	52 of 57

WordPress inverts the pattern the hosted builders set: its scripts are mostly already deferred by themes and plugins, while its <head> fills with stylesheets, one per plugin. So the advice that helps a WordPress site is close to useless on a Duda one, and vice versa. These are the sites we chose to audit, not a sample of the web.

Taking them off the critical path

The goal is not to delete these files. It is to stop them gating the paint:

CSS → inline the Critical CSS for the first screen and load the rest asynchronously, by requesting it as a print stylesheet and flipping it to all on load.
JavaScript → add defer or async so the script no longer blocks parsing, and hold non-essential third-party scripts until the visitor interacts.
Fonts → add font-display: swap so text paints in a fallback instead of waiting on the web font.

What it costs to unblock

Each of those moves buys the paint at somebody else’s expense: inlined CSS grows the document the server sends first, async stylesheets can flash unstyled content, and deferred scripts run later than an author who assumed in-order execution expected. The budget-and-cap approach we take on our own pipeline exists because doing all three at maximum strength reliably breaks something.

How WebSpeed handles it

Our pipeline targets exactly this audit: it inlines critical CSS, converts blocking stylesheets to async loading where that is safe, defers non-critical and third-party scripts, and adds font-display: swap. Because the <head> stops blocking, the first paint fires on the first response instead of after a chain of round-trips, which is why proxied pages typically gain most on FCP and LCP.