Published: September 17, 2024
In the previous post, we looked at three new features to help you customize your performance workflows in DevTools. These ergonomic improvements were just the start of our multi-year effort to make DevTools even easier and more capable for optimizing Core Web Vitals. Today, we're launching of the next batch of features: a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.
In this post we'll take a closer look at each of the new features:
- Real-time local Core Web Vitals performance
- Real-user experience data
- Recommendations to configure your local environment
- Information to help you reproduce issues
Real-time local Core Web Vitals performance
The ability to measure how your local experience performs is a critical part of any Core Web Vitals debugging workflow. It can make the difference between reproducing real-user issues or not. However, measuring your local performance wasn't always this easy.
Historically, the Performance panel in DevTools shows a detailed timeline of network requests and CPU activity which is a very useful tool for performance debugging. However, it can be difficult to reproduce performance issues because you don't know if the performance is poor until after the recording finishes. As we've learned from the Web Vitals extension, having access to your local Core Web Vitals performance in DevTools is a game-changer. So we've taken everything we've learned from the extension and decided to build these features directly into the Performance panel.
For the first time, all of your Core Web Vitals metrics are available in the Performance panel. Open up the Performance panel and you'll immediately see how your local experience performs—no recording necessary. In fact, you don't even need to have DevTools open; the metrics are gathered in the background and available whenever you need it. This comes in handy all of those times when you may not be actively trying to debug a specific issue, but something feels slow, and you want to understand why.
The Local metrics section of the panel features a live view of your local Core Web Vitals metrics: Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. As you load and interact with the page, these metrics will update in real time. They're also color-coded according to their respective thresholds for good and poor performance, making it easier to spot performance issues as they happen.
Real-user experience data
Optimizing performance issues that most users never experience may not be the best use of your time. Likewise, if your local experience is unrealistically fast, you're probably overlooking some real-world issues. So to make a more informed decision about how to invest your time, you should be comparing your local performance to real-user experience data from the field.
The Performance panel now gives you a way to see your real-user data right next to your local experiences. The data is powered by the public CrUX API, which is a 28-day aggregation of real-user experiences on a given web page and origin. To enable it, click Set up in the Field data section and follow the directions in the configuration dialog.
Note that individual URLs and origins (entire websites) must meet certain eligibility criteria to be included in the CrUX dataset. User experiences are also aggregated by desktop and mobile device types when there's sufficient data. DevTools will do its best to automatically show the most relevant data to your local experience, defaulting to the same URL and device type when available. If there's insufficient desktop or mobile-level data, it will attempt to show data aggregated over all device types.
In addition to the 75th percentile value, you can hover over any metric to see the proportions of real-user experiences within each rating. In this example, the local Largest Contentful Paint experience is atypically slow, similar to only 12% of real-user experiences.
Equipped with this data, you'll have a much clearer picture of how representative your local experience is and you'll be able to fine tune it to more closely emulate a typical user experience.
Recommendations to configure your local environment
There are many differences between lab and field data, which are compounded by all the ways one can access and interact with a page. You can account for some of these differences and make your local experience more representative by configuring your environment.
When field data is enabled and available, the Recording settings section will suggest emulating the most common device type used by real users. By enabling device mode you can emulate a mobile device's viewport size. Responsive interfaces might change which element is attributed to the Largest Contentful Paint and have very different performance characteristics. The mobile layout might also reveal certain elements, like a navigation menu that only mobile users can interact with, or incur unique kinds of layout shifts not otherwise experienced on larger viewports.
This section may also recommend a specific network throttling configuration, like Slow 4G. Network recommendations are based on the 75th percentile round trip time metric, aggregated from real-user experiences on that page or website. Slower network speeds can make the loading performance characteristics of the page more realistic—for real-world desktop and mobile users alike—which can make it easier to spot opportunities for improvement. Also consider that layout shifts only count towards the Cumulative Layout Shift metric if they don't occur within 500 ms of an interaction. If a user-initiated layout shift is the result of a network request, throttling the network may be the only way to expose it locally.
Throttling your CPU is another way to make your local device perform more like real users. CPU throttling better emulates the relatively slower way that mobile devices tend to perform, with faster machines requiring even more throttling. DevTools recently added the ability to throttle your CPU by 20x, which is especially useful for the performant desktop machines that developers often use. A throttled CPU will cause scripts to run more slowly, making them more likely to become long tasks that lead to Interaction to Next Paint issues. For the same reason, the other Core Web Vitals metrics can also be affected by slower script execution, especially if it blocks the rendering of the largest piece of content or elements that shift the layout.
Configuring your local environment with more realistic viewport, network, and CPU settings should bring more performance issues to the surface that you might not have otherwise known about. And with recommendations powered by real-user data taking the guesswork out of it, you can focus more on finding and fixing those issues.
Information to help you reproduce issues
Your local performance is heavily dependent on how your environment is configured and how you interact with the page. For example, on a typical web page, the Largest Contentful Paint element is less likely to be an image at mobile viewport sizes. Typing a single character into a text field may be fast, but typing many of them in quick succession may cause poor Interaction to Next Paint. To help make sense of this and have more reproducible experiences, additional information about the metrics is available.
The LCP Element associated with the Largest Contentful Paint metric shows a link to the element itself. Hovering over the link highlights the element on the page. Clicking the link takes you to the Elements panel, so you can see the element in the full context of the document.
The Interactions section is a real time log of all eligible interactions that occur while DevTools is open. As you type, tap, or click, each interaction is added to the log with additional information to help you better understand what happened and how to reproduce it.
In addition to the interaction type, which is either a pointer or keyboard event, you'll see a reference to the interaction target. Similar to the LCP element, the interaction target itself is interactive and you can hover over it to highlight it on the page or click it to see it in the Elements panel. The interaction latency is also shown, using the same color-coding per the Interaction to Next Paint metric thresholds, making it easier to spot the slowest ones.
When you're able to reproduce the performance issue you're trying to debug, you're ready to start profiling. Under the Next steps section, use the Record and reload button to debug loading performance issues, like Largest Contentful Paint and load-time Cumulative Layout Shift. To debug issues that happen as a result of user interactions, use the Record button to profile the page while manually reproducing slow interactions or post-load layout shifts.
What's next
Grounding your performance workflows in real-time local data and real-user data from the field can help you decide whether to invest more or less effort in debugging and optimizing a metric. You should use this data to adjust your local environment to more realistically emulate your users' device types, CPU speeds, or network configurations to better reproduce their performance issues.
For any users of the Web Vitals extension, you'll probably recognize many of these features and so you might be wondering what this means for the extension. We'll be sharing more information in the coming weeks about how these changes impact the extension.
We're still just getting started with all of our Performance panel improvements, and there's so much more yet to come. We'll post here again with another update soon, but until then we encourage you to try out all of these new features in the Performance panel and let us know what you think. If you have any feedback, we'd love to read your comments in the public issue.