 And as we evolve our metric story, we want to fill in as many gaps of our measurement of user experience as we can. There are a few major shifts here that I'd like to call out. The first one is the reduced emphasis on first meaningful paint and first CPU idle. We're excited to have metrics available that better capture when a page feels usable, which leads me to the second major call out, which is the new metrics you see added. So largest contentful paint, total blocking time, and cumulative layout shift are all out and available. These new metrics help to fill some of the gaps in our measurement story. For instance, when Time to Interactive does a good job of identifying when the main thread calms down later in load, total blocking time aims to quantify how strained the main thread is throughout the load. Pretty much all the lab metrics are available in Lighthouse. First input delay only really makes sense in the field. So then when it comes to field metrics, you can see most of them are available in Chrome UX support. Other than, you can collect yourself with a performance observer. And you can check out, actually, the documentation for all this in web.dev.slashmetrics. Thank goodness. Gone are the days where you're having to toggle and compare between two Lighthouse reports side by side, trying to find the differences, and you're actually able to see the diff view. Now you can see the changes between the two reports in a single view. So we are launching the 0.3 alpha of Lighthouse CI today. And you can check it out in the repo, set it up. Please let us know what you think of it. It is early stages, and we definitely want your feedback. Your user's hardware and their network type can massively impact the experience that they're going to have with your site. Now there are three or four key signals we'll be looking at for adaptive loading today. First of all, we've got network for fine tuning things like data transfer to use less bandwidth. We've got memory for reducing the amount of memory consumption on low end devices, CPU for limiting costly JavaScript execution, and reducing CPU intensive logic. To make all of this easier, today we're releasing a new experimental set of React hooks for adaptive loading that you can go and check out. Adaptive module serving is something I'm excited about. And this is this idea of shipping a light, interactive core experience to all of your users and progressively adding high end features on top. So if a user's device characteristics and network can handle it. Now it's this device awareness that takes progressive enhancement to the next step. Well, we have navigator.hardware concurrency, which tells us generally how many CPU cores. And many browsers also give us navigator.device memory, which tells us how much RAM. So maybe on desktop there's a way we can use these two fields and figure out some generalized buckets that we can apply consistently across different devices and different metrics. Once we have this core metrics and we're able to break it up and have a consistent way and understanding of what different types of hardware, we can actually consider this in our core frameworks. We're in close contact with the Angular team and really excited for their achievements on both UX and DX. In particular, they ship differential loading, which reduces polyfill in modern browsers and they have automatic deployments to different platforms to name a couple of things. Also, Dion mentioned the keynote that we have funded a number of projects with the framework fund. We'll have funding again next year. So if you're playing a role in the framework ecosystem, providing something of value, please apply for funding. At Google Iow, I mentioned that we kicked off an effort in the space, directly collaborating with Next.js. In particular, we are starting with performance improvements first, both because this is an important problem needing attention, but also it wasn't overlapping with other efforts. Sum up another major Next.js site that we tested our chunking strategy on saw a reduction in their largest JavaScript bundle by 64%. And again, the amazing thing about these changes is that it involved no actual change to the user's code whatsoever. This was all by just turning a flag on that changed the chunking strategy to use our newer granular approach. Today, we're excited to introduce a new Babel preset that optimizes specifically for this case. It's called Babel Preset Modules and it's available on NPM right now. But running the same code through preset modules produces this. It's a lot smaller. Here's the thing, both outputs run in all browsers that support script type module. So these are the things that we're currently working on to help you with building more scalable web applications. So one of them is translations. Then there's unit testing. So unit testing, integration testing is a really broad topic also. There's image handling. So images make up a large percentage of what you show on the website, right? But we don't provide a opinionated way to load images currently. So that means that it's really easy to include images that are too large. There's analytics. Analytics is something that you all probably use in a website at least because you want to know what your user are doing on the page. However, to correctly implement and relay analytics in single-page applications is really hard. There's error reporting. You probably all have written bugs before and it's really hard to catch bugs in production in websites because it runs on a browser that is not your own browser. And because of that, you can't see what user are doing. So error reporting is very important in that way. So relaying errors that happen is going to be easier very soon too. Let's walk through step-by-step what portals can do. Let's say you have a page. Say food.html. All blue, super nice with this full blue background and having food.html in the center. And you also have another page, part of HTML, which is pretty similar to food.html but having a different color and a different URL. We'll use these two pages to see what portals could do. You would first want to check if your browser supports portals. As you all know, progressive enhancement is very important because we don't want to break any experience in non-sportive browsers. You can check if the HTML portal element is in a global window object to achieve this. Next, let's create a portal element by document doc3 element, setting a source attribute as bar.html and adding some styles of your own. And lastly, adding the element to the document and boom, you'll see bar.html embedded in a page. So as you can see, portals really makes the loading experience disappear. You don't need to wait for the page to render anymore because it's already rendered inside the portal. Like I mentioned, portals has nothing to do with animation but you can always animate the portal to make the transition smooth. You could be using keyframes or JavaScript to move around the element. But in this case, let's say we animated the element with CSS transitions. All right, to close, we've talked about four APIs today. The first one, portal, which is designed to enable instant and seamless navigation. Periodic background sync, this is designed to help get content ahead of time on the device so that you don't have to worry about connection. Content indexing, this one is about surfacing the content that's available on the device and it's going to be available in origin trials soon. And last but not least, web bundles. So this is a convenient format to enable discovery and distribution.