Missed the action at the 2018 Chrome Dev Summit? Catch up with our playlist on the Google Chrome Developers channel on YouTube. Watch now.

Analyze Runtime Performance

Users expect pages to be interactive and smooth. Each stage in the pixel pipeline represents an opportunity to introduce jank. Learn about tools and strategies to identify and fix common problems that slow down runtime performance.


  • Don't write JavaScript that forces the browser to recalculate layout. Separate read and write functions, and perform reads first.
  • Don't over-complicate your CSS. Use less CSS and keep your CSS selectors simple.
  • Avoid layout as much as possible. Choose CSS that doesn't trigger layout at all.
  • Painting can take up more time than any other rendering activity. Watch out for paint bottlenecks.


JavaScript calculations, especially ones that trigger extensive visual changes, can stall application performance. Don't let badly-timed or long-running JavaScript interfere with user interactions.


Make a Timeline recording and look for suspiciously long Evaluate Script events. If you find any, you can enable the JS Profiler and re-do your recording to get more detailed information about exactly which JS functions were called and how long each took.

If you're noticing quite a bit of jank in your JavaScript, you may need to take your analysis to the next level and collect a JavaScript CPU profile. CPU profiles show where execution time is spent within your page's functions. Learn how to create CPU profiles in Speed Up JavaScript Execution.


The following table describes some common JavaScript problems and potential solutions:

Problem Example Solution
Expensive input handlers affecting response or animation. Touch, parallax scrolling. Let the browser handle touch and scrolls, or bind the listener as late as possible (see Expensive Input Handlers in Paul Lewis' runtime performance checklist).
Badly-timed JavaScript affecting response, animation, load. User scrolls right after page load, setTimeout / setInterval. Optimize JavaScript execution: use requestAnimationFrame, spread DOM manipulation over frames, use Web Workers.
Long-running JavaScript affecting response. The DOMContentLoaded event stalls as it's swamped with JS work. Move pure computational work to Web Workers. If you need DOM access, use requestAnimationFrame (see also Optimize JavaScript Execution).
Garbage-y scripts affecting response or animation. Garbage collection can happen anywhere. Write less garbage-y scripts (see Garbage Collection in Animation in Paul Lewis' runtime performance checklist).


Style changes are costly, especially if those changes affect more than one element in the DOM. Any time you apply styles to an element, the browser has to figure out the impact on all related elements, recalculate the layout, and repaint.

Related Guides:


Make a Timeline recording. Check the recording for large Recalculate Style events (displayed in purple).

Click on a Recalculate Style event to view more information about it in the Details pane. If the style changes are taking a long time, that's a performance hit. If the style calculations are affecting a large number of elements, that's another area with room for improvement.

Long recalculate style

To reduce the impact of Recalculate Style events:


The following table describes some common style problems and potential solutions:

Problem Example Solution
Expensive style calculations affecting response or animation. Any CSS property that changes an element's geometry, like its width, height, or position; the browser has to check all other elements and redo the layout. Avoid CSS that triggers layouts.
Complex selectors affecting response or animation. Nested selectors force the browser to know everything about all the other elements, including parents and children. Reference an element in your CSS with just a class.

Related Guides:


Layout (or reflow in Firefox) is the process by which the browser calculates the positions and sizes of all the elements on a page. The web’s layout model means that one element can affect others; for example, the width of the <body> element typically affects its children’s widths, and so on, all the way up and down the tree. The process can be quite involved for the browser.

As a general rule of thumb, if you ask for a geometric value back from the DOM before a frame is complete, you are going to find yourself with "forced synchronous layouts", which can be a big performance bottleneck if repeated frequently or performed for a large DOM tree.

Related Guides:


The Chrome DevTools Timeline identifies when a page causes forced synchronous layouts. These Layout events are marked with red bars.

forced synchronous layout

"Layout thrashing" is a repetition of forced synchronous layout conditions. This occurs when JavaScript writes and reads from the DOM repeatedly, which forces the browser to recalculate the layout over and over. To identify layout thrashing, look for a pattern of multiple forced synchronous layout warnings (as in the screenshot above).


The following table describes some common layout problems and potential solutions:

Problem Example Solution
Forced synchronous layout affecting response or animation. Forcing the browser to perform layout earlier in the pixel pipeline, resulting in repeating steps in the rendering process. Batch your style reads first, then do any writes (see also Avoid large, complex layouts and layout thrashing).
Layout thrashing affecting response or animation. A loop that puts the browser into a read-write-read-write cycle, forcing the browser to recalculate layout over and over again. Automatically batch read-write operations using FastDom library.

Paint and composite

Paint is the process of filling in pixels. It is often the most costly part of the rendering process. If you've noticed that your page is janky in any way, it's likely that you have paint problems.

Compositing is where the painted parts of the page are put together for displaying on screen. For the most part, if you stick to compositor-only properties and avoid paint altogether, you should see a major improvement in performance, but you need to watch out for excessive layer counts (see also Stick to compositor-only properties and manage layer count).


Want to know how long painting takes or how often painting occurs? Enable the Paint profiler on the Timeline panel and then make a recording. If most of your rendering time is spent painting, you have paint problems.

Long paint times in timeline recording

Check out the rendering settings menu for further configurations that can help diagnose paint problems.


The following table describes some common paint and composite problems and potential solutions:

Problem Example Solution
Paint storms affecting response or animation. Big paint areas or expensive paints affecting response or animation. Avoid paint, promote elements that are moving to their own layer, use transforms and opacity (see Simplify paint complexity and reduce paint areas).
Layer explosions affecting animations. Overpromotion of too many elements with translateZ(0) greatly affects animation performance. Promote to layers sparingly, and only when you know it offers tangible improvements (see Stick to composite-only properties and manage layer count).


Was this page helpful?