# Critical CSS: is it still worth doing in 2026? > Critical CSS inlines the styles for the first screen and loads the rest later. Learn when it still pays, what it costs to maintain, the simpler fixes to try first and how to measure the difference. Updated 2026-09-25 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/critical-css-worth-it-in-2026 Critical CSS was the answer to a specific problem: every stylesheet in `` stops the browser from drawing anything, and on a slow connection a 200 KB stylesheet meant two seconds of blank screen. The fix was to inline the few rules the first screen needs and load the rest without blocking. Ten years later, HTTP/2, smaller bundles and `preload` have changed the maths, and the tooling has a reputation for breaking layouts. This guide says when it still pays, what it costs, what to try first, and how to measure the difference on your own page. ## Quick answer | Your situation | Do this | | --- | --- | | One or two stylesheets under 50 KB compressed, HTTP/2 on | Skip critical CSS. Preload the main stylesheet and stop. | | A page builder or theme shipping 200 KB+ of CSS on every page | Remove unused CSS first; then, if First Contentful Paint is still over 1.8 s on mobile, add critical CSS. | | Marketing landing pages, slow mobile field data, one template | Worth it: one template, large payoff, low maintenance. | | A site with many templates and frequent design changes | Usually not: the extraction goes stale and the bugs cost more than the 200–500 ms. | Whatever you decide, measure with the [speed test](https://getreport.app/tools/speed-test) before and after: the render-blocking finding shows the stylesheets and the estimated savings. ## Why critical CSS matters ### The problem it solves A browser will not paint a page until it has downloaded and parsed every stylesheet linked in ``, because any of them could change how the first pixel looks. On a fast connection that wait is tens of milliseconds. On a phone on a 4G connection with a slow first byte, one 150 KB stylesheet can be 500–1,000 ms of blank screen, and First Contentful Paint, Speed Index and Largest Contentful Paint all start after it. Critical CSS breaks the dependency. The rules that style the visible part of the page (header, hero, first paragraph) are copied into a ` ``` The `preload` downloads the file at high priority without blocking; the `onload` handler turns it into a real stylesheet once it is there; the `

` line, so keep it. Without it, a JS error before the stylesheet swaps in leaves the page half-styled for everyone. ### 3. Keep fonts and layout-critical rules in the inline block Anything that changes the size of above-the-fold elements must be in the critical block: the grid, the hero's `min-height` or `aspect-ratio`, the heading sizes. Leave it out and the page reflows when the full stylesheet lands, which is the layout shift the finding warns about. Fonts are the exception: keep `@font-face` external and preload the one file the headline uses. ### 4. Regenerate on every CSS change Wire the extraction into the deploy, or into the plugin's cache purge (WP Rocket and LiteSpeed regenerate their critical CSS when you clear the cache). A stale critical block is worse than none. ## Decision table | Signal in the report | Decision | | --- | --- | | Render-blocking finding lists scripts only | Add `defer`; no critical CSS needed | | Stylesheets under 50 KB total, estimate under 300 ms | Preload the main file; skip critical CSS | | Stylesheets over 150 KB and unused CSS over 70 % | Remove unused CSS first, re-test | | After removal, mobile FCP still over 1.8 s, one or two templates | Add critical CSS for those templates | | Many templates, design changes weekly | Split per template, preload, accept the round trip | | TTFB over 800 ms | Fix the server first; CSS is not the bottleneck | ## Platform notes ### WordPress Use one plugin for CSS delivery, not two. WP Rocket, LiteSpeed Cache and Autoptimize each rewrite the `<link>` tags; two of them together produce stylesheets loaded twice or a `<noscript>` block that references the wrong file. Exclude the builder's above-the-fold styles from "Remove Unused CSS" if the hero renders unstyled, and test logged-out, because the extraction runs as an anonymous visitor. ### Shopify Themes ship a base stylesheet plus per-section CSS, and the platform serves it over HTTP/2 from a CDN. There is no supported way to inject critical CSS into `theme.liquid` without maintaining it by hand on every theme update, and the gain is small. Reduce app scripts instead; they are usually the larger blockers. ### Static sites and frameworks Astro, Next.js and Nuxt can inline the component-scoped CSS of the current route at build time (by default or with one build option, depending on the version), which is critical CSS without the extraction step. Check the render-blocking finding after enabling it; the framework's global stylesheet may still be a separate blocking file. ## Verify - Run the speed test before the change and keep the link. After the change, the render-blocking finding should no longer list the main stylesheet, and the lab FCP should be earlier by roughly the estimate. - Open the page on a throttled connection in DevTools (Network → "Slow 4G") and watch the first paint: styled header and hero, no unstyled text, no jump when the full stylesheet arrives. - Cumulative Layout Shift in the lab table did not go up. If it did, a layout rule is missing from the inline block. - Switch off JavaScript in DevTools and reload: the page is still styled, via the `<noscript>` fallback. ## Common mistakes - **Critical CSS on top of 200 KB of unused CSS.** Symptom: FCP improves, Speed Index and total bytes do not. Fix: remove unused CSS first; the inline block becomes smaller too. - **Extraction from the desktop viewport.** Symptom: mobile pages render unstyled below the header. Fix: extract at a phone width (about 412 px) or both, and keep the union. - **Stale critical CSS after a redesign.** Symptom: the page flashes an old layout and then reflows; CLS rises. Fix: regenerate on deploy or on cache purge, and check the finding after every CSS change. - **No `<noscript>` fallback.** Symptom: unstyled page for a visitor with scripts blocked or a JS error early in the page. Fix: add the fallback line under the preload. - **Inlining the whole stylesheet.** Symptom: a 120 KB HTML document, nothing cached, every page view pays again. Fix: keep the inline block under about 14 KB and load the rest deferred.