The 80/20: Fix CSS delivery before you rewrite CSS

Fix 01
Put CSS in the <head> (and keep it discoverable)

Browsers can only fetch what they discover. If your styles are injected late or only discovered after something else, your first render slows down. Keeping critical styles referenced in the document head is still the clean baseline for optimizing CSS for web performance, because it reduces late discovery and helps the browser start work earlier.

HTML 
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>CSS Discoverable Early</title>

  <!-- CSS is discovered while parsing the <head> -->
  <link rel="stylesheet" href="/css/styles.css">
</head>
<body>
  <h1>Styled on first render</h1>
  <p>The browser finds the CSS immediately.</p>
</body>
</html>
Fix 02
Avoid @import in production CSS

@import inside CSS creates late-discovered, consecutive request chains because the browser must download the parent stylesheet before it can even see the import. It also can't be discovered by the preload scanner.

Use <link rel="stylesheet"> instead so stylesheets can be discovered earlier and fetched more predictably.

Fix 03
Inline critical CSS (selectively) to speed first paint

Inlining "above-the-fold" styles in the <head> can remove an early network dependency and improve initial rendering — especially on a cold cache. The tradeoff: more HTML bytes and less caching for those rules, so it must be measured.

Practical approach that scales:

  • Inline only the CSS needed for the initial viewport (header, nav, hero, typography).
  • Load the rest as a normal stylesheet (or split by route/template).
HTML 
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Fast CSS Discovery Example</title>

  <!-- CSS is discovered immediately during HTML parsing -->
  <link rel="stylesheet" href="/css/styles.css">

  <!-- Optional: critical inline CSS for above-the-fold content -->
  <style>
    body {
      margin: 0;
      font-family: system-ui, sans-serif;
    }

    header {
      background: #0a66c2;
      color: white;
      padding: 1rem;
    }
  </style>
</head>
<body>
  <header>
    <h1>Fast Rendering Page</h1>
  </header>

  <main>
    <p>Content renders styled on first paint.</p>
  </main>
</body>
</html>
Fix 04
Use Lighthouse's "render-blocking resources" audit as a starting compass

Chrome's Lighthouse explains why CSS blocks rendering and what to do about it. It's not perfect, but it's a fast way to find the biggest offenders and verify improvements.

"Do this now" checklist
  • Remove CSS @import in shipped CSS (keep it in preprocessors only if bundled).
  • Keep primary styles discoverable in <head>.
  • Inline truly critical CSS (measure the win vs. HTML weight).
  • Re-test with Lighthouse + field data (see FAQ below).

FAQ

Does Google rank sites directly based on Core Web Vitals?

Google documents page experience signals (including Core Web Vitals) as part of the overall ranking picture, while also emphasizing relevance remains key.

Is inlining critical CSS always good?

No — inline CSS can speed initial render, but it increases HTML size and reduces caching benefits. It's worth it in some architectures, not all.

Should I split CSS files or keep one bundle?

If a single CSS bundle contains lots of unused rules per template, splitting often improves initial render by reducing download + parse work.

Author: Elena David  ·  Last Updated: February 2, 2026
web.dev — Optimize resource loading → Google Search Central — Page experience →