Why does CSS slow down my page?

Because CSS is render-blocking by default. When the browser encounters a stylesheet link in the head, it must download and parse that CSS before it paints any content, to avoid showing an unstyled flash. A large stylesheet, or one loaded slowly, therefore delays the moment the page first appears (First Contentful Paint) and can delay the main content (Largest Contentful Paint). Reducing and optimising CSS lets the browser start painting sooner.

What is critical CSS?

Critical CSS is the minimal set of styles needed to render the content visible in the viewport when the page first loads — the above-the-fold area. The technique is to extract those styles and inline them directly in the page's head so the browser can paint immediately without waiting for an external stylesheet, then load the full CSS file afterwards in a non-blocking way. This improves First Contentful Paint and Largest Contentful Paint, especially on the first visit.

How do I find unused CSS?

Open Chrome DevTools, press the Coverage tab (via the Command menu or More tools), reload the page, and it shows each stylesheet with the percentage of bytes that went unused on that page. Lighthouse and PageSpeed Insights also include a 'Reduce unused CSS' audit with estimated savings. High unused percentages usually mean a single global stylesheet is shipped to every page, which is a strong candidate for splitting or trimming with a tool that strips selectors not present in the markup.

Should I minify my CSS?

Yes. Minification strips whitespace, comments and unnecessary characters from CSS with no change to how it behaves, reducing file size. Combined with Brotli or Gzip compression at the server or CDN, it meaningfully cuts the bytes the browser has to download. Minification is a standard, automated step in modern build tools, so the main thing to confirm is that your production CSS is actually minified and compressed rather than shipped in its readable development form.

Is @import bad for performance?

Using @import inside a CSS file is bad for performance because it creates a sequential chain: the browser must download the first stylesheet, parse it, discover the @import, then download the next one, and so on. This serialises requests that could otherwise happen in parallel, delaying rendering. It is better to use multiple link tags in the HTML (which the browser can fetch in parallel) or to bundle stylesheets together at build time, avoiding @import in production CSS.

How to Optimize CSS for Faster Pages

CSS has a special power over how fast your page feels, and it is easy to overlook: it is render-blocking. Before the browser will paint a single pixel of content, it must download and process the CSS you have told it about — otherwise it risks showing an ugly flash of unstyled text. That makes a bloated or slow stylesheet a direct brake on how soon your page appears. In short: CSS blocks rendering, so to make pages faster you minify it, remove the rules you are not using, inline the small amount of critical above-the-fold CSS and load the rest without blocking, avoid @import, and keep selectors lean. These changes improve First Contentful Paint and Largest Contentful Paint, the metrics that decide whether a page feels instant or sluggish. This guide explains why CSS blocks rendering and walks through each fix, with a technique-to-benefit table and the tools to find your own problems.

It is one of the critical-path levers in how to make your website load faster.

Why CSS is render-blocking

To understand the fixes, you have to understand the constraint. When the browser parses your HTML and finds a <link rel="stylesheet"> in the <head>, it treats that stylesheet as render-blocking: it will not paint the page until the CSS has been downloaded and parsed into the rules it needs. The reasoning is sound — if the browser painted before the CSS arrived, the user would see a jarring flash of unstyled content (everything in default browser styles) that then snaps into your design a moment later. To avoid that, the browser waits.

The consequence is that the size and speed of your CSS gates your First Contentful Paint — the moment any content appears. If your stylesheet is 400 KB, or is fetched from a slow third-party origin, or is split across several files that load one after another, the user stares at a blank screen for longer. Worse, because the largest visible element cannot paint until styles are applied, slow CSS also drags on Largest Contentful Paint. CSS is therefore not just a styling concern; it sits squarely on the critical rendering path, the sequence the browser must complete before showing meaningful content.

The goal of CSS optimisation is to let the browser get the minimum styles it needs to paint the visible page as fast as possible, and to defer everything that is not needed for that first paint.

The techniques and what they buy you

Technique	What it does	Primary benefit
Minify CSS	Strips whitespace, comments, redundant characters	Smaller download, faster fetch
Remove unused CSS	Deletes rules not used on the page	Smaller file, less parsing
Inline critical CSS	Puts above-the-fold styles in the head	Faster First Contentful Paint
Defer non-critical CSS	Loads the rest without blocking render	Page paints before full CSS arrives
Avoid `@import`	Removes sequential download chains	Parallel fetching, faster start
Reduce specificity/bloat	Simpler selectors and structure	Less style-matching work, maintainability
Use `content-visibility`/`contain`	Skips rendering work for off-screen content	Less layout/paint cost on long pages

