The Future of Performance Tooling

Rate this content
Bookmark

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.

21 min
16 Jun, 2022

Comments

Sign in or register to post your comment.

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.

1. Introduction

Short description:

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

Short description:

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 tend to talk a lot about things like JavaScript and JavaScript bundles, but today I wanted to take a step back and focus on user experience. Now, users often experience web pages as a journey, and there's a few key moments to it. There's, is it happening, is it useful, is it usable, and is it delightful? Delight can mean making the experience more pleasant through adding things like animations.

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

Next up, we have Actionable. Now, I mentioned earlier that I was excited to announce my new position. Now, when people often look at the timeline, the performance panel, they find it daunting. They almost want to cry. Now, a good piece of life advice is if JavaScript doesn't bring users joy, thank it and throw it away. We've been doing work to make sure that tools like Lighthouse are as actionable as possible for the web vitals. We've been working on a new interaction readiness metric called Interaction to Next Paint. It measures runtime responsiveness, full interaction latency, and includes taps, drags, and keyboard input events. Total Blocking Time is a good metric to consider.

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, when you're looking at the performance panel, you've often got a lot of data here. Here we've got a long task. If you've ever wondered why time to interactive isn't great, it's often because long JavaScript tasks are keeping the main thread busy. Now, a good piece of life advice is if JavaScript doesn't bring users joy, thank it and throw it away. I'm pretty sure this is from a Marie Kondo special. She didn't, in fact, say JavaScript. But I think this is good kind of Evergreen advice.

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

Short description:

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.

Now we've been working hard on introducing IMP to many of Chrome's tools starting off with PageSpeed Insights. So the first thing I'm going to show you is a new feature called Fast Crux. This gives you instant access to field data. You'll see that I just hit analyze. This isn't sped up and you've got instant access to field data and will then progressively load in your Lighthouse diagnostic data so you understand where you can improve. So IMP is already in PageSpeed Insights. Next up we have Lighthouse where we've got that time span mode. I'm going to interact with one of Google's more interactive experiences, Google Flights and here I'm going to show you that I'm performing a number of interactions. I've sped this up a little bit and we're going to end our time span here. And what this gives us is a Lighthouse report that's inclusive of interaction to Next Paint. We can scroll down and we can see that we have a brand new audit called Minimize Work During Key Interaction. This includes our input delay, processing delay, presentation delay as well as all the other audits Lighthouse typically gives you for reasoning about long tasks and JavaScript performance. Finally we've worked on tools like the Web Vitals Extension which I know a number of folks like. This also now has interaction to Next Paint. Now on the debugging performance side of things, people have been using the performance panel for years and years and it actually started out in a place where it was a little bit simpler. Over time we added flame graphs and the ability to reason about you know call stack depth but it trended a little bit towards tools that browser engineers used for performance debugging. Could this be better? We've got a preview of something we've been thinking about. So I'd like to introduce you to the performance insights experiment.

10. Contextual: Stack Packs and Improving Performance

Short description:

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.

Here's an example. So in an application that's using next.js rather than just saying you should be using a modern image format will tell you that you should be using the next.js image optimization API to serve modern formats like avif. Rather than telling you to just lazy load your images will tell you to use the next image component which defaults to loading equals lazy. Really powerful stuff, really great contextual stuff. We'll also do like tell you when you should maybe be considering splitting your JavaScript bundles using react.lazy or using a third party library like loadable components.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2023JSNation 2023
26 min
When Optimizations Backfire
Ever loaded a font from the Google Fonts CDN? Or added the loading=lazy attribute onto an image? These optimizations are recommended all over the web – but, sometimes, they make your app not faster but slower.
In this talk, Ivan will show when some common performance optimizations backfire – and what we need to do to avoid that.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion