CSS

The problem

An image of 200 KB and a stylesheet of 200 KB download in the same time. After that they have nothing in common. The image is decoded and drawn. The stylesheet has to be parsed into thousands of rules and then matched against every element on the page, and it stops the page from painting until that’s done.

CSS is also the one thing that gets quietly re-run. Change a class and the browser may have to work out again which rules apply to thousands of elements. That’s where a small change on a big page turns into a dropped frame.

Things to try

1. Look at the image row. The download is identical. The main-thread work isn’t.
2. Add @import levels. Each one waits for the one before it, so you pay a round trip per level before rendering can even start.
3. Make selectors harder. Switch from single classes to universal or :has() selectors and watch the style cost multiply.
4. Grow the page. Drag the element count up. The style cost scales with it.
5. Compare the two class changes. The same toggle costs milliseconds inside a component and hundreds on <html>. The dashed line is a frame.
6. Split the media CSS. Tick the box to move print and other-media styles out of the blocking path.

How the browser handles CSS

• Parse. The text becomes a structure of rules. This happens on the main thread, and a stylesheet in <head> must finish before anything is painted (Experiment 05).
• Match. For each element the browser finds the rules that apply. Rules are bucketed by id, class and tag so it doesn’t test every rule against every element. That’s why doubling the rules doesn’t double the cost, but doubling the elements does.
• Invalidate. When a class, attribute or the DOM changes, the browser works out which elements might be affected and re-matches just those. A change near the root can affect everything below it.
• Layout and paint follow for whatever changed. Changing a property that affects size and position triggers layout; transform and opacity usually don’t.

Selector micro-optimisation is rarely the answer. Modern engines match selectors quickly, and a short, readable selector is worth more than a theoretically faster one. The costs that matter are how much CSS you ship, how big the DOM is, and how widely a change spreads. Measure before rewriting selectors.

What helps

• Ship less. DevTools Coverage shows how much CSS a page never uses. Remove it, or split it by route or component.
• No @import. Use <link> tags (they download in parallel) or let your bundler combine files.
• Split by media. <link rel="stylesheet" href="print.css" media="print"> doesn’t block rendering on screen.
• Inline the critical CSS for the first view and load the rest without blocking (Experiment 05).
• Scope changes. Toggle a class on the component, not on <html> or <body>, especially in code that runs often.
• Keep the DOM small. Every element is matched against the rules.
• Skip off-screen work with content-visibility, below.

content-visibility and containment

.card {
  content-visibility: auto;
  contain-intrinsic-size: auto 120px; /* a guess at the height until it has been rendered */
}

• With auto, the browser skips rendering work for elements well outside the viewport and does it as they approach it. The content stays in the DOM, so find-in-page and accessibility tools still see it.
• It helps on long pages made of many independent sections: feeds, articles, listings. It does little for a short page, and the work is deferred to scrolling, not removed.
• Without contain-intrinsic-size, a skipped element has no height, so the scroll bar jumps as things render. The auto keyword remembers each element’s real size once it has been shown.
• contain is the related tool: it promises the browser that a component’s layout, style or paint doesn’t affect the rest, so changes inside it can be handled in isolation. Measure the effect on your page before assuming it helps.
• Support: Chromium has had content-visibility since 2020, and Firefox 125 and Safari 18 added it in 2024. Check support for your audience. It degrades to normal rendering where it isn’t supported.

Common misconceptions

See it on a real page

1. In DevTools open Coverage, reload, and sort by unused bytes for each stylesheet.
2. In the Performance panel, find Recalculate Style events. Their duration, and the “elements affected” count in the details, tell you how wide a change reached. Chrome can also record per-selector statistics from the Performance settings.
3. In Network, look at the waterfall for a staircase of CSS requests: that’s an @import chain.
4. Lighthouse’s “Reduce unused CSS”, “Eliminate render-blocking resources” and “Avoid chaining critical requests” audits point at the same causes.

Model assumptions