Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
The Future of Performance Tooling
AI Generated Video Summary
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
Hey folks, my name is Adi Osmani. I'm an engineering manager working on the Chrome team at Google. Today we're going to talk about the future of performance tooling. You may know me from the internet for posting about DevTools features and talking about performance.
Hey folks, my name is Adi Osmani. I'm an engineering manager working on the Chrome team at Google. And today we're going to talk about the future of performance tooling. You may know me from the internet for posting about DevTools features and talking about performance, but I've gone through the pandemic the same way that everybody else has. It's been a long pandemic. There have been a lot of folks recently announcing they have new jobs. I, too, am excited to announce my new position. It's the fetal position. I've been in it for some time. I'm probably going to remain in it right after this. The last two years were a good, dry run.
2. The Future of Performance Tooling
Today, we're going to talk about the future of performance tooling. Delight can mean making the experience more pleasant through adding things like animations. DevTools has an animation inspector built in. It's one of my favorite features. There are efforts to bring such APIs to the platform. The future of performance tooling is user-centric, actionable, and contextual. Core Web Vitals are three metrics that cover loading, interactivity, and visual stability. We can do more to bring how we think about performance closer to the user experience.
Now, as I mentioned, I love sharing DevTools tips, and one thing some folks, you know, a lot of folks don't know is that DevTools actually has an animation inspector built in. Here it is in action. You can use it to modify the timing of animations, delays, durations, and so much more. Here it is working against a Page Transitions app by Sarah Drasner. I love the animations inspector. It's one of my favorite features. Now, sometimes folks will ask, well, are there efforts to bring such APIs to the platform? Jake Archibald had a great talk about a new Page Transitions API. And here's a cool demo of it built by the community. So we have a shared element transition here where clicking on a URL, it's taking us to this page. We're going back, and you'll see that both the URL bar is changing, as well as giving us these beautiful animations. Now, there's a lot of work left to do to support things like Page Transitions in the animation inspector, but we can already see things like being able to play back these animations and see all of the different kinds of motion we are adding to our pages. Really powerful stuff, and I love it.
So onto our main question, what does the future of performance tooling look like? Now, I think it's three things. I think it's user-centric, actionable, and contextual. Let's start off with user-centric. Now, in the last few years, Chrome has talked about the importance of focusing on user-centric performance metrics, such as the Core Web Vitals. Now, the Core Web Vitals are three metrics. They're Largest Contentful Paints, First Input Delay, and Cumulative Layout Shift. This covers loading, interactivity, and visual stability. Now, these are great. We recommend checking them out using real-world data in the field, or in the lab. But there's a lot more that we can do to bring how we think about performance closer to the user experience. Now, there are probably a set of core user journeys that you care about on your site these days. This isn't something that lab performance tooling, or the tooling that we use in our laptops, has really fully acknowledged just yet. Instead, we focused on things like initial page load performance. This continues to be really important, by the way. But it's a story we've told in a few places, like in Lighthouse and in DevTools.
3. Understanding User Flows and DevTools Recorder
We're evolving our understanding of user experience, including post-load performance and user flows. User flows are a series of steps a user takes to achieve a goal. We've added support for user flows to DevTools and Lighthouse, starting with the DevTools recorder. It captures interactions and selectors.
But we're evolving our understanding of user experience all the time. Now, if you look at the core of Vitals metrics, some of them are already thinking about that post-load performance, including things like layout shifts that might happen after the initial page is settled. Your largest contentful paint can change. And there are so many factors that play into here, like whether you're an MPA or an SPA, like do you have a soft navigation? Are you prefetching or pre-rendering? What's your caching strategy? A lot of nuance here.
And so I would like us to think about user flows. Now, a user flow is a series of steps a user takes to achieve a meaningful goal. This is one of the best definitions out there. And it's by Alexander Handley. Now, a user flow usually begins at a user's entry point into an experience. And it ends usually and then completing a particular task, like completing a sign up or placing an order.
Here are a bunch of different examples of flows. You could be doing things like trying to purchase a product, you know, going through the phases of finding what you want, customizing it and so on until you add it to your cart and check out. You could be onboarding, you could be trying to create things or cancel a plan. Now, the way we've thought about measuring the performance of these types of experiences is usually by slicing them into URLs. So we'll say, well, what's the page load performance of step one, of step two, of step three, rather than reasoning about them in the aggregate or in the whole, the way that a user experiences them. And I think that there's an opportunity to do something to bring this much closer to what the user feels.
I'm happy to share that we've added support for user flows to DevTools and Lighthouse. This is a big deal. We've been working on it for some time and I'm really excited to walk you through it. It all starts with the DevTools recorder. So here's the recorder that allows us to measure across an entire journey. I'm going to start off with an Add to Cart flow. I've got our commerce experience. I'm browsing categories. I'm adding some things to my cart. Maybe I want to use the search feature to find a t-shirt. So we're going to do that. We're going to customize some colors. Then we're going to proceed to our checkout. Now here I can hit stop and you'll see that all those interactions were captured by DevTools, including the selectors that were involved.
4. Replaying Flows and Performance Measurement
I can now replay user flows, measure performance, and optimize specific parts of the experience in the DevTools performance panel. Flows can also be exported to Puppeteer for testing and used with Lighthouse to visualize steps, see audits, and identify areas for improvement.
I can now replay that flow. I don't have to go and tell each member of my team to do it themselves. I can hit replay. It's going to go end-to-end and there we go.
We've checked out. I can measure the performance of this flow. So we've got a measure performance button here. It's going to replay the entire flow, generate a trace of the end-to-end experience and here we have it. We're in the DevTools performance panel and I can zoom into any part of that experience I want to optimize.
We can also export flows to Puppeteer in case we're writing tests and we want those tests to also reflect what we're doing. So here I am. It's generated me a Puppeteer script. We can also use these Puppeteer scripts with Lighthouse for some bonuses. So in this case I'm using a Lighthouse feature that allows us to annotate things like time spans and snapshots and via Puppeteer I'm able to get this new report, this flow report. This allows us to visualize all of those different steps and see audits for parts of the experience that might need a little bit of work.
5. User Flow Import/Export and Lighthouse Support
In Chrome Canary, the recorder panel now allows you to import and export user flows using JSON. This addition makes it easy to share and collaborate on user flows. You can also edit user flows, customize products, and measure specific parts of the flow using the Lighthouse panel. This enables you to identify areas for improvement, such as cumulative layout shift issues. Find this powerful feature in Canary and make the most of it.
Now in Chrome Canary we've continued iterating on this support. The recorder panel now also allows you to import and export user flows including using JSON. This addition makes it really trivial for you to be able to commit your user flows to your GitHub repo, share it with members of your team, share it with QA, and it's going to be really powerful for your sharing story.
You can also do things like edit user flows for their selectors and timeouts just in case things take a little bit longer than you might expect. Also in Canary we have Lighthouse panel support for flows, so you can select a time span, you can hit start time span, and begin interacting with that experience. This is the first time we've allowed you to interact while Lighthouse has been running, so you can interact with this experience, you can customize your products. And then when you're done with the part of the flow you want to measure you can hit end time span. This will go and it will generate you a part of that flow report and we can use it to discover things such as, you know, do I need to do a little bit more work on my cumulative layout shift, because maybe there was some layout shift that happened during my interactions. This is really powerful, you can find it in canary and we hope you'll find it useful.
6. Flows with Other Tools and Cross-Browser Testing
Now let's explore using flows with other tools. The web page test team has a DevTools recorder to web page test scripts repo. By exporting flows to a cart.json file, we can reason about the entire user flow, gaining performance insights, filmstrips, and visual page load processes. We can also utilize web page test waterfall features. Additionally, cypress.io offers a package to export Cypress tests from Chrome DevTools recordings. This enables cross-browser testing and playback of recorded flows, allowing for debugging and powerful cross-browser interop.
Now another question we had after working on flows was what if you could use flows with other tools? I'm happy to share something very experimental, very exciting. I love using web page test, and the web page test team put together a handy DevTools recorder to web page test scripts repo that you can check out.
So let's say that I've exported my flow to a cart.json file using one of the previous steps. I can use this with this script. This is what the output kind of looks like. It's not that interesting, but we're just going to skip ahead. And let me show you what this enables. We can paste this into our web page test run and now I can reason about my entire user flow. I get performance insights for my navigations, for my clicks. I get filmstrips. I can see the visual page load process for any of my steps. I'm able to scroll down, I'm able to use any of the great web page test waterfall features for understanding bottlenecks. All this is really really great and gives us a step towards tooling interop, which I'm really excited about.
Here, for example, we can see we've also got features like the web page test videos, which I love using. Now another question that we ask ourselves is what about cross-browser testing of flows? Maybe you know where we're going with this. So cypress.io is a user-friendly test automation tool for end-to-end testing. It's great for things like UI testing, regression suites, integration, and unit testing. Now, the Cypress team has a special new package that can export Cypress tests from Google Chrome DevTools recordings. Let's say we take our cart.json once again, and I want to run it with Cypress. I'm going to use the Recorder conversion package on my cart.json. Let's go ahead and say we've got that done. We're going to now run Cypress. Let's see what happens. So npx cypress open, it's going to open up a Cypress window. I can select a browser here. So I'm going to select Firefox, our users.spec.js is the converted Cypress script. And here I am with the flow I recorded using Chrome DevTools and it's playing back my whole flow in Firefox. This is so cool. I'm able to go to all of the different steps and sequences that were involved in this flow. I can debug, you know, what cross-browser might not be working well or might not be working well and it's just really powerful that you get this kind of cross-browser interop almost via such tooling.
7. Cypress Account and Recording
If you have a Cypress account and API key, you can record and persist flow recordings to your Cypress dashboard. You can share and play back the recordings, providing a powerful experience. Check it out!
It's really, really cool. Now, if you happen to have a Cypress account and you have an API key, you can do things like use record to persist your flow recording to your Cypress dashboard. So, here's an example of that. I am going to just go and show you something I did earlier. Here, we've got our Add to Cart experience and we can see what we just... You know, where we're demoing. Here is a video of that experience. I can share it with others, I can play it back. I get the same kind of Cypress experience I would get if I was custom, you know, creating these flows myself. So, really, really powerful stuff. I hope you'll check it out.
8. Actionable: New Metrics and Improving Lighthouse
Next up, we have Actionable. Now, I mentioned earlier that I was excited to announce my new position. This is also how I look when I'm looking at performance traces in DevTools a lot of the time. I love DevTools, by the way. Now, when people often look at the timeline, the performance panel, they find it daunting. They almost want to cry. I sometimes cry when I'm looking at the performance panel. Did you know that there are something like 17 muscles that get activated when you're crying? 17 muscles. Great for fitness. I've been doing some of that during the pandemic too, I'm not going to lie.
Now, we've been doing work to try and making sure that tools like Lighthouse are as actionable as possible for the web vitals. And if you haven't checked out Lighthouse recently, we've got all sorts of audits that can help you do things like identify your long main thread tasks or what your large layout shifts are. And we try to make this experience quite visual. And try to pinpoint exactly what DOM nodes you might want to pay attention to. Now, we talk about interaction readiness quite a lot. And I wanted to talk to you about input responsiveness for a moment. So what is responsiveness? Responsiveness means understanding how quickly web pages respond to user input. Now, this can mean things like when I try to open the menu on a website, how long does it take before anything actually happens? Or if I'm trying to add something to my cart, how long does it take before I can actually see that my item has been added? These are all important steps in a user flow. Now, we've been working on a new interaction readiness metric and we call it Interaction to Next Paint. This is a new experimental responsiveness metric. It measures runtime responsiveness, full interaction latency, and includes things like taps, drags, and keyboard input events as well. The way this differs to first input delay is that it measures the whole input latency from when a user interacts until they actually see a visual response, not just the initial delay on the main thread. In the lab, Total Blocking Time is a pretty good proxy metric to be looking at.
9. Improving Performance Metrics and Debugging
We find that 70% of users have a terrible experience with responsiveness at least once a week. Optimizing for metrics like total blocking time and IMP is crucial. IMP has been introduced to Chrome's tools, including PageSpeed Insights and Lighthouse. The new Fast Crux feature provides instant access to field data. Lighthouse now includes interaction to Next Paint in its reports, along with a new audit called Minimize Work During Key Interaction. The Web Vitals Extension also supports interaction to Next Paint. We're constantly working on improving performance debugging tools, and we have a preview of the performance insights experiment.
We find it correlates pretty well with Interaction to Next Paint. One of the nice things about this is that it's automatic and out of the box. Interaction to Next Paint is a field metric primarily and can vary depending on what interactions a user is making. This is one of those reasons it's great to use things like user flows because it lets you know what the key interactions are.
Now what we find is that 70% of users have an experience that's terrible where responsiveness is concerned at least once a week. This is really a big opportunity for us to do better, especially given that UX research says that ideally it's 100 milliseconds you should be looking at for expected input latency. We find that on desktop users load twice as many pages if they experience good responsiveness there. So lots of reasons to be optimizing for these metrics.
As these metrics have been rolling out we've also been able to share more concrete guidance. For example if you're using React 18 and you wrap your UI in suspense boundaries you can make hydration non-blocking because it happens in slices instead. This can improve things like your total blocking time. And I'm looking forward to even more concrete guidance for optimizing metrics like total blocking time and IMP coming out before long.
10. Contextual: Stack Packs and Improving Performance
Improving performance is a journey. Small changes can lead to big gains. Step one might be an outline, step two is not a sudden solution. It's a result of iteratively investing in improving the user experience over time. Your users will thank you for an improved performance experience. The future of performance tooling is user-centric, actionable, and contextual.
This is available as a preview we hope you'll check it out and feel free to share feedback. And finally we have contextual. Now we introduced a feature called stack packs which allows Lighthouse to display stack specific suggestions. We know that a lot of people are often using frameworks or CMSs when they're building things out and so we've been hard at work making sure the Lighthouse can start to give you slightly better context if you're using a modern stack.
Now, a parting thought is that improving performance is a journey. There are lots of small changes that can lead to really big gains. Step one might be an outline. Step two is definitely not this. You're not going to suddenly solve all the world's problems. But you might end up similar to where I usually do with performance, which is step 1.5. It's fine. It's a result of iteratively investing in improving your user experience over time. And you'll eventually get to something closer to this. But this is actually okay. It's still pretty. Your users are going to thank you for an improved performance experience at the end of the day. So I hope you got some value out of this talk. I think that the future performance tooling is user-centric, actionable, and contextual. I've been Adi Osmani.