Eliminate Render-Blocking Resources
Before a browser can paint anything, it has to finish downloading and parsing the CSS and JavaScript referenced in the page's <head>. If those files are large, slow to fetch, or simply not needed for the first screenful of content, the browser sits idle while the user stares at a blank page. That's what PageSpeed Insights and Lighthouse mean by "render-blocking resources."
What it means
By default, a <link rel="stylesheet"> and a plain <script> tag both block rendering: the browser must fetch and process them before it can build the render tree and paint pixels. Lighthouse flags every stylesheet and synchronous script it finds in the critical path, along with the milliseconds each one delays first paint.
Why it matters
Render-blocking resources push out First Contentful Paint (FCP) directly, and in most layouts they also delay Largest Contentful Paint (LCP) because the LCP element cannot be painted until the blocking CSS has been applied. This is one of the most common root causes of a poor LCP score, and because LCP is a Core Web Vital, it also has a documented effect on Google's page experience ranking signal.
How to fix it
The fix is not "remove all CSS and JS" but "control what blocks the first paint and what doesn't":
- Inline the small amount of CSS needed to render above-the-fold content directly in the
<head>, so there's no extra round trip for it. - Load the rest of your stylesheet without blocking, using the classic media-attribute trick, then swap it to "all" once it has loaded. This works best combined with trimming the stylesheet down to the rules the page actually needs in the first place, so there's less to parse either way.
<link rel="stylesheet" href="/main.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/main.css"></noscript>- Add
defer(orasyncfor independent scripts) to script tags that don't need to run before the page paints:
<script src="/app.js" defer></script>- Split large bundles so the first paint only waits on the code that screen actually needs; ship the rest on demand (see reducing unused JavaScript).
rel="preload"a genuinely critical asset, such as a hero font, so the browser starts fetching it earlier without blocking the parser.
How to verify
Re-run the test after deploying the fix. The render-blocking-resources audit should show a much smaller "potential savings" figure, or disappear entirely, and FCP/LCP in the lab data should drop by roughly the same amount.
Test your site
Run a free scan to see whether this audit applies to your pages, on mobile and desktop, with lab and field data side by side.
Run a free test