Critical CSS for Faster Pages: When It’s Worth the Work

By Greg Nowak. Reviewed 5 August 2026.

Critical CSS is the small set of styles needed to render the first visible part of a page. Putting those rules directly in the HTML can let the browser show useful, properly styled content without waiting for a large global stylesheet.

That sounds attractive, but it is not a default recommendation for every website. Critical CSS adds another generated asset, another release step, and another place for a template change to cause a visual bug. The business question is whether removing CSS from the critical rendering path will noticeably improve pages that generate enquiries, sales, bookings, or readership.

Decide from evidence, not a performance score

Chrome’s current guidance describes CSS inlining as an advanced technique and notes that most sites should be able to meet recommended performance targets without it. Start with the actual bottleneck.

What the evidence shows	Recommended decision	Next action
Render-blocking CSS delays first paint or the LCP element on several valuable templates	Use critical CSS	Automate it by page family and test mobile and desktop output
A large shared stylesheet is present, but images, fonts, scripts, and server time also contribute	Run a limited pilot	Test one stable service or landing-page template before expanding the scope
Slow server response, an oversized hero image, JavaScript execution, or third-party code dominates	Defer critical CSS work	Fix the larger constraint and measure again
CSS is already small and cached, or every page has a different first screen	Probably skip it	Keep delivery simple unless field data identifies a real problem

A practical decision matrix for choosing whether critical CSS belongs in the next performance sprint.

Prove that CSS is holding the page back

Test representative anonymous pages in PageSpeed Insights, Lighthouse, Chrome DevTools, or WebPageTest. Do not judge the homepage alone. Check a high-traffic article, a service page, a campaign landing page, an ecommerce category, and any template containing a prominent form.

Use the network waterfall and the render-blocking requests insight to see whether stylesheets delay the first render. Inspect the Largest Contentful Paint element as well: if it is an image still being transferred, CSS extraction will not solve the main delay.

Compare laboratory tests with real-user data. Google’s current Core Web Vitals remain LCP for loading, INP for responsiveness, and CLS for visual stability. Critical CSS primarily targets rendering and LCP. It will not repair slow interactions, and incomplete first-screen styles can make layout stability worse.

Keep the critical layer deliberately small

Include the layout, typography, header, navigation, hero, visible buttons, and above-the-fold form controls required for the first screen. Include rules that reserve the correct space for visible media. Test narrow and wide viewports because navigation and grid rules often change at breakpoints.

Leave out footers, below-the-fold components, editor interfaces, rare utilities, animations, and widgets that do not appear immediately. Be careful with fonts and background images: extracting every related rule can make the inline block surprisingly large.

Inlining also repeats CSS in every HTML response instead of benefiting from a separately cached file. The goal is the smallest dependable first-screen layer, not moving the entire stylesheet into the document.

Make generation part of the release process

Manual files go stale as soon as somebody changes a header, campaign component, or breakpoint. Generate critical CSS from the same rendered templates and assets that will be deployed.

The current critical package provides a concise command-line workflow:

pnpm add -D critical
npx critical ./dist --inline --write --dimensions 390x844,1280x900

This processes built HTML, inlines the selected rules, and defers the remaining stylesheets. The current release requires Node.js 22.13 or newer. Its automatic mode can inspect server-rendered markup without launching a browser; JavaScript-rendered application shells may require the optional Playwright-based rendering engine.

For a CMS, generate against stable page families rather than every URL. Your test set should cover optional banners, navigation states, cookie notices, editor-controlled blocks, validation messages, and pages with or without a hero. A visual regression check is valuable because a technically successful build can still omit a runtime class.

Use Drupal as the delivery layer

Drupal’s critical_css module remains available as a stable, security-covered release for Drupal 9, 10, and 11. Install its current 2.x line with:

composer require 'drupal/critical_css:^2.0'

The module finds an appropriate critical CSS file in the active theme, places it in the page head, and handles the remaining head CSS asynchronously. It does not generate that file. Your build or deployment process must still produce accurate CSS for the relevant bundle, entity, URL, or default template.

Drupal.org marks the project as feature-complete with maintenance fixes only. That is not automatically a reason to avoid it, but it is a reason to test logged-in states, AJAX responses, aggregation settings, and theme changes instead of treating installation as the finished job.

Reduce old CSS carefully

If a global stylesheet contains years of unused selectors, remove that waste as a separate task. PurgeCSS can identify unused rules, but CMS templates and JavaScript often construct class names dynamically. Safelist predictable runtime prefixes and review rejected selectors during rollout:

import { PurgeCSS } from 'purgecss';

const results = await new PurgeCSS().purge({
  content: ['templates/**/*.html', 'src/**/*.js'],
  css: ['dist/app.css'],
  safelist: [/^is-/, /^has-/, /^js-/],
  rejected: true
});

Test menus, modals, forms, error messages, personalised blocks, and campaign components before shipping the reduced file.

Measure the release like a business change

Record before-and-after waterfalls and Lighthouse runs under the same conditions. Then monitor real-user LCP and CLS by template once enough visits have accumulated. Also confirm that calls to action become visible and usable sooner and that the release has not introduced flashes of unstyled content.

The right outcome is not “critical CSS installed.” It is a faster, stable page with a maintenance cost the team understands. If you want an independent assessment of the bottleneck and the safest implementation route, Greg can help scope the performance work across templates, Drupal, front-end delivery, and conversion-critical pages.

Related on GrN.dk

Need help with this kind of work?

Discuss your website performance priorities with Greg Get in touch with Greg.

Sources

Last modified

2026-08-12