Big Data, Zero JS: Cross-Browser Virtual scrolling

So next up we have Michael Kladky. Is that the non American pronunciation?

Did I do that? Okay, that's the non American. That was perfect. The American one is more angry. It's like. Or something like that. Yeah.

Michael is a CEO of push based Google developer, expert, Microsoft mvp, NX champion, visionary, thinker, wearing wonderful mustaches.

I don't know, like the list goes on and on. But Michael's done a significant amount of training and consulting around highly technical topics. I like that he really takes like zooms in on one specific thing and really tries to break it down from a variety of angles and understand how it works and the mechanics of it underneath, which I think is what we're going to get a piece of here in just a few minutes.

I'm going to. Nope, I was going to start telling jokes. No, he's good.

All right, so everybody, Michael is ready. Welcome Michael.

Thanks everyone. Where's my mic? You're perfect.

What can I say? A lot. I believe I visit this conference, I guess in three, four years. I love it.

I believe it is the best, the best place in Europe if not internationally for performance. I can prove that.

Look around, you will see a lot of my heroes here and a lot of cool other people that are very, very into the topic.

I really can can only talk very positive about the conference and even cooler I am here on stage. That is really nice for me. I'm trying to get in here for a while and it seems you just have to wait a little bit. Okay. My Talk Big Data 0 JavaScript Cross Browser Virtual scrolling. I had to adjust the title because if I would put there CSS performance content visibility, PPK would say CSS. We do this stuff with JavaScript.

You know, you need JavaScript. Okay. I want to show you how we can use CSS to really drastically improve the performance. As I would say, quick winner. A low hanging fruit.

My clicker is working. This here happens when you want to center a div in the browser.

I'm not sure it's just a joke, but what I want to point out, it's pretty complicated to figure out where things in the website sit.

How do they look, how big they are, how do they move around and if I change something in between, where do I start to recalculate all their different values? It's really complicated, especially when you go to areas that are not very well visualized. And what do I mean with that?

When you think about flame charts, all the boxes that you know, the yellow, purple, green. Yeah, I'm using professional terms Here you will see that there is a lot, a lot of information, a lot of other boxes under the yellow part, under the scripting and purple and paint green color is empty. So you just have the main browser event and no other information. And that makes it really complicated to understand what is happening and when. I mean really complicated. I mean really complicated. That's a room full of performance engineers. It's not a basic thing, I'm pretty sure not a lot of you know every detail.

Hopefully afterwards my talk wants to talk about some really old stuff. Contain layout, paint, whatever. Like we just need that basics to understand content visibility. That's the main focus of this talk and as I promised, not a single line of JavaScript.

Maybe a little bit, but not for the optimization.

Good. What can you do after you go home from this talk? You can throw in 10 lines of CSS in a website and get from before to after this impact, I would say massively cool impact. And on the left side you see what happens when you bootstrap an application. When you basically turn on your browser, hit the URL bar and your single page application.

That's what I measured here. Single page application bootstraps.

And then when it runs like when you just have the browser open, maybe you have some animations in the background. They will also consume and trigger layout and paint. After you Throw in the 10 lines you will see there is no nothing but very little work left at runtime. And the bootstrap phase shrinked down to the blue area and that is basically adding the DOM nodes.

So it is very powerful. That's what I want to point out here.

My name is Michael, Michael Latke. Ludki is super hard to read, write and pronounce and I even myself don't know how to pronounce it professionally. So let's stick with Michael. It's the easier path. I'm doing a lot of performance work, also other scaling issues but our company is like known for this performance focused kink that we have in the company and yeah, let's talk a little bit about the render pipeline, the browser render pipeline or how I would phrase it, the browser render waterfall.

Why? Because you trigger more or less always the next step.

It's rather basic info so I quickly run over it.

But I guess it doesn't hurt to have a nice and short repetition of this. The first thing scripting. That's what we will not talk about a lot today. But that's normally where your render pipeline starts. You have a browser event, maybe the page load event and Then it kicks in. Or you have some user interactions with event listeners, but there is some underlying script that will kick off additional browser work after that, or in between, or whenever you start to go into the purple phase. And this is all about figuring out where your elements sit, how you position them and so on. And recalculating styles is one of the first steps the browser needs to do. You basically figure out all your style sheets or your DOM nodes and then you make your page look like it's called technically CSS on, but you can imagine it like tailwind. It's like inline CSS that you read was a bad joke for the tailwind users. Thanks for getting it. I'm a little bit slow with jokes. They always take longer than they should. Sometimes good, sometimes not. Okay, recalculate styles. So we know now all our notes and we know all the rules and we know how they should look.

