 So, you've heard the benefits of Core Web Vitals, but what are we working on to make meeting those thresholds easier? In the next 10 minutes, we're going to take a whirlwind tour of features to help you make your pages faster. I'm Jack Archibald, and this is Beyond Fast. First up is the CSS properties, content visibility, and contain intrinsic size. What do these do? Well, when you load a page, the browser tries to be smart about how much it paints. For example, it won't put effort into drawing things that are way outside the viewport until you scroll towards it. However, the browser has to do a load of layout work to figure out what's inside the viewport and what isn't. This is because an element may be at the very end of the document, but positioned at the top, or some deeply nested element could be positioned outside all of its parents. These are things that CSS just lets you do. So, to figure out the size and position of one element, you generally need to know the layout of its siblings, its parents, its parents, their siblings, their children, basically, you need to know everything. But now, there's an easy way to avoid that. Let's start with these content areas. We're going to give them a content visibility of auto. This means the browser can skip the layout of the children while the container is outside the viewport. But skipping that layout means the container loses its height, so we use contain intrinsic size to set a fallback content size for the element. This lays the containers out as if they had a single child that's 0 pixels wide and 500 pixels tall. Now, 0 pixels, that might sound weird, but because the container is block level, it stays full width. While we're at it, we can do the same with our smaller heading elements, this time giving them a fallback height of 60 pixels. And now, when the page loads, it does a full layout for everything in the viewport, so that's the top heading there and that first content area. But that's it. It skips the rest, making things much faster. Then, if the user scrolls down, the other areas of the page will be laid out just in time. All the layout shifting you see here is happening outside the viewport. The only thing the user might notice is an update to the scrollbar. And, of course, a much faster load time. But how much faster are we talking here? Well, I tested this out on the HTML spec, and it took the layout time down from 50 seconds to 400 milliseconds, and that's an amazing saving. But remember, the HTML spec is a 12 megabyte document, so this is quite an extreme case. But even on normal sites, like you can make hundreds of milliseconds of saving with very little change. Measure it with your own content and see the difference. That's the high level. For more details, see the web.dev article that is linked in the description. But the good news is this shipped in Chrome 85. And, of course, that includes the other browsers that use the Chromium engine. Other browser engines are thinking about it too. In particular, there's positive signals from Firefox. But using it today won't break other browsers, so your users can benefit from it right now. Okay, next up is the font metrics override descriptors. Now, that might sound like something Captivicard would activate to stop the enterprise exploding, but this CSS feature tackles a long-standing frustration when it comes to text rendering. Have you ever gotten your layout looking exactly as you want it in one browser, only to try it in another and find out the text is ever so slightly misaligned? Well, this is because font layout information can come from a variety of different places within the font itself. Some fonts use all of them, but use different numbers. And sometimes browsers and operating systems disagree on which numbers to use. Thankfully, a new CSS feature tells the browser to ignore all of that in favor of the font metric override. Actually, can we just call them Fmods? Like, this is supposed to be a short video. Okay, here are the Fmods. So now, for text that are given font size, I can say 73% is the Ascenders and 25% actually, this is a bad example because it doesn't have any Descenders. Let's go for texts. Cool. So 25% is the Descenders. And finally, 2% is shared between the gaps at the top and the bottom. And now this will be fully consistent in all browsers that support Fmods, which is currently Chrome 87. But wait, what does this have to do with web vitals? Well, the quickest way to get text on the screen is to display it using a fallback font straight away and then swap to the web font once it's downloaded. But different metrics between the fonts can cause a massive layout jump when the swap happens. We can fix this with Fmods. By adjusting the metrics of the fallback font, we can reduce the change in layout caused by the font swap. Like I said, this is in Chrome 87. See the description for more information and links to demos. We also want to find ways to handle other differences between fallback fonts like different letter widths, but we'll talk more about that when things are more concrete. Okay, next feature. Ever been browsing around the web reading a really interesting article, seen a link, clicked it and thought, yeah, okay, but I want to go back to the article. Well, meet the back button. Okay, we've had that from the start, but it used to involve reloading the previous page from scratch. Okay, that was still pretty fast, and that's actually because I optimized my site really well, and it's a really simple site, but you can still see the problem here. This bit of the page is enhanced with JavaScript, and when we go back, you can see it having to reload and re-execute. If the page involves a lot more JavaScript, it'll take longer. The layout may even shift around as elements are added to the page, but let's try that again in the latest Chrome. As before, I followed the link, but this time, Chrome automatically keeps the previous page in memory, but it's frozen to stop it processing and monitoring in the background. This means when we navigate back, it's ready instantly, and that's in Chrome 86 on Android for cross-origin navigations and Chrome 87 for same-origin navigations. This is also a gradual rollout, so not all users will get the feature at once. Also, it's worth mentioning that this feature has been in other browsers, such as Firefox, Safari, and even Internet Explorer for years now. It's been difficult for us to integrate it into Chrome's strict multi-process architecture, and let's just say, in this instance, we've been fashionably late. There are some gotchas too. Using particular web features prevents this optimization, and this list differs between browsers and browser versions. In many cases, you can work around it by deactivating the feature just before the user navigates away using the page hide event and reactivating it when they navigate back using the page show event. Check the link in the description for all of those terms and conditions, I guess. All right, next up, it's portals. Portals are a new HTML element that lets you load a page and render it inside the current page. Here's one. I've scaled it down a bit and given it a border. Okay, I know what you're thinking. This is iFrames, but it's not the same. For instance, portals aren't interactive. If a user clicks this, they're clicking the portal element, not the page inside the portal. Okay, I know what you're thinking. This is iFrames, but worse. However, portals come with their own advantages. For one, they can be activated either by clicking them or calling this method. When a portal is activated, it becomes the top-level page. That, as usual, changes the URL bar. It's similar to a regular navigation, except we had the page pre-rendered ready to go, so it was really, really fast. But let's try that again. And rather than have the portal sitting clumsily in the middle of the page, we'll move it out of view and wait for the user to click that article link. When they do that, we'll animate the portal, then activate it. With a little clipping and coordination, we can use this to create rather pleasant navigation transitions. But that's not all. Check this out. This is the same page as before, but I've added a button to share the article with an external service. The user clicks it and confirms they want to share it. And that's it. But what actually happened there? Let's run through that again, but with code. First up, the user taps the share button. The article site creates a portal to the sharing service, then adds it to the page and activates it. Now, example.com is in charge. The URL has changed. But the user doesn't see this blank page because example.com uses the portal activate event to get a portal to the previous page and add it to the document. To make it clear it isn't interactive, they blur it and add their own UI over the top. Although it looks like a model on top of the article, the sharing service is in full control here. They can trust interactions with this dialogue and the user, they can confirm that from the URL bar. They know who they're dealing with. Now, the user clicks yes and the sharing service captures that event, uses animations to bring the article back into focus, and then activates the portal to the article. And that gives it control of the tab once again. You can see the URL has changed. Not only can portals create navigation transitions, they can create flowing user interactions between sites. And that's in Chrome behind a flag. Which flag is it behind? Well, we might change that between me recording this and it going on YouTube, so see the description for details and links to more information. Like, we're really interested in feedback on this feature. It's fair to say we've been talking about portals as a new thing for a couple of years now, but we really want to get this right, especially in terms of privacy. For instance, when one site contains an iframe to another site, browsers are moving to a model where the embedded site won't have access to its standard set of cookies and other storage. This prevents the two sites exchanging information about you, so it's a privacy win. Of course, Chrome will provide the same protection when it comes to portals. But there's an extra challenge here. If that portal activates, it's now the top-level page, so it no longer needs those storage restrictions. We need to figure out the best way to handle this, so the site can react to the change in storage and update its content, and how it has access to things like login state and user preferences. Solving this problem will also let us do more with page prefetching and pre-rendering across sites in a privacy-preserving way. Check the description for more details on that. In fact, instead of thinking of portals as different iframes, you could say they're more like pre-render tags that you can display. Okay, that's the future, but what about the present? Often the quickest and easiest way to improve the performance of your page is to ensure important content loads early. The preload and prefetch tags do this, and they're well-supported enhancements. We also have the quicklink library, which automates prefetching content that's likely to be needed in the next navigation. Newegg used this, and they saw a 50% increase in conversions and page navigations that were four times faster. I mean, that's huge. See the description for links to the library and more information on prefetch and preload. And that's everything I wanted to show you today. Like I said, bit of a whirlwind tour. I don't know if I've mentioned the links in the description yet, but there are links in the description to further information about these topics. So if you're interested in further information about these topics, and you like clicking links in descriptions, be sure to click the links found in the description to further information about these topics. Where are these links I hear you ask? They're in the description. What kind of information is in these links? Further information. What should you do with these links? Well, they're not going to click themselves, are they? So go on, give them a click.