What "render-blocking" means
The browser will not paint anything until it has the CSS for the page, because painting unstyled content and then restyling it would be worse. So every stylesheet linked in the <head> blocks the first paint until it has downloaded and parsed. Scripts in the <head> without defer or async block too, because they might change the document.
On a fast connection with a small stylesheet, this costs tens of milliseconds and nobody notices. On a phone on a mediocre connection with four stylesheets, two of them third-party, and a synchronous tag manager, it costs one to two seconds of blank screen, and that shows up directly in Largest Contentful Paint.
The audit line in PageSpeed Insights, "Eliminate render-blocking resources", lists the files and an estimate of the saving. The estimate is rough. The list is the useful part.
The fixes, in order of return
1. Load fewer files
Before optimising how the CSS loads, remove CSS that should not be there. Business sites routinely load a theme stylesheet, a plugin stylesheet per plugin, an icon font's CSS, a slider's CSS on pages with no slider, and a page builder's global CSS. Each is a round trip before paint.
Dequeue what the page does not use. Combine what is left into one file per page type, or let a modern build tool do it. One well-cached stylesheet is the target.
2. Make the CSS smaller
Unused CSS still has to download and parse. A framework's full stylesheet at several hundred kilobytes, of which the page uses ten, is the common case. Tailwind and similar utility frameworks generate only used classes at build time; component-scoped CSS (modules, scoped styles) naturally stays small; a purge step on a legacy stylesheet removes the rest. The Coverage panel in DevTools shows what fraction of each stylesheet a page actually uses.
Minify and compress. Brotli on the server for text assets is a configuration flag and typically cuts CSS by three quarters over the wire.
3. Get scripts out of the way
Any <script> without defer or async in the <head> stops HTML parsing. Add defer to everything that is not truly needed before paint, which is nearly everything. Move analytics and tag managers to load after the page is interactive. Third-party widgets, chat, maps, video, load on interaction or when scrolled into view.
The exception is a tiny inline script that sets a theme class to avoid a flash; that can stay, and should be tiny.
4. Fonts
Web fonts do not block render, but a font that arrives late triggers a text swap, and a font loaded via a third-party CSS file adds a blocking stylesheet plus a connection. Self-host the fonts, preload the one or two used above the fold, and set font-display deliberately. Framework font loaders do all this.
5. Preconnect and preload where it counts
If a critical resource comes from another origin, <link rel="preconnect"> warms the connection. If the LCP image is discovered late (a CSS background, or loaded by a component), <link rel="preload" as="image"> starts it early. Use these for the two or three resources that gate the first paint, not for everything; over-preloading competes with the things that matter.
6. Inline critical CSS, if you still need to
After the above, a single small stylesheet is usually fast enough. If measurements still show a gap, inline the CSS for above-the-fold content in a <style> block in the <head> and load the rest asynchronously. This removes the last round trip before paint.
It has costs: the inlined CSS is not cached between pages, the extraction has to be automated to stay correct, and the async load of the rest can cause a flash of partially styled content if done carelessly. Frameworks with per-route CSS often make it unnecessary. Do it last, and measure that it helped.
How to measure
The metric that responds is LCP, and the intermediate metric is First Contentful Paint. Record a performance trace on a throttled mobile profile before and after. In the network waterfall, look at the gap between the HTML finishing and the first paint marker: that gap is what render-blocking resources cost, and it should shrink with each step.
The audit's "estimated savings" will change too, but the trace is the truth.
On the common platforms
WordPress: a performance plugin handles combining, deferring and critical CSS generation reasonably well; the bigger win is usually dequeuing plugin assets per page, which the plugins do not do and a few lines in the theme do.
Next.js and similar: CSS is per-route and inlined or chunked by the framework; render blocking is rarely the issue. Third-party scripts added via a tag manager are, and belong in the framework's script component with a lazy strategy.
Hosted builders: limited control. Reduce fonts, remove unused apps and embeds, and accept the platform's floor.
Where it fits
Render-blocking resources are usually the second thing we fix after the LCP image itself, and on plugin-heavy WordPress sites they are the first. Both are part of a Core Web Vitals engagement, and both are measured before and after so the improvement is a number, not an audit line turning green.