The graphic, by the way, is handmade. Love to point out how much useless time I put in slides after that. After we know how many elements we have on our page, we should figure out where they sit. And layouting is one of the last things that is needed to make a link to the previous talk.

For all the accessibility things that you need to know everything. Paint is a little bit less important, also less impactful. So if you have a good performance website until the layout, that also will have a good performance. If you have people that need your site to be also accessible and fast. So layouting basically draws a two dimensional sheet and then it positions boxes in the sheet and then you have boxes in boxes. So you have some recursive processes going on there and at some point you're done and you know, okay, that's my X and Y coordinate and here will be the box painted in the future. And I'm finally done with the rest of the work.

And then I have this invisible layer, the set index, where I can see if it sits before or behind something.

Next step, optional step would be hit test. I click somewhere on my website, I hover somewhere, a CSS animation fades in and I need to figure out where on my device screen the click happened and where on my page the coordinates are where the event should fire all the purple steps. Done. Let's go to the paint. And here we have two steps in the presentation. Here I will only focus on the paint area. I will not try to optimize composite.

It's already a nice optimization. So let me give you a little bit of context. At the beginning of time, when we had old browsers beginning of the Internet, maybe we had browsers and they had very primitive ways of displaying a website.

They had a paint step. We also have the paint step now, but it was a little bit different back then. And they basically used all the layout information or the other styling rules to generate a massively big bitmap of your website, an image, and then they would paint that image.

And whenever you interact with your website, whenever you hover over a menu atom and the font size would change or the font color would change, they had to repaint the whole website.

Nowadays, that's different. We have not one massively big image. We have multiple different small images separated from each other, painted independently, and then the browser composes those images together into one big one.

If I nowadays hover over a menu item and just the font color changes or the font size, I will only repaint a very small section of my website.

Also all animations and everything you can.

Basically, you should try to push into composite because it also runs on the gpu and that is cool because that will reduce work on your main thread.

I will, as I said, not Talk about the JavaScript.

I will not talk about the composite layer. I will try to focus on the middle things. I will focus on recalculate layout and paint.

And to go on, I want to quickly bring up a couple of buzzwords. The first one is border box. That's basically everything related to layouting. We want to know where our elements sit.

We want to know what boundaries they have, what edges, what ends they have. That all is encapsulated in a border box or in this term here. Then we have visual boundaries.

That is everything a DOM node displays.

And that can be encapsulated within this border box. It could have an overflow. You can have overflowing elements. They could be visible, they could be hidden, depending on on the CSS rule. And that all impacts a lot of paint stuff. And then we will have a third concept. That is the screen, the viewport.

We want to know where on our screen our elements sit.

Are they on screen, are they off screen? Are they in an obscured node?

Are they normally visible?

To go on, I want to talk a little bit about CSS triggers. Let me click the link if that is working here. Yeah, cool. So this is a website that explains basically which CSS rule.

A very old website, triggers which work in a browser.

If you don't know that, I would wonder if you don't know that, you should really remember it. That helps a lot to understand how you can optimize and tweak a little bit what you can do with rules. Which rules will trigger which work. You have all the rendering engines here. You have the first and subsequent updates.

And if I give an example margin, for example, any margin property will trigger layout, paint and composite. Why? Because I will shift my element from left to right or whatever. And that obviously will trigger recalculating the coordinates where my element is sitting. And if I change its core coordinates, I will also have to paint the coordinates. And then maybe there's a composite step.

So that's why margin has here 3 bars purple for layout and then paint and composite. If I would put a background.

Do I have to scroll down now?

Something is happening. Whoops. Click it again. Okay, I have to scroll there. It seems if we use background.

Here we go. We see that less bars are triggered. And if I would scroll down to opacity, we would see that only one bar is triggered.

Only the composite layer is triggered when you use opacity on a background. So you see you have different options and depending on what your goals are, you can go there on different ways. And you can either change the background color from red to slightly transparently red and you will trigger paint and composite, or you can trigger the opacity of the red with a white background. And you also have maybe the same red.

And you don't trigger paint, just composite. Just so you get an idea of what it means to play around with CSS rules. And you can do a lot. It's a very, very deep topic to dive in.

