CSS Performance Overview

CSS performance is easy to underrate because CSS files are usually small compared to JavaScript bundles or images. But CSS sits in a uniquely powerful position in the browser's rendering pipeline: it's render-blocking by default, it can force expensive layout recalculations, and the wrong property animated in the wrong way can make an otherwise fast page feel janky. "Just make the file smaller" is only a small part of the real picture — this section covers the mechanisms that actually determine how fast a page feels once CSS is involved.

What this section covers

Topic	What it addresses
Critical CSS	Inlining just enough CSS to render above-the-fold content immediately, deferring the rest
Repaints & Reflows	Which CSS changes are cheap (paint-only) vs. expensive (full layout recalculation)
will-change	Hinting the browser to prepare an optimization ahead of a change, and the risk of overusing it
CSS Containment (contain)	Isolating an element's rendering so changes inside it don't ripple out to the rest of the page
content-visibility & intrinsic-size	Skipping rendering work for off-screen content entirely until it's about to be needed
Selector Performance	How much (or how little) selector complexity actually matters in modern engines
Font Loading Performance	Controlling how and when web fonts swap in, avoiding invisible text and layout shift

Why CSS performance goes beyond file size

A handful of distinct mechanisms are worth keeping in mind, each covered in more depth on its own page:

Render-blocking behavior. By default, a browser won't paint any content until it has fetched and parsed all linked stylesheets in the <head>. A large or slow-loading CSS file delays first paint for the entire page, not just the parts that file actually styles.

Layout thrashing. Certain CSS property changes force the browser to recompute the geometry of potentially many elements on the page (a "reflow"), which is dramatically more expensive than a change that only affects pixel color (a "repaint"). Triggering many reflows in a short span — especially inside a scroll or resize handler — is one of the most common sources of visible jank.

GPU compositing. Some properties (transform, opacity) can be animated entirely on the GPU's compositor thread, without touching layout or paint at all — which is why they're dramatically smoother to animate than properties like width or top.

Measure before optimizing

Every technique in this section (critical CSS, containment, content-visibility) trades some build or runtime complexity for a performance gain. Before reaching for any of them, use the browser's Performance panel to confirm where time is actually going — CSS-driven jank and slow first paint have very different fixes, and guessing wrong wastes effort on the wrong problem.

Read the pages in this section in order

The topics build on each other conceptually — reflow/repaint mechanics explain why will-change and contain exist, and contain is itself the foundation that content-visibility builds on. Reading them in the table order above will make each subsequent page click faster.