Knowing how to run performance tests on your web application properly is one thing, and putting those metrics to good use is another. And both these aspects are crucial to the overall success of your performance optimization efforts. However, it can be quite an endeavor at times for it means you need to have a precise understanding of all the ins and outs of both performance data and performance tooling. This talk will shed light on how to overcome this challenge and walk you through the pitfalls and tricks of the trade of Chrome DevTools, providing you with a complete roadmap for performance analysis and optimization.
High-Speed Web Applications: Beyond the Basics
AI Generated Video Summary
This talk covers the latest features in Chrome DevTools, including network tab analysis, performance tab optimization, and user flows. It discusses optimizing HTTP requests with fetch priority to improve loading time. The performance tab provides insights on frame drops, long tasks, and the importance of minimizing total blocking time. The talk also highlights the optimization of page rendering and introduces user flows in Chrome DevTools.
1. Introduction to Chrome DevTools
Hello and welcome to my talk, High Speed Web Applications Beyond the Basics. I will cover the latest features in Chrome DevTools, including network tab analysis, performance tab optimization, and user flows. Let's start with the network tab, where you can analyze HTTP requests and use fetch priority to optimize content. In the performance tab, I'll demonstrate optimizations using content visibility and scheduling. Lastly, I'll introduce user flows and pitch the latest tools for measuring runtime performance.
Hello and welcome to my talk, High Speed Web Applications Beyond the Basics, a talk about the latest and greatest features in Chrome DevTools. Let me quickly introduce myself. My name is Michael, Michael Lutke. Very hard to read, write and pronounce, so let's stick with Michael. What I do is, I do consultings, trainings and workshops in the field of performance optimizations, Angular and reactive programming. I also run a company that is named Pushbased. You can visit it, just click on the link in my slides.
But now let's see what is on the agenda. First of all I will talk about the network tab. I will show you what you can see in the network tab and then I will try to look at some latest features. One of the cool features that are shipped in Chrome is fetch priority and I will use fetch priority to optimize the largest content for paint with an image as well as with http requests. Later on I will show you how to look at the performance tab. This is not really easy because a lot of information and I hope or let's say I promise that after the talk you will be able to at least have a little bit more understanding on what you will see there and what to look at. To demonstrate some optimizations in the performance tab, I will use content visibility, one very nice cutting edge CSS feature and I will also introduce you to scheduling and chunking of work in the main thread.
At the very end of my talk, some really, really exciting stuff I want to talk about user flows. User flow is basically a new tool that is at the moment only available in Canary Chrome, and it enables us to completely new ways, how to measure runtime performance in the browser. In the end, I will pitch to you the latest and coolest tools on user flow, how to use them and also how to integrate that stuff in your CI. With no further pauses, I will jump right into network analysis and the Network tab. So what you see here in this tool is first of all, I selected the Network tab and then you have a lot of information present. A lot of information about all the HTTP requests that are done from your application. And if you have a closer look on the right part of that slide here, you will see the waterfall diagram. In the waterfall diagram, you basically see a time bar chart thingy that displays all our HTTP requests, their start, their end, and what time they are made up of. If you hover over one of those tabs, you will see the request timing. And the request timing can show you some information about connection time, how big the amount of data was, and all the other times and durations that were required to make up the whole receiving of that data. In this slide you see a column that basically tells us about the priority of HTTP requests. We can see that some of those HTTP requests are more important, have a higher priority than others, and I want to leverage one of the latest features Fetch Priority to demonstrate what you can achieve with priority in your application. Without more information on the Network tab, I will straight go into practice and show you how we can change all the requests that are done and how we can improve them. One of the first things I want to improve, also visible in the network tab of course, is the connection time. In this slide you see at the very top an un-optimized version of two HTTP requests to two different domains and as you can see there is an orange block that connects and then a blue block that downloads, another orange block that connects and another blue block that downloads. So if we leverage the pre-connect attribute on our links, we can basically tell the browser, look to those two API endpoints we will fire requests in the future, so why don't you just set up the connection right at the start of the application and then we can save the connection time later on.
2. Optimizing HTTP Requests with Fetch Priority
This section discusses the parallelization of connection locks, the priority of HTTP requests, and the use of fetch priority to optimize the largest contentful paint of an image. The example demonstrates the improvement in load time and the importance of having the largest contentful paint at the beginning. The next optimization involves leveraging fetch priority in HTTP requests.
This is demonstrated in the lower part of the picture and you can see that both connection locks are now parallelized at the very beginning and the whole chart is a lot shorter.
The next thing, and this is the fancy new cool stuff, is the priority of those HTTP requests. Again, in this chart you see an unoptimized version at the top, some execution of script, some fetching a resource A, fetching a resource B, and then rendering stuff.
Of course, rendering an image is more important than executing some script or fetching some resources that are used later on. So, the first thing that we do is we should make all the yellow scripting blocks asynchronously and non-blocking. This can be achieved by the defer, the preload, or the prefetch attributes. Deferring scripts just means move that script to the very end of the queue and go on with processing, with parsing of your HTML. And preloading and prefetching means basically that I try to get data at the very beginning of let's say the part that is not visible in the page. So preloading would be preloading resource sources that are accessed at a later point in time on this very page. And prefetching could mean preloading some stuff that is used after a navigation.
With those three things we can already go far but there is another really really fancy and very very helpful feature fetch priority. So with fetch priority we can basically determine on which of my HTTP requests have more priority than others and I want to use it to update the largest contentful paint of an image. If we look at this code snippet here we see two links that fetch some hero images and one of those two images is more important than the other one. So normally just by the order of HTML content we would first fetch hero image 1 and later on hero image 2. But now with fetch priority it can tell the browser that the second image, even if it is later on in time has more priority than the first one and the browser would switch execution of those two HTTP requests and fetch the second one earlier in time.
How would that look in practice? So, I took ObservableHQ as a dummy website and what we see here is a video image, or like I said, a small image of a video that we'll start to play later on and this is definitely the largest contentful pane, the most important part the user should see at the beginning. By applying some tweaks to the HTML and using prefetch, we end up with the following improvement. So what you see at the top is the first line of this movie strip shows us the default page and the second line of this movie strip shows what is the outcome of my optimization. There are two things different. First of all, the whole chart is way shorter now. I basically went from total 7 seconds to 4.5 seconds. But the really important and interesting part here is the largest content for paint is now present at the very beginning. So I went from 7 seconds of the largest content for paint which you can see here at the top to 2.5 seconds. This is also what is visible here in the detailed diagram at the bottom. And you can see that the image is really the first thing visible and then after that there is some fetching. But the image is always visible and gives a very nice user experience for users that want to consume this video or at least want to see a first sneak peak.
The next optimization that I want to do is I want to use or leverage fetch priority in HTTP requests. So when you use the fetch API you now can also give it an importance of this HTTP request and this is done by just applying another configuration as you see here. With this technique let's see what I did in practice with it. If we have a look at the page we see two different dynamic contents on the page.
3. Optimizing HTTP Requests with Fetch Priority
We can optimize the order of HTTP requests using fetch priority, ensuring that critical content is fetched first. This feature allows us to improve the loading time of our web applications.
We see a list of movies and a side menu with a section that is made up of dynamic fetched menu items. And as you can see those HTTP requests are fired quite late in time. So when I apply fetch priority and you have a look on the next slide, you can see that I moved this stuff to the very beginning and I was also able to basically shift the order of those two HTTP requests so that the images of the movie list is fetched first and after that the dynamic list in the side menu. Pretty cool, pretty exciting stuff. Everything that you saw is basically possible with this new cool feature Fetch Priority.
4. Performance Tab and Long Tasks
Next, we'll dive into the performance tab, which provides valuable insights but can be complex to interpret. We'll explore frame drops, long tasks, and the importance of allowing the browser to process user interactions quickly. Long tasks are identified by red areas or red triangles, and the overview at the top shows the frames per second rate. We'll aim to minimize long tasks and total blocking time to improve performance.
What's next? Next is the performance tab. The performance tab is one of the most insightful, but also most complicated charts to read when it comes to performance tools. In the next slide, I want to give you a sneak peek on what you can look at and also how to improve that stuff. Let's start with what a frame drop or a long task is. First of all, a user always wants to interact with your page. Interaction means clicking, scrolling, or any other stuff that could happen to the keyboard or over the keyboard. One of the most important parts is to give the browser the chance to process those interactions whenever it is needed first or let's say as fast as possible. If you look at the chart, you see grey boxes and those grey boxes are so called tasks. A task is basically a unit of work that the browser needs to process before it can do anything else, for example, reacting to a user input. We can spot those long tasks, tasks that took too long to block user input or the processing of user input by this red area or by the small red triangle that you can see on the top right here. Another place where you can spot that stuff is also the overview at the very top, there you see these red bars and the green squiggles and those two things basically tell us A where our long tasks are and B how's the frames per second rate and if the frames per second are consistent you can assume that also our tasks are not too much blocking. At the very bottom number 3 you see an overview in this case a total time of our long tasks and their blocking time and total blocking time is one of the heaviest rated measures in for example the lighthouse score and we should always try to reduce long tasks or total blocking time to a minimum.
5. Understanding Single Tasks and Long Tasks
Let's now zoom in and understand how a single task looks. The grey box marks the task, and the color indicates the type of work. We see the details of what was scripted, layouted, or painted. Long tasks are marked with a red triangle and indicate overtime. We aim to eliminate tasks longer than 50 milliseconds.
Let's now zoom in a little more and understand how one single task can look like. So in this picture we see one task in detail. We see that at the very top is a grey box. The grey box marks of course the stuff but what we also see is the type of work. Yellow, purple or green. Scripting, layouting or painting. Below all of that you can see the details. What exactly got scripted? Or what exactly got layouted or painted? In this slide you see that this task is marked as a long task and we see the overtime area in this red dashed, or not dashed, but sharpaed lines and then we also see the long task flag, the red triangle at the top right corner of every gray box of every task that is marked as a long task. This information is very important for us because this is what we need to get rid of. What we need to get rid of is everything that is longer than 50 milliseconds. As you can see here, 50 milliseconds is an okay-ish long task and everything that is over 50 milliseconds is basically the overtime of a task.
6. Optimizing Page Relay Outing and Paint
With the latest browser features available in Edge and Chrome, we can optimize page relay outing and paint. Lab measurements show significant improvements in paint and layouting times. Field data demonstrates the impact of optimizing rendering time and introduces scheduling and the frame budget to reduce total blocking time. Optimizing total blocking time and input delay is also showcased, along with the exciting new feature of User Flows in Chrome DevTools.
With all that information clicked, we jump to page relay outing and paint. This is the purple and green stuff that I want to show you how to optimize and I want to use latest browser features available in Edge and also in Chrome. In this slideshow here, you can see from CanIUse where it is supported and I have told you already it is supported unfortunately only in edge and chrome, but all other browsers are working heavily to get that shipped.
Now as we understand where you can use it, let's see what could be the potential impact. This here is a lab measurement of taking one page in an unoptimized state, one page optimized with content visibility or nodes on screen, which means all content is visible within the page and then all content off screen, which means it is somewhere below your screen size, not visible to the user at the moment. If we look at the numbers, the top numbers are in green, paint, so we can go from an unoptimized with six milliseconds paint to on screen optimized one millisecond paint and off screen really, really nice to 0.1 milliseconds off screen. This is really an interesting impact, I would say a tremendous impact. Even cooler for layouting, this is the lower part here in this slide, you see 11 milliseconds update layer tree and paint with the optimization everything on screen 0.5 milliseconds and later on everything off screen it's only 61 microseconds, which is a really, really interesting number and heavily dramatic impact.
7. User Flows and Chrome Lighthouse
What are user flows? Chrome Lighthouse now enables three measurement modes: navigation, time span, and snapshot. The time span measurement mode allows you to record user interactions within a specific duration of time. A user flow report in Chrome DevTools shows multiple steps, such as ordering a coffee online. The report viewer displays the navigation to the coffee cart application and the details of the recorded time span for selecting a coffee.
Please have a look, very interesting. So what is user flows? If you imagine that Chrome has this tool that's called Chrome Lighthouse and Lighthouse so far was only able to measure bootstrap performance that measured the moment when you navigated to a page the first time, and this was always a cold navigation and was always as I said, limited to bootstrap performance only. With version 9 something. Lighthouse now enables 3 measurement modes, navigation, time span and snapshot.
Navigation is basically the default Lighthouse measurement that was present ever since. So any measurement was a navigation measurement or navigation mode until version 9. The second very cool measurement mode and for me most exciting one is the time span measurement mode, where you can start and stop recording of a duration of time and within that duration of time you can run some user interactions. For example, fully automated with Puppeteer. And at the very end we see snapshot and the snapshot is basically a way to take a so-called snapshot of your page at any moment in time. And it is very useful to determine accessibility measures and other static stuff to a later point in time, not only at navigation.
Let's see how this could look in practice. What you see here and in a second I will show it to you live is a user flow report, basically a report that looks quite similar to a Lighthouse report, but as you can see has multiple different steps. And what I did here is I basically ordered a coffee online. Let me quickly exit the slides and demonstrate to you how this report looks in real life. I will open up Chrome dev tools and I will hopefully, if I don't make a mistake, be able to drag and drop the report directly here. As you can see, pop. So this is the normal lighthouse report viewer and it already supports user flows. The first one, let me click on summary is a navigation to this coffee cart application and I will open the application for you just that you can see a very primitive application. I can select a coffee, click on that stuff, could enter some user data and then order basically a coffee. I see the confirmation message at the bottom and that's it. What I wanted to record. So let's go back and let's have a look at this. What I did was a navigation to this page and from the numbers you can see this is a default lighthouse score. I can click on it and I see the full details. I have all my web vitals here, some images, the time, the tree map and all the diagnostics visible at the bottom. As a later point in time, I recorded the time span of selecting one coffee. So from a non selected coffee to hovering over a coffee and then clicking that coffee and select it. This is recorded here. As you can see it provides us a reduced number of our recording. We see total blocking time, cumulative layout shifts and other stuff.
8. Userflow Insights and Conclusion
After selecting a coffee, I wanted to ensure accessibility, CO terms, and best practices were met. The numbers show some reduction, but still provide valuable insights. There are more measurements for checkout and order submission. I recommend checking out the GitHub link for Userflow. Thank you for your time.
And if I scroll more down, we also see all the detailed recordings. The last one is selecting a coffee snapshot. So after I selected a coffee, I wanted to make sure, is all the accessibility still given? Are CO terms met, is best practice still a thing? And as you can see, those numbers here show us that it is reduced, but it still gives us a lot of insights on what we can do with those new tools.
Of course, there are more measurements, again, another time spent for checkout, another snapshot for checkout, another time spent for the order submission and another snapshot for order submission. Really nice tools. I highly recommend you that you check out the link from before on GitHub push-based with a dash slash user flow, and you can directly use it already in your project, CLI, or even CI.
Let me jump back to the slides and open them full screen. And let me say, thanks for your time. This is the very end of this very small, dense and brief talk about some latest and greatest features. I know it was quite a lot in, lot in some minimum time. So if you have any question, feel free to shoot me an email, michael.latki8-push-based.io. I'm also on Twitter and more most, probably more active on Twitter than on any other platform. And again, the GitHub link to the latest and coolest feature, Userflow, please check it out. And again, thanks a lot for your time and see you later. Enjoy the rest of the conference.