Okay, so this is how we trigger work. We just change. We add a DOM node or we add a style sheet, or we change a style and then our browser will run through that steps will run through the browser render pipeline. So figuring out how much work a page is doing in terms of layout and paint and guesstimating it is not so easy. So I had a couple of different ways how to measure how expensive the work is on a page.

I will maybe try to do it here. And the first thing that I did, Sorry, I stop it. When I tried to trigger relayouting of a page and guesstimate how much work is in that page. I would just resize my page. I can do a measure here and I can resize it a little bit like this. Very professional.

And yeah, that's us.

Very professional. And then we see there is a measure and there is purple, there is yellow, there is green. All the colors in beautiful. Okay. That was how we started to measure the impact. Let's go on a Little bit more in depth, like a little bit more professional. How else could we measure the work that is lying around on a website? We could trigger the zoom level. We can zoom in 0.1% in the page. And I'm pretty sure nearly everything there will relay out and paint.

So let me do that now I will choose another page.

I will use the Nuxt website for two specific reasons.

First, I cannot rant about Svelte. If Rich Harris is here, I can also not blame Angular too much. I use it so often. So I'm like, okay, who is not here?

Alex and Daniel Rowe are not here. Let's use the Nuxt website.

Okay, I turn it on first. I will give you this resize style of thing. You will see. We already have some. Stop it.

We already have some work done here. Let me go to modules.

Come on. Oh, yeah. And we see purple and green, but very uncontrolled. What I prefer to do is I start recording.

I have my bookmark here, and I click it and I zoom in and out this 0.1% in my page and then stop the recording. And I should also see work produced only purple and only green. And in this case, I even have luck. There is a slight little long task here, so we could even try after my talk is done and I have time left to optimize it live on stage. But this is how we quickly guesstimate. Is there a lot of layouting and paint work? And if yes, will it pay off for me to try it out? And I can promise it will pay off.

I tried it yesterday and it took me around 10 minutes to figure out the two, three elements that I need to encapsulate. And it was already better.

So this is how we start the scene and how we do a full page relayout. Then I went on.

As a performance Engineer, I have 30 minutes left. As a performance engineer, I always want to do my best. I want to know everything on the deepest level. I want to be able to share it. And most important, I want to be able to reproducibly measure what I do. And when we started to fiddle around with CSS rules, especially with contain and content visibility, it was kind of really hard for us to set up a proper demo setting that we can demonstrate the impact of it. So I will show you what I ended up with. I'm pretty happy with that setting here, let me close that. Let me close that. And here I can insert demo items. I can also remove them. And then I have two buttons. I will explain later what they do but they will add DOM nodes.

Here we have a green button that I will use to show how we can introduce paintwork. And then I have purple button that I will use to show how we can insert layout work if the browser is not dying. And if I have that in, I can also use CSS triggers here. For example, I have an animation.

I hover over the button, the button has an animation, the animation triggers margin and changes the background color and boom. I will trigger layout and paint in the whole page. So I can in a controlled way add DOM nodes and I can in a controlled way trigger work. I can here trigger layout work. I can trigger only paint because here I only change the background color that will trigger paint in my browser only.

And I can only trigger layout with this button here because there is margin that is adjusted only and no other property. So this is our test setup.

This is how we claim to be able to reproduce the impact of CSS contain and content visibility.

Okay, then I have other buttons here, just that you get a little bit more of insights of what I do here. And if I click one of those buttons, a border gets added to the box here.

And that means that I added a CSS property contain layout to this box with the images. And if I click on paint, the color changes. And now I added contain paint to this box. So just that you will see a little bit later on how we can apply different styles and how we can do that.

One more cool thing I could tell you about our test app, but let's first go on and dive a little bit into the first CSS property and then I show you some cool tricks with layout.

Okay, Contain is the property. We have a multitude of options. We have layout, we have paint, size, style.

I will not talk about style, content and strict that are shorthand. That is basically a combination of the other four or three options that we have above.

Where is it supported? It is everywhere supported, but in Internet Explorer. I'm pretty sad about this.

I'm using EA a lot, especially version 6 and 7. So very sad that it's not working here.

But recently it shipped for Safari and I'm very happy because I can finally say it is cross browser and I finally can use the title cross browser for that. And that's amazing. Not only contain is supported there, but also content visibility. I will talk about both contain.

