 All right, so I think I might do the intro like as part of this rather than just picking up a random intro But we'll see we'll see how it goes. See how it goes Are you ready summer? Need a quick emergency sip. Yeah, let's go Hello summer Hello, jake You've seen this before I don't don't I know it. Yep. This is the html spec This is this is the full version of the spec. This is the eight megabytes 12. Wow 12 now They keep adding to it. It turns out. Oh, damn. Um, I actually measured how High this is this is 1.7 million pixels high at this rough size. It's a big document Pretty big document got a lot of apis to cover Yes, it takes ages to fully load and it is janky all of the time that it's loading The bottleneck here is layout and you can see from this bit of chrome dev tools here It takes over 50 seconds worth of layout and that is on a high-end macbook pro. So yeah, don't do that on On an android go phone That's gonna it will it will melt through the table and you'll never see it again Melt straight through to the core of the earth and we'll kill us all so definitely don't do that But what if I told you With less than five minutes of effort I made it Into 400 milliseconds that 50 seconds Down to 400 milliseconds two orders of magnitude less. Is that right? Yes I think so. Yes. I suppose it is and I didn't cheat I didn't delete anything I actually added some stuff. Um, I didn't break Controller nef or commander nef like searching in the document. I didn't break linking I didn't break seo Um, and I didn't even write any java scripts and I'm gonna show you how I did that So, okay, all I did to achieve this is some minor html changes and a little bit of css specifically these two bits of css which are new in chrome 85 and it's Only in chromium browsers right now But the changes I made don't break things in other browsers. They just don't get the optimization And so you're just applying this to whatever because the hml spec totally uses whatever I will show you the correct class name I used in a minute steady on fine I could have used whatever because I don't think it uses whatever already. Yeah, it's not spec Maybe I don't know. I don't know But before I tell you the class name I did use that can be the uh, that's the hook That's going to keep everyone isn't it like they're eager to see what class name I actually used It's going to be disappointing. Uh, but before we go into detail I'm going to show you a little a little bit of background The browser tries to be smart like when it displays a page It doesn't paint everything Like it just paints the stuff you can see it seems like a pretty sensible assumption Yeah, it's great And that means like it saves loads of cpu gpu and memory by just painting stuff as you get to it Uh in the viewport as you scroll up and down the document But In order to figure out what's inside the viewport It needs to know the layout of the page And css is great, right you can do anything in css One of the things you can do is take something that's right at the end of the document and make it appear at the very top um, you can take something which is nested in 100 Divs or elements or whatever And you can move it outside of those elements so Generally, you need to do all of the layout before the painting um, even if like even if you figure out that a box is completely outside the viewport It doesn't mean that you can make any assumption about the children inside that box and so you Yeah Exactly. Yes, it's difficult to lay out just a a small bit of the document until now We have a solution for it now um Here's the html spec in terms of like how it looks in terms of html It's pretty flat. It's a pretty flat document. Uh, there are 22 h2 headings Um, here's the the bit you wanted to know so I mean you wanted to know that class name. Here it comes Um, I wrapped each section in an element and gave it a class. There it is. Enjoy it Um, and that's all I did and of course I used a regular expression to do this because it's a quick hack But it worked. So are you saying you passed html with regex? Yeah, yeah, I just searched for those start headings and those end headings and I did a I did the start and the end tag at the same time and then just went and deleted the first end tag because it doesn't have Yeah, you know, it's easy. It's fine. It's okay. It's a hack, but it works. That's the important thing And then it's the the css What I added is content visibility auto This is one of those new bits and what this says this says the It's like a declaration that says the the inner layout of this element can be deferred until this is in the viewport Until the parent elements in the viewport And that comes with a few restrictions I wish they called it deferred now content visibility is deferred Yes, that would make sense, wouldn't it because we already have deferred for scripts and things like that. Oh, well Or actually for things that enter the viewport we call it lazy So I guess it would be content visibility lazy. I'll also be good. I like it If we're gonna have a spec meeting now, let's do it Let's change the whole thing. Let's unship it. We'll fix we'll fix that one word. Okay. Yeah, fair enough The word is auto that it shipped with And yeah, that comes with some restrictions. It means you can't paint outside the element Uh, which you'll be familiar with if you've used overflow hidden before and it also means that layout can't escape the element So, you know css has collapsing margins This means you can't use those It's but that's like that's position. That's overflow hidden as well. Yeah, so by me the developer saying I'm giving this element content visibility auto I'm basically opting in Or guaranteeing that there is no escaping elements That would make, you know, these layout calculations actually difficult Yes Yeah, um So yeah, so that means that if this parent element is going to be at the end of the document That declaration means it the browser knows that something inside it can't, you know Drift its way to the top of the document and be in the viewport when the parent isn't So, yeah, that that's the sort of guarantee that you give the browser and it enforces that very similar to overflow hidden Um This often leaves the element at zero height like the height of an element with no children elements Um, and that's a problem because that means all of our sections are going to scroll into view at the same time Because they're all just stacked on top of each other zero height uh Which is not good because that means they're all going to lay out at the same time So to work around that because now they're back in view with zero pixel. Ah Okay, yes, this is contained intrinsic size, which I don't know it's it's it's a mouthful difficult one to remember because I always think the first word is content Because the other thing is content. Anyway, it doesn't matter What this lets you do is set the width and height Of the the content of the element while the layout is deferred So it's like a fallback width and height But you are setting the size of the content Not the element and this is something that took me a while to get my head around So it's as if it has a single child element of this size Well, that would only make a difference when you have padding, right? Otherwise, it would be the same No, no, so it's different in this case because I've I've given it a Inner width of one pixel there But it's still going to be a full width element because that's how block level layout works because it's display block Right. Okay. So that's why I put one pixel in there. I thought oh doesn't matter and for the heights I I just guess like I it was the the biggest number I could think of at the time So I just put that in It really it doesn't matter much because it's just a fallback because so when it does the proper layout It's not going to use those numbers anymore. It will give it the correct number All right, so you basically let's say you start at this at the start of the hml spec And you have like the table of contents in view That means all the actual top level sections will be empty boxes with a height of 5000 Outside of the viewport and the browser can skip layouting all the actual children because you said, you know what? Don't don't bother just assume that once you let other children one pixel by 5000 pixel is a result And now when you when you scroll towards the next upcoming section, that's where the browser goes Wait, this is now actually very close to viewport. I'm going to the actual layout But just for this one following box Which might mean that this section could Be larger or smaller than this one pixel by 5000 pixel, right? Yes. Yeah, the actual layout could be Yeah, it could go everywhere so could that cost problems The there is one side effect of that and I will come to it in a minute But largely no it's it's okay Um, but yes, like you're saying the browser can keep the layout really really simple Uh, and it isn't till like the user starts scrolling and then it goes Oh, I'm going to add that more layout because they're getting close to that element And it just defers all of that work But yeah, that's literally all I did With the html spec just those small changes And that is what took the the layout time of the spec from 50 seconds down to 400 milliseconds like 0.6 of the original And like I said doesn't break control enough That still works That's a big deal because I know this is it reminds me a bit of infinite scrollers where for example twitter has these things Where you have the tweets in the viewport and a couple tweets outside either end when you start scrolling the things At the top will get recycled to be reduced at the dot at the bottom to keep your Dom count low and keep layout costs low um, but those implementations are a javascript driven and b Break control f which I've run into like where you try to find a tweet you just saw on your timeline But because it's scrolled out of the view and has since then been recycled control f won't find it anymore Exactly. Yeah, I've run into that too. Um When you do control f on the html spec demo I built for this It's it's a slowdown because you need When you do control f you're not just searching the markup. You're not even just searching the text in the document. It depends on Oh It depends on style calculation. It might depend on some layout as well So it has to go and do a lot of that and it can do it in phases It can do it deferred a bit but to tell you how many matches there are in the document It's going to have to go and do a lot more work than it would Do if you were just regular scrolling, but it works and that's the important thing um And it doesn't break linking either if you link to an element that's inside One of these deferred layout things it will figure it out or or at least it will soon In the making of this demo. I found a bug with that. I filed it and it's been fixed So, you know, maybe by the time this episode goes out a lot And that's actually it's actually an interesting point though because you know things like display none Will affect control f and other things as well That style calculations will still affect the entire document and will Become more expensive. The bigger your document is. It's layout It's really it really I say to layout that gets cheaper with content visibility. Is that right? Yes, it's just layout layout the only thing it saves. But yeah with searching for text um You can have two elements which are right next to each other in the source Like there's no space between them. But because they're both block level there is You know as far as humans are concerned a line break between them um That isn't in source whereas if those two were in line then You know, there's no space between them So, yeah, there's a lot of layout information that you need to think of to actually Effectively search for text in the document But yeah, it's all just taken care of which is it's just great. Here's a live demo Now you're asking me what's the you know, what might be the problem with me just putting 5000 as the box size um Watch the scroll bar in the top right Uh, so as I scroll down there's a little jump there Uh, the scroll bar jumped down And as I scroll further and further and further Eventually get to another section and it's it jumps up And this is it switching from its imagined Fold back layout to its actual layout and it has to adjust the scroll bar to cater for that. But that happens on Mobile platforms already for the same reasons like you've guessed the height of certain elements and the scroll bar Moves around and adjusts itself as it figures stuff out. I think it's fine Yeah, it's it's really a question how much scroll bar consistency or inconsistency in this case is a big deal because infinite scrollers have the same problem to an extent and I guess I guess it becomes a little weirder when you load a page with an anchor that you start in the middle of the document And you scroll up and the scroll bar jumps back down I guess I but I guess it still works if you click and drag It doesn't break clicking and dragging the scroll bar itself. That still works. It probably behaves a bit weird But it should still work Yeah, it it still jumps around, uh, but the it doesn't break the mouse interaction It just looks a bit weird. But yeah, that already happens on you know on mobile platforms one other thing in that that demo, I don't know if you noticed over the uh Hangouts call we're on now, but the uh, there was a bit where it There was a flash of white or not a flash of white It scrolled into a white area and it took a while for it to draw a bit And that's because one of like I said, there's like 12 headings in this massive document So I only have 12 sections and so I scrolled into an area where it actually had to do quite a lot of layout work To be able to render it and you could see that I could fix this by just making smaller chunks So that's one thing to think of as a developer with this is like the number of chunks like More is generally better. Like if you have too many at the start then you increase the upfront layout work Where it figures out where all those chunks are? Um If you have too few then you risk that thing where like scroll into a particular area is still going to be quite expensive Another effect could your nest Content visibility so you have no you have the top level h2s that are now all Content visibility auto with their intrinsic size Could you now apply the same mechanism to the h3 heading so that the stuff inside the h2 in itself again Uses content visibility to create those smaller chunks. Yes, you can do that and it all just works But that's why it's complicated and that's why we had a bug when it came to linking to a specific anchor through the document because like It knows that anchor is inside This box so it scrolls to that box But then it has to lay out and then it realizes. Oh no that anchors now somewhere else So it scrolls again And then it might have to relay out because of all of these boxes becoming visible that weren't visible before And that's the bit that we hadn't done like that's the bug we had is we are only scrolling to the fallback box And it was it was the initial position. Yeah, okay exactly another nice effect for this This is time resizing so resizing here is super smooth because There's not a lot of layout work to do So it's nice and quick and that'll be quick on mobile desktop like, you know We compare it to the real html spec and this is an extreme example, but it's taking Like over 10 seconds sometimes to figure out The new layout for the new width. It really lags behind. I mean You say it's an extreme example But using this bigger document on a fast machine like you're using is probably somewhat representative of a Normal ish document on a low-end phone where you go from portrait to landscape Like that could still happen and there would still be benefits to making those operations faster. Yes. Yeah And even in some cases, uh, you know popping open a keyboard in and out It's going to change the viewport size to to some extent. Um so yeah, this is an extreme example, but You know, have a look at your site and have a look at the layout time And if you're hitting, you know, a large ish Layout time. I'm not saying like 50 seconds if you have three seconds of layout time And if a lot of that is content that's out of view of the viewport then There's a quick win right here, you know And you might not even have to change any of your html because you might have those sections all boxed up already So you're just adding like two lines of css And you can knock like seconds off your layout even if you're knocking just a few milliseconds off It's almost free to do it so Yeah, I it's We've had sort of css containment stuff in the browser for years You've been able to do some of this stuff, but it's been such a lot of manual work, but now a couple of lines of css Job done I actually would love to see this in more like blog templates just built in by default where This seems to be like the perfect application where just when you have a lot of text content potentially Just don't lay out the stuff out of view. It's magic. It's great Yeah, and not just blogs like we see particularly the news sites that have lots of Especially on their home pages lots of complicated layout stuff going on Quick win right there Right there free performance and that's all I've got Well, thank you, Jake You're welcome sir It's been a pleasure and an honor And we're out