The throughline is the same one that runs through all performance work: send less, send it sooner, and do less work with it. Each technique below serves one of those goals.

Minify and compress

The simplest win first. Minification removes everything in a CSS file that the browser does not need: whitespace, line breaks, comments, and redundant characters. A readable stylesheet written with generous formatting can shrink noticeably when minified, with zero change to how it renders. Every modern build tool does this automatically, so the real task is usually just confirming your production CSS is actually minified rather than being served in its development form — a surprisingly common oversight.

Minification pairs with compression. Once minified, the CSS should also be served with Brotli or Gzip, which compresses text dramatically — see what are Gzip and Brotli compression. Minification and compression are complementary: minification removes redundant characters, compression encodes what remains efficiently, and together they make the stylesheet as small as it can be on the wire. Neither requires touching your actual styles.

Remove unused CSS

This is where the big savings usually hide. Most sites ship a single global stylesheet to every page, often inflated by a CSS framework, old features, and styles for components that appear on only a handful of pages. The result is that any given page downloads and parses far more CSS than it uses — sometimes the majority of the file is dead weight for that view.

To find out exactly how much, use the Chrome DevTools Coverage tab: open it, reload the page, and it lists each stylesheet with the percentage of bytes that went unused on that page. A stylesheet showing 70% or 80% unused is a glaring opportunity. Lighthouse and PageSpeed Insights echo this with a "Reduce unused CSS" audit and estimated savings.

The fixes follow from what you find:

Split CSS by route or template so each page loads only the styles it needs, rather than one monolith for the whole site.
Run an unused-CSS tool (such as PurgeCSS or the pruning built into modern build setups) that scans your markup and removes selectors that never appear.
Delete genuinely dead styles — rules for components and pages that no longer exist.
Audit your framework usage: if you use a large CSS framework but only a fraction of its utilities, configure it to emit only what you use (utility-first frameworks like Tailwind do this by scanning your templates).

Removing unused CSS shrinks both the download and the parsing work, and it directly reduces the render-blocking cost on every page.

Inline critical CSS, defer the rest

This is the most impactful technique for perceived speed, and it follows directly from the render-blocking problem. The idea: identify the critical CSS — the minimal styles required to render the above-the-fold content, the part of the page visible without scrolling — and inline it directly in a <style> block in the <head>. Because those styles are now part of the HTML document itself, the browser has everything it needs to paint the visible page immediately, with no wait for an external file.

The rest of the CSS — styles for below-the-fold content, other components, interactive states — is then loaded without blocking rendering, so it arrives and applies after the first paint rather than gating it. A common pattern is to load the full stylesheet with a technique that makes it non-render-blocking (for example, loading it in a way that applies once downloaded, or marking it so the browser deprioritises it), so the page appears fast and the complete styles fill in moments later without the user noticing a gap.

The payoff is a faster First Contentful Paint and often a faster LCP, because the visible content paints without waiting on the entire stylesheet. The trade-off is complexity: extracting critical CSS accurately takes tooling (several build plugins and services generate it automatically by rendering the page and capturing the styles the viewport uses), and the critical set must be kept in sync as the design changes. For many sites, especially those built on frameworks that support it, critical-CSS extraction is automated; for others, it is worth doing manually on the most important templates (homepage, key landing pages) even if not everywhere. Done well, it is one of the clearest improvements you can make to how quickly a page seems to load.

Avoid @import in production CSS

The CSS @import rule looks convenient — it lets one stylesheet pull in another — but it is a performance trap. Because the browser only discovers an @import after it has downloaded and started parsing the stylesheet that contains it, imports create a sequential chain: download stylesheet A, parse it, discover the import, download stylesheet B, parse it, perhaps discover a further import, and so on. Each step waits for the previous one, serialising requests that could otherwise happen in parallel and delaying rendering.

The fixes are straightforward. Either use multiple <link> tags in the HTML, which the browser can fetch in parallel, or — better still — bundle your stylesheets together at build time into one (or a few) files so there is no chaining at all. The rule of thumb: @import is fine as an authoring convenience that your build tool resolves and flattens, but it should never appear in the CSS that actually ships to the browser.