I will only show you 3ish options. I will demonstrate and clearly verify scientifically measure the impact of layout of paint and of size.

I have a visual system for that. Whenever you see a Dashed line. That is my border box. That is the layout that I want to place somewhere in my page. And whenever you see this dotted green line, it is more for paint.

So let's start on contain layout. And what you see here is a very old but lovely video that demonstrates what happens when the browser layouts the page. No paint, just layout. And please now look at the three, four bars that get drawn now and notice how they will iterated recursively. So it's not one time where they will be placed, but multiple times the browser iterates over those boxes. I'm not sure if this process here that is recorded is up to date, but something like that is happening and that's a very nice and beautiful visual animation of what can happen with layout. So there's no paint. It's just figuring out where the box is sitting, how much space the box takes. And. And you also see you need to do that process multiple times because it could happen then that you calculate layout for this box, then you calculate layout for another box. But if you're done with the box, you will shift it a little bit and then you have to recalculate the rest. That's where all the work is done, often multiple times. And it's a lot of work. This and recalculate style basically is the super most annoying thing and very, very hard to f recalculate styled. But this is for the last part of the talk. Let's talk about the performance impact of contain layout.

What can I do if I add this class this CSS rule to one container? I can shield.

I can shield this container and I could not let layout triggers bleed out of the box. Leave my border box and go up to the document root and trigger relay out of the full page of the full document. I can also shield boxes and say even if the full page is relayouting this one part of my page will not because I know the size, I know all the dimensions and I know how to treat has also a design impact. It will oddly mess around with how your element is positioned. You will heavily feel that set index changed.

Even if it didn't change, it was just like not visible to you. And those are two things that I want to show you. The perf impact and the design impact. Let's go to my demo page. Let me click the remove button and I add simple items and I will show you the easy part. I want to show you the visual impact. So I have my items.

I click here on children and then on layout and every item now gets this dashed box and if I hover over them, you see it's already broken, they overlap each other. If I would remove it on none, it would be non broken.

I could see that the menu is very nicely visible everywhere. So that's what I meant with having a messed up set index.

It only matters if you have. If you really need this overlapping style. I have a lot of cases where you don't care at all if this set index problem will pop up. If yes, you could also try to fix it with some additional work. But that's it, that's the downside, the visual downside, the performance impact of it is even more drastically. I love to demo that and I have to explain a little bit more how I did it. Oops, let me try that again.

Okay, so I was sitting at home and I'm like, I want to reproduce a measurement where I put DOM node somewhere. I add the CSS rule and then I can measure the layout work before and after and then I will see result. That was what my goal was.

It turned out it was not so easy to produce layout work only because as you remember, browser render pipeline, Rosalinda Waterfall, if I change layout, something will get relayouted, moved somewhere. So I have to repaint it and most probably also trigger composite.

And it took me a while how I can do that.

And let me click the debug button here.

I started. Is this visible? Yeah, I started obviously with some DOM nodes and I thought, okay, what is layout work? Now that I know what the browser render pipeline is, now that I have CSS triggers, what can I do? And then I started to nest boxes, like very deeply nested boxes. And then I made a very shitty layout in the last box with 10 boxes here, the one that goes down, it's very unefficiently layouted here.

And if I then would start my recording and I would trigger this layouting button here where my margin goes plus minus, plus, minus, and I would stop it, I would get my measurement. Let me have to zoom in maybe a little. Not zoom in, throttle a little bit. Let's do a six times throttling. Let's refresh.

Let's refresh the page first, then enter the stuff, then put throttling.

Okay.

Ah, sorry.

So the last part of the measurement will be interesting.

Good. I zoom in here and you clearly see a lot of layout work, but also green paint. As I said, every time when I lay out something, I also get paint. And I was pissed because I only want to measure layout. So how can I Get rid of the paint and keep the layout work.

How can we do that? I was sitting at home and the best ideas come on the toilet, under the shower, or at four in the morning.

And in this case it was four in the morning, slightly drunk and I'm like, I know it. The paint surface.

The bigger the paint surface, the more paintwork is done. What if I reduce the paint surface to zero? What if I make the boxes here zero width, zero head and overflow, hidden. I will paint nothing but the content because the browser doesn't know that the content of the boxes they have to get relayed and calculated. And I will do the measure. And I believe that's the best part in, in this whole talk here for me. And I look in the mesh and I see nothing because my measurement is broken or in my browser, I don't know, I should see only purple.

