Why style recalculation slows your page down

When JavaScript changes the DOM — adding or removing elements, altering attributes or classes, or running animations — the browser must recalculate element styles and often reflow part or all of the page. This style calculation process has two phases: the browser first builds a set of matching selectors to determine which classes, pseudo-selectors, and IDs apply to each element, then processes the style rules from those selectors to compute the final styles.

Jeremy Wagner

Style recalculation is a significant component of interaction latency, which browsers measure through the Interaction to Next Paint (INP) metric. INP tracks the time from a user interaction until the browser paints the next frame with the corresponding visual update. That rendering work includes style calculation just before layout, paint, and compositing. Shortening any part of this chain reduces overall interaction latency.

Simplify your selectors

The simplest CSS selectors reference an element by class name only:

.title {
  /* styles */
}

As projects grow, however, selectors tend to become more complex:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

With a selector like that, the browser must effectively ask: "Is this an element with a class of title, whose parent has a class of box, and which is the minus-nth-plus-1 child of its parent?" Resolving that can be computationally expensive. A more specific class name makes the browser's job much simpler:

.final-box-title {
  /* styles */
}

These longer class names may look awkward, but they avoid costly structural checks. In the earlier example, the browser must understand the position of every element to determine whether any following element could match the nth-last-child condition. Matching against a class name alone is far cheaper.

Reduce the number of styled elements

Selector complexity matters, but the more important factor is often the volume of elements affected by a change. In the worst case, the cost of computing styles is the number of elements multiplied by the number of selectors, since the browser must check every element against each rule to find matches.

Modern browsers can often limit style invalidation to a few directly affected elements rather than the whole page. Older browsers lack these optimizations, so where possible you should reduce the number of invalidated elements.

Measuring style recalculation cost

You can measure style recalculation either in your development environment or for real users in the field. Each approach serves a different purpose.

Using Chrome DevTools performance panel

To measure style recalculation locally, use the performance panel in Chrome DevTools:

  1. Open DevTools.
  2. Navigate to the Performance tab.
  3. Optionally, check the Selector stats checkbox.
  4. Click Record.
  5. Interact with the page.
DevTools showing style calculations.
A DevTools report showing style calculations.

The top strip is a miniature flame chart that also plots frames per second. Activity closer to the bottom of the strip means faster frame painting. If the flame chart levels out at the top with red bars overhead, you are seeing long-running frames.

Zooming in on a trouble area in Chrome DevTools in the activity summary of the populated performance panel in Chrome DevTools.
Long-running frames in the DevTools activity summary.

Long-running frames during interactions such as scrolling warrant closer attention. A large purple block indicates style work; zoom in and select any task labeled Recalculate Style for details.

Getting the details of long-running style calculations, including vital information such as the amount of elements affected by the style recalculation work.
A long-running style recalculation taking just over 25&nbspms in the DevTools summary.

The event's call stack reveals which JavaScript triggered the style change. It also shows how many elements were affected — just over 900 in this example — and the duration of the style calculation. That information helps you locate the problematic code.

If you enabled Selector stats in the performance panel settings before recording, an additional tab with the same name appears in the bottom panel of the trace.

The CSS selector stats table as it appears in the performance panel of Chrome DevTools. This table contains headers and corresponding data for things such as elapsed time, match attempts, match count, percentage of non-matching nodes, selectors, and the style sheet they can be found in.
The selector stats table as shown in the performance panel of Chrome DevTools.

This panel shows the relative cost of each selector, helping you identify expensive CSS rules. For more detail, see the CSS Selector Stats documentation.

Measuring style cost for real users

To understand style recalculation for real users, use the Long Animation Frames API. Data from this API, including style recalculation time, is included in the web-vitals JavaScript library.

If you suspect that presentation delay is the primary driver of a page's INP, you need to know how much of that time goes to style recalculation. Read about measuring style recalculation time in the field for guidance.