Reduce specificity and selector bloat

Beyond file size, the shape of your CSS affects how much work the browser does to apply it. Deeply nested, highly specific selectors (long chains of descendants, heavy use of !important, sprawling combinators) make the browser's style-matching work harder and, just as importantly, make the stylesheet harder to maintain — which is how unused and duplicated rules accumulate in the first place. While selector performance is rarely the single biggest bottleneck on a typical site, keeping selectors flat and simple has compounding benefits: smaller files, faster matching, and a codebase where it stays obvious what is used and what is not. Favour class-based styling over deep descendant chains, lean on a consistent naming convention or a utility approach, and avoid specificity wars that bloat the stylesheet over time.

Use containment for long pages

Modern CSS offers two properties that reduce rendering work, which are especially useful on long or complex pages. content-visibility: auto tells the browser it can skip the rendering work (layout and paint) for off-screen content until the user scrolls near it, which can dramatically cut the cost of rendering a long page on first load. The related contain property lets you tell the browser that an element's layout, style or paint is independent of the rest of the page, so changes inside it do not force the browser to recompute layout elsewhere. Used thoughtfully — particularly content-visibility on long lists, articles or feed items below the fold — these can meaningfully reduce the main-thread work of rendering without changing how the page looks. They are newer tools, so test across your target browsers, but they are a powerful complement to trimming the CSS itself.

How CSS optimisation ties to Core Web Vitals

It is worth being explicit about the payoff in metric terms, because that is how the work gets prioritised and measured. Optimising CSS primarily improves two things. First Contentful Paint improves because the browser is no longer waiting on a large or slow stylesheet before it can paint anything — inlined critical CSS and a smaller, faster-loading file let content appear sooner. Largest Contentful Paint improves because the largest visible element cannot render until styles are applied, so removing render-blocking CSS delay lets that element paint earlier. CSS optimisation has little direct effect on INP (which is dominated by JavaScript execution) or on CLS unless late-loading CSS is causing reflows — though it is worth noting that loading critical styles early actually helps stability by ensuring the page is laid out correctly from the first paint. To see how all these metrics fit together and what counts as good, read Core Web Vitals explained.

A worked example

Suppose PageSpeed Insights flags "Reduce unused CSS" and "Eliminate render-blocking resources", both pointing at a single 350 KB site-wide stylesheet, and your FCP is slow. You open the Coverage tab and confirm the stylesheet is 78% unused on the homepage — it carries styles for the whole site. You take three steps. First, you run an unused-CSS pass that prunes the stylesheet against the homepage markup, cutting it to a fraction of its size. Second, you extract the critical above-the-fold CSS and inline it in the <head>, loading the remaining styles non-blocking. Third, you confirm the production CSS is minified and served with Brotli. After deploying, the browser paints the visible page almost immediately from the inlined styles, the render-blocking warning clears, and FCP and LCP both improve in the field. As with most performance work, a couple of targeted changes against the biggest offender deliver the bulk of the gain.

A practical checklist

Confirm minification and compression are active on production CSS.
Run the Coverage tab to measure unused CSS per page; note the worst offenders.
Remove or split unused CSS — prune with a tool, split by route, trim framework output.
Extract and inline critical CSS for key templates; load the rest non-blocking.
Remove @import from shipped CSS in favour of parallel <link>s or bundling.
Flatten selectors and reduce specificity bloat as you maintain the codebase.
Apply content-visibility to long off-screen sections where supported.
Re-measure FCP and LCP in the field after each change.

Common mistakes

Shipping one giant stylesheet to every page, most of it unused on any given view.
Leaving CSS render-blocking when critical-CSS inlining would let the page paint sooner.
Using @import in production, serialising downloads that could be parallel.
Forgetting to compress minified CSS, leaving easy byte savings unclaimed.
Optimising CSS but ignoring JavaScript, which is usually the larger drag — see how to reduce JavaScript and speed up your site.

Go deeper

The big picture, in priority order: how to make your website load faster.
The metrics CSS optimisation improves: Core Web Vitals explained.
Compress what you ship: what are Gzip and Brotli compression.
The bigger drag on most sites: how to reduce JavaScript and speed up your site.

Want to see your render-blocking resources and CSS weight, alongside SEO and security? Analyse any URL with StackOptic — free, no sign-up.