I will relay it again. We'll try to not waste your time too much record.

Trigger the layout thing and we see only purple.

Wonderful. That's what I wanted and what is really most critical to demo all that stuff. Now I can start to demo. I add nodes. I can not only trigger layout work and I will make two measures. I will trigger the layout work, then I will add the rule to my container and then I will trigger the layout work again. Let's do that.

I will start my measurement, trigger the layout button, wait for some minutes, add the class layout again. And as the spec is claiming off screen impact is given.

I move the nodes off screen and I trigger it a third time.

So the spec says it even works has a positive impact on off screen items. So let's check that out first measure. Nothing shows clearly. If you look on the minimap. A lot of layouting work. After I apply the class the CSS rule, the work is gone. Beautifully measured, only purple.

I love this chart. It's the best flame chart I ever made in my life.

And if I move them off screen, I clearly see specs are wrong. We disproved it.

No impact layout has no impact for off screen notes. Why should it? Layout doesn't even know if it is painted, if it is visible or not. So why should it have an impact? But paint has an impact. And paint is the second option I want to talk about.

And then speed up.

I showed you this. This is a lab measure. Very beautiful.

You see no improvements. Improvements and improvements off screen. No impact for off screen. Nice picture. Good.

Next is paint. Paint promises even more than layout. Paint promises the shielding of both sides.

Paint promises to reduce the visual boundaries make better organization of it. Like, a lot of stuff. I was like, pretty bold statements about contained paint. Let's see what other downsides it has. And of course, it also. Sorry, do you want to make a picture? I go back for you.

Done. Can I. Thanks. Thank you.

Okay, so you get a design impact. Obviously, if you have something cut off, it looks cut off. It's not hard to get, but I can show you what I mean.

If you reduce. Let me add here, let me move the.

Let me stop throttling first. Okay.

Okay, good. Yeah, that's what I want. Good. I add some atoms. I have this hover effect. I add my paint to all the childs and you see it's cut off. It's not even like hidden below. It's really cut, obviously, because you reduce the. The paint surface. Okay, let me remove that.

Let me add some paint notes. And here I need help.

If someone in the audience can help me to get rid of more of the layout work and have only paintwork left, I would love it. I didn't make it for this one, but it's good enough. Thing is here, I trigger paintwork, I add the class.

Something seems broken and I trigger paint again and let's hope it works.

No, it didn't. Let me try it again.

Demo seems slightly broken.

Aha. Okay, I will just try it one more time and then I will show you the measure. I will stop that recording, start a new one.

Hover paint.

Hover stop doesn't work. Okay, my bad. I have pictures.

So this demo didn't work and I somehow failed it. So I made, of course, pictures. Yeah. This is how it looks. You have something unoptimized, you add the class, you get like a sixth of the work, and if you move it off screen, you have zero work left.

That is really impressive. And it's just one CSS rule.

Let's move on size. Let's quickly scratch it because we need slight of that information for later. But size has not really have a good performance impact. It is just very annoying because it will shrink all your boxes to zero if you don't specifically mention how much dimensions, width and height they have. It's annoying and not a lot of impact. I was like, why do we need that?

Because they have impact later on when we use the shorthand. Shorthand number one is content. It is contain, layout, end paint. Down below, you see the CSS rules.

And then strict. And strict is layout, paint, end size.

And strict claims to have the biggest performance impact. I can show you later. How that looks, but it is very annoying to use. I made a table that shows you how easy it is to use the CSS property. Like if you put it on a box, what can you assume? How much you need to fix and what the impact is. And as you can see, size, moderate, strict, a lot, but also hard to use.

I suggest content, super easy, nice to use.

And since it is supported in every browser, instead of using strict, I would use content visibility.

To talk about content visibility in the last 10 minutes here, I want to remind us a little bit about the viewport that we have off screen and on screen nodes or on fold and below the fold or above the fold and below the fold items. We have not only off screen nodes, we also have obscured nodes. We have nodes which top is visible in the browser, but the node is very long and on the bottom somewhere you have other nodes. They are not visible, they are like thousands of pixels out of the screen. But as the edge of the container is visible in your viewport, you will somehow also impact the other nodes. That's called an obscured node.

What else do we need to know? We need to know viewport, okay, it has an edge at some point, it goes below or above the viewport.

Then we have browser native features, we have viewport observers and we have SAS observers.

And those tools we will use or the browser uses under the hood. But I will use those tools to explain content usability and contain intrinsic size. What's the next thing? It is supported everywhere. Unfortunately not in Internet Explorer 5 and 6, but they are working on a polyfill for that. I'm just kidding.

Content visibility is native virtual scrolling without JavaScript. Yeah, that line is for PPK. No, JavaScript. You hear it? What does it do?

You put it on an element and then it recognizes the element. It registers. It is my element. On screen or off screen, it will have these observers on it and it will recognize the size and dimension of these elements.

It will recognize how big it is now and it will recognize if you change the width. With these two things, you can imagine that you could measure the element, track where it goes and if it moves off screen, you just do stuff to it. You remove the styles or you, I don't know, do the magic what the browser is doing. The browser will completely remove that element from the processing. It will not pop up in recalculate styles in layout, in paint, nowhere. It is the only tool or let's say rule trick that I know how to quickly fade recalculate styles. That is not an Issue.

But it's just because you have a lot of style sheets or you have a lot of DOM nodes, but you need all of them. That's one of the only things I know that we can heavily hit to recalculate styles.

Let's look on what it is promising. Content visibility promises a lot. It promises everything that layout does for us. It promises everything that paint does for us. It promises to be less annoying than strict contains. Strict. It says I'm better than strict. You can give me more easily a height and dimensions. And the really, really, really good thing. It promises that it will detect nodes and when they go off screen, it will completely remove them from the browser. That's the promise.

The design impact or the hurdle is you need to deal a little bit with static sizes. But it's not as hard as with Sass itself. I have some minutes left.

I will go to my demo page here.

What do I want to demo? Ah Sai. Okay. Let's try to add layout notes on and not crash the browser.

Sad. Let's try to only add nodes.

It's a lot of work. Okay.

And then I add random other things. Maybe that works just something that is not only layout work.

No. Why is my browser crashing all the time?

It's very hard to understand.

Please. Okay. Okay. Now I can measure. I can do a measure. I will trigger my layout paint all of that quickly. See how it looks. Looks good.

I have some purple, some green. Wonderful.

I will remove this measure. What I will do is I will compare strict and you can see if I put strict. The collapsing problem happens with content visibility.

So let's do that. I put on none. I click measure.

I trigger both layout and paint because they claim they do it for both.

Then I apply strictly. And then I apply content visibility.

And then I stop. I will not do the off screen measure for now.

And I will just want to demonstrate how brutally cool the impact is. You see, they are kind of similar, but visually I had to do nothing to apply content visibility. It looks exactly the same and it has the impact. So that's why I love it way more.

There's also another impact that I want to show you. I measure it on screen. I trigger layout and paintwork.

I move that node 3,000 pixels down, trigger the same work again and drum roll. Nothing.

There is nothing. Not a single task visible here. When I move it off screen and on screen it already has this very beautiful impact. It's massive.

I would applaud now, but I have five more minutes for a demo.

Yeah. Thanks for the APPLAUSE But I have more. I have more. I have pictures.

Obviously. Never rely on a demo. Always picture it here.

Pictures on the top you see the layout impact on the bottom. The other way around on the bottom you see the layout impact. On the top paint. This is scientific. The numbers are very tiny. If you on a real website, it has massive impact.

It's just very hard to reproduce accurately. So therefore this measure.

Before I go on, I have four minutes left.

I also made a nice table to give an overview how to use it. Where it is hard to use or not. I believe this is very easy to use. I love content visibility. I try to use it wherever I can. It is super quick and small fix and it has measurable like significant impact on your website.

What's next? I have demo websites where I applied that. This demo website was interesting because it has a very bad bootstrapping phase. Let's ignore the yellow part. But if I click on that page specifically somewhere, it does a lot of layout and paint and it has off screen notes and they also trigger stuff. So we have everything we need to demo. And if I would apply a content visibility, it would look like this. Scripting stays the same. But I didn't promise anything about scripting improvements. I told you I will not use JavaScript and you can see the css.

Sorry. The layout paint recalculate style is nearly gone. And if I go one back, the last part, off screen paint, where is it here. Off screen paint of images is also completely gone. If you don't love that property, I don't know what your job is or what you do in your life, but. Okay, we can discuss it later.

What else will I waste your time with? I will lose. I will not lose. I will use the last three minutes to show you how I optimize a website and I will use the nuxt website because we love each other so much.

There's no Daniel here, so I can't really do that. I'm very happy I can do that. Messing around with framework sets and improve them.

Good. Let's scroll down, add some items. While I'm scrolling down, I could try to look at the footer, but no. The infinite scroll always adds items so I will never see the footer. But I have a lot of items now. Let me add more.

Cool. I believe that's a good amount. I believe it is 50. 50 of those tiles are visible.

I stop measuring. I will really make sure this time that I don't have throttling on. Perfect. And then I do my very professional Resize.

No, just kidding. I do my very professional full page relayout.

Click, click, click, click, click, click, click. I stop it and I have this beautiful spikes and all of them are red.

And if I see that, I'm like, yes, that will be good. It will work. So we are happy with that website because it is producing a lot of recalculate and layout tasks. Not because of nuxt, but they use tailwind. And a couple of those CSS rules are not very well thought. So it's not a problem of nuxt. Good. What I do now I will go on quick sources will show you what I did right before I set every image. Let me zoom in for you.

It's the last thing. Then I'm done. I'm not over time.

I'm just unable to navigate here.

Okay, can I do plus? Yeah.

Every image and every SVG will have contain content.

Remember layout and paint.

Every image and SVG will have contain content visibility auto. And then I have three other rules and that's it. I have every tile like all of those tiles here that you see. Every tail has a red border that I can see if the style is applied and content visibility auto.

Then I have a height of 238 pixels. I guesstimated it.

I could write any number here. Let's put 280. It will still work.

Now I most probably broke it, but let's see. And the footer that I could not see. I was guessing what is in the footer and I said there must be an H3. There must be an L1.

And I will also give them some 18 pixel head.

Okay, let's shrink that. Let me.

What's this thing here? Save it. How can I apply that here? Play button, play. Boom. Red borders everywhere.

I scroll up and I do my measurement again.

I run it. 1, 2, 3, 4, stop. And all the red is gone. There's no red anymore.

And my layout task shrinked down to nothing. Thank you, ladies and gentlemen.

Awesome. Oh, I was like. I thought he was just thanking you for applauding like on cue. It was nice. Thanks, Michael. Here, we got a couple questions I made drinking. I need water. Oh yeah, water is fine. Don't take your time. You got it? I have it. I have it. Thank you. Okay. All right. So first off, I think you mentioned kind of the beginning that the just a quick one.

The composite layer using the gpu. Do you know if that's only mobile and tablet or does that apply to desktop as well? That is applied on every browser. On every browser. Desktop mobile, doesn't matter. Desktop mobile. Okay.

Is there a risk of. I mean, the impact.

First off, I don't know if I've ever seen so many profiles without yellow. Like, I just, I've never seen that before and it was really cool.

It's really cool. Do you. Is there any risk of over applying some of these properties? Like, is there a downside? Like, I feel like most things come with that cautionary tale where like, oh, preload is good, but if you preload everything, it's bad, you know, is there a risk to that?

I tried it, of course, to disprove or figure it out.

So far I could not see any downside in terms of performance, but a lot of downside in terms of extra styling adjustments.

Sometimes you want to apply the rules on a large field on many, many DOM nodes. You cannot test all of them and it could happen that you sneak in some layout problems with that.

I saw a couple of times already. Okay, do you know if there's a way of capturing any of this, like in rum data? Like if you're doing inefficient rendering of stuff off screen or anything like that? Or is this more synthetic at the moment? So what we did is of course we used it in real life projects and they have measurements and we dropped INP significantly with that.

So it is measurable in with your arm measurements. Whatever tool you use. There are a couple of really cool tools on the market and it will definitely improve it. Like the two things for NP is tracking and relayed. So half of it you can, I would say tackle with it. I was going to say, I suspect long animation frames could potentially be helpful there as well. So yeah, it could also be impacted in a nice way. Do you think in general, like there's somebody was noting that they were. I think maybe they were inspired by the talk and looking around and couldn't find a lot of examples of people using the properties. Would you say this is in general just a missed opportunity? At the moment I would say it is like fully underused under hyped. I don't know how to explain it, but it's like it's very old. Contain is I don't know how old, but at least four years, I believe or even older. Five and content visibility the same. It's.

It's not often used. Not a lot of websites that I find use it. Maybe because sometimes it's. It's hard to directly understand how you apply it, how you measure the impact. But yeah, I would say it's underused completely underused. Well, I appreciate you hyping it up, then. All right, thank you, Michael. Again, thank you.