Analyze runtime performance
Users expects interactive and smooth pages. 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.
- Do not over-complicate your CSS. Use less CSS and keep your CSS selectors simple.
- Avoid layout as much as possible. Choose CSS that does not trigger layout at all.
- Painting may take up more time than any other rendering activity. Watch out for paint bottlenecks.
Take a recording in the Performance panel and look for suspiciously long
Evaluate Script events.
|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 may 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 figures out the impact on all related elements, recalculates the layout, and repaints.
Take a recording in the Performance panel. 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 is a performance hit. If the style calculations are affecting a large number of elements, that is 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.
The following table describes some common style problems and potential solutions:
|Expensive style calculations affecting response or animation.||Any CSS property that changes the geometry of an element, like the width, height, or position; the browser checks all other elements and recalculates 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 layout model of the web means that one element may affect others; for example, the width of the
<body> element typically affects the widths of any child elements, and so on, all the way up and down the tree. The process may 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 may be a big performance bottleneck if repeated frequently or performed for a large DOM tree.
The Performance pane 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.|
|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 noticed that your page is janky in any way, it is 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.
Paint and composite: Tools
Want to know how long painting takes or how often painting occurs? Check the Enable advanced paint instrumentation setting in the Performance panel and then take a recording. If most of your rendering time is spent painting, you have paint problems.
Paint and composite: 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.|
|Layer explosions affecting animations.||Overpromotion of too many elements with
||Promote to layers sparingly, and only when you know it offers tangible improvements.|
Getting in touch with the Microsoft Edge DevTools team
Use the following options to discuss the new features and changes in the post, or anything else related to DevTools.
- Send your feedback using the Send Feedback icon or select
I(macOS) in DevTools.
- Tweet at @EdgeDevTools.
- Submit a suggestion to The Web We Want.
- File bugs on this article using the Feedback section.
Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons Attribution 4.0 International License.
The original page is found here and is authored by Kayce Basques (Technical Writer, Chrome DevTools & Lighthouse) and Meggin Kearney (Tech Writer).
This work is licensed under a Creative Commons Attribution 4.0 International License.