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 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.
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.
|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).|
|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.
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.
To reduce the impact of Recalculate Style events:
- Use the CSS Triggers to learn which CSS properties trigger layout, paint, and composite. These properties have the worst impact on rendering performance.
- Switch to properties that have less impact. See Stick to compositor-only properties and manage layer count for more guidance.
The following table describes some common style problems and potential solutions:
|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.|
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.
The Chrome DevTools Timeline identifies when a page causes forced synchronous layouts. These Layout events are marked with red bars.
The following table describes some common layout problems and potential solutions:
|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.
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:
|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).|
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Terms of Service.