Slashing layout cost with content-visibility - HTTP 203

[@bengelliott]

that synced clap was very satisfying

[@dassurma]

RIGHT?

[@jakearchibald]

We do it to help sync the audio for our editor Lukas. Although a few days ago he said "btw I don't use the clapping to sync the audio, but I didn't want to tell you because I've been enjoying the clapping so much"

[@TheNeonRaven]

The scroll bar jumping around like that does feel really jarring on desktop, especially on windows where the scrollbar is often visible. I can't help feel it would also be incredibly easy to lose your place if trying to scrub through a document to find something. There is obviously performance gains to be made here for large documents, so there is a good chance this trade-off is worth it, but I don't consider this "no big deal". Perhaps another enhancement to this that helps mitigate the issues (depending on the size of the document), is to remove these css properties on desktop with javascript after the page has fully loaded, or even incrementally on requestIdleCallback for really large documents. That way, you still get the benefit a first initial paint, but once that is done it finishes laying out the rest of the page so it's ready.

[@hobbyturystaSEO]

high five

[@jakearchibald]

I like the idea of gradually allowing it to lay out. Doesn't help with resize performance once laid out, but I guess that's a minor thing.

[@TheNeonRaven]

@@jakearchibald I guess for particularly large documents that resize performance is an issue, you could always add some sort of "onresize" event listener that re-adds the class that has these properties on it, and then debounce the removal of that class again after 1 second or however long is deemed suitable? I wouldn't be as concerned about the scroll bar changing during resize, as that happens anyways, and you aren't actively using it if you are resizing the window.

[@TheNeonRaven]

@spYro I think we're pretty much talking about the exact same solution here, just instead of the browser natively handling this for you, using javascript to remove the CSS that they are talking about in the video. For potential drawbacks, see the comment above by Jake. :)

[@WizardCM-1337]

Yeah it's a dealbreaker for me. A scrollbar is a user's only way to understand where they are in the document. Messing with that should always be a big "no-no".

[@hypersonic12]

We ship this in our app, specifically for a font dropdown menu that has to render several dozen different fonts. Setting content-visibility: auto to each menu item completely eliminated the occasional hang when showing the menu for the first time.

[@JelleDeLoecker]

Great stuff! I do wonder how the "auto" and "contain" bit made it in when it's like one of the first things these 2 people take note of.

[@marufhasan9365]

"Gone but not forgotten" - that was sweet.

[@panas3002]

Who is that person?

[@cabbarserif1229]

@@panas3002paul lewis famous for coining FLIP animation

[@rishabhanand4270]

Dangg, that was some optimisation.

[@N0r8]

This is one of the greatest achievements of css for all this years.

[@floriel]

Good timing, thanks for the video! I was looking at the status of the wicg yesterday and saw it was abandoned, display locking spec was to replace it. Content Visibility will be useful for list, especially when the size of the content is fixed. Looking forward to try it out!

[@LeeSmith-cf1vo]

This is pretty cool, sounds like it could make a substantial difference to our webapp. Question - if a box has been in the view at some point, and thus has been fully laid out, will it retain its layout once it is out of view, e.g. for the purposes of the scrollbar. (obviously assuming its layout it not changed in any way)

[@alystair]

Another nail in the VDOM coffin, lovely!

[@LarsRyeJeppesen]

Agree!! RIP VDOM

[@LarsRyeJeppesen]

The boys are back! yes!

[@hobbyturystaSEO]

"oh yes! oh yes ! ha ha ha"

[@LewisCowles]

Jumpy scrollbar could be mitigated, but on any page with ads can lead to accidental click-throughs. Likely that won't bother Google though as they get paid via ads...

[@NZTeco]

21.09% improvement! Great work! Any similar resolutions for LCPaint? 😊😊

[@jonathan-._.-]

oO does it also unlayout if the content is out of view ? - i mean it just means it odenst do the layout until its in view it doenst really guarantee that nothing breaks out of it right ? - like i could for example display a fixed header that is only visible when a certain section is in view or similar

[@jakearchibald]

It does unlayout! But it can use the previous layout of the parent as a fallback size

[@basix250]

So what I understood is: content-visiblity: auto; implies contain: layout?

[@mathiasbynens1518]

Woah, nice! Any plans on upstreaming these changes to the HTML Standard?

[@jakearchibald]

We've discussed it briefly. Once the bug fixes to anchor linking hit stable, we'll look at it. Some folks are a little uncomfortable with the scrollbar thing, so they'll need convincing.

[@velara314]

@@jakearchibald for the scroll bar thing maybe add a tween to the thumb position between the jumps or pause the thumb to let the scroll partition catch up. a UI designer can help resolve something like this. also if you do background layout you could have each section ready if someone scrolls. so if someone is reading from there to down everything could be laid out already. once a deferred section is laid out it does not need to be laid out again correct?

[@WilcoVerhoef]

​@@jakearchibald Or set the contain-intrinsic-sizes for each element using JS right at the start, using a lookup table for known calculated size estimates for each screen width.

[@TheTrainWatch]

@@jakearchibald I see this is still only supported in Chromium. I wonder if a “lazy” option would help encourage adoption elsewhere as a resolution to the scroll bar issue. Lazy could work just like auto, but would start laying out subsequent blocks in a lazy manner (i.e. when the main thread is not busy). This would result in most of the scroll bar changes occurring when the user is not scrolling. Similarly to page load, on viewport size changes, the browser would discard all of the blocks except the visible one, then slowly start building the surrounding blocks when the main thread is not busy. I think there are also some browser assumptions that could be made on resize to help reduce the scroll bar shift as well. The area (width*height) of a text area could be assumed to be constant. And the aspect ratio of all images could be assumed to be constant. So any blocks that have already have been laid out, the browser could guess what the new height is, overriding the css guess (assuming there isn’t a css media property that adjusts the intrinsic size for different widths).

[@emilemil1]

You could probably mitigate the scrollbar issue with some preprocessing. Load the page and get the actual heights of the hidden elements, pull those values out and set them as the intrinsic heights. Tools could do that for you as part of a build step and generate some sensible values for various browsers and screen dimensions. Should be far better than straight up guessing, and even less work once you've got the pipeline set up.

[@dassurma]

But to know the _actual_ height of an element, you’d need to do the layout, which is what this is trying to avoid in the first place.

[@jakearchibald]

@@dassurma I think they meant preprocessing at build time. You'd have to do it for various viewport widths, and I'm not really sure it's worth it

[@emilemil1]

It's a build step similar to minification or SASS compiling, it has no runtime penalty. Imagine doing this by hand, but instead a build tool does it for you: 1. Load up the page without setting content-visibility or contain-intrinsic-size in your stylesheet. 2. Note down the height of all elements that you plan to add content-visibility to. 3. Complete your stylesheets by adding content-visibility to all of those elements, and set contain-intrinsic-size to the values you noted down. Of course it's still just a guess since the actual height will vary between browsers, screen sizes, and for highly dynamic content that can't be preprocessed, but that's not the point. The point is to get a decent estimate so there is less scroll bar jank.

[@dassurma]

Ah you want to generate a “better” guess. Yeah, that make sense!

[@johnsontinuoye8428]

To account for browser sizes, you could generate the intrinsic heights as fractions of the viewport width based on the size used in build time. Wouldn't still be accurate though because browser width could also affect the rendered height.

[@divyasripantangi7869]

can u plz tell me how to fix the contents not appering like overflow:hidden anymore causing by content-visibility:auto?

[@SalmenBejaoui]

Does this impact Web Core Vitals Cumulative Layout Shift (CLS)?

[@jakearchibald]

Not in a negative way

[@aadlr]

The W3C should really reach out to allow the dev community to vote and express feelings about the spec syntax before it ships. Jake and Surma are sitting here agreeing that the spec syntax for these new CSS rules is utterly confusing and confounding.

[@mprasanth18]

Will screen readers able tyo read the text that are not rendered because of content-visibility:auto?

[@divyasripantangi7869]

when i applied content-visibility:auto to all the sections in the container but the some content in the section like tooltip which have position:absolute is not visible completely.

[@emkisn]

yesssssssss, this is amazing, thanks a lot for you work

[@nicewithacupoftea]

It's good to be back

[@linwang6659]

parent element set content-visibility auto，child element set position fixed， it renders a bit strange, the child element is not positioned relative to the initial containing block established by the viewport.

[@jakearchibald]

It becomes a stacking context so it can make the layout containment guarantees

[@jincyquones]

Does it work with elements added to the DOM dynamically?

[@sasikantnair]

I applied this on my feed. It works and the feed posts are fast now. However, this is causing screen flickering on my linux Chromium based browser. Tested it in 2 different linux laptops. It works fine on my mac.

[@jakearchibald]

Please file this at crbug.com and give me a link to the issue. I'll make sure it reaches the right people.

[@ucheozoemena2499]

I wonder how much different this is (under the hood) from CSS contain. This seems more intuitive and easier to use than CSS contain.

[@dassurma]

It’s based on CSS Containment, tho :D

[@jakearchibald]

Yeah, it's like a high-level easy to use version of CSS containment that doesn't require JS.

[@ucheozoemena2499]

Ahh okay makes sense! I’ll dig into it more.

[@DamonHart-Davis]

@@jakearchibald I just started automagically injecting contain:layout (I use floats) and contain:content through templates for large static pages. Have I been wasting my time? (No, I haven't found a good simple way to actually measure any effect of this blind 'optimisation' yet, shame on me.)

[@mimosveta]

I just tried it, and it did nothing for my load speed... jake is kinda weird at explaining things, he's funny, but he's not explaining to someone like me, so, am I supposed to put this on all elements, or only top level elements?

[@javiasilis]

Never imagined this would be a great feature for infinitr-scrollers. Yep. This solved a lot, but a lot of problems!!!

[@beyondthehorizon94]

Thank you guys.

[@cwc2005]

Does this work with named anchors? What happens with the content that are "in between" the link and the anchor on click? Will that cause a sudden render that causes delay?

[@cwc2005]

Perhaps the deferred layout can be further refined to continue layout on the rest of the document after the initial, faster layout is completed?

[@jakearchibald]

@@cwc2005 we discuss this exact thing in the episode. They work, but I found a bug when making the demo for this video. If you find linking bugs in Canary, please report them.

[@eligrey]

Can't you use contain-intrinsic-size with the vh and vw units? Why did you use an arbitrary `contain-intrinsic-size: 1px 5000px` for the HTML spec? Surely you'd want to pair `content-visibility: auto` with `contain-intrinsic-size: 100vw 100vh`

[@jakearchibald]

You can use those units, but remember you're setting the fallback size of the inner content, not the element size. Because of this 100vw is likely to land you with horizontal scrolling. 100vh is just as arbitrary, and less accurate in this case.

[@DennisJ42]

@@jakearchibald why would they be of the inner content and not the outer? Am I missing something? Why wouldn't you want to set the outer content intrinsic size?

[@jakearchibald]

@@DennisJ42 because it's the inner layout that's being skipped. The outer element is still being laid out.

[@jakearchibald]

Eg, the container element might be part of a flexbox/grid, so it's still being laid out by its parent, but how much space it takes up in the flexbox/grid is determined by its intrinsic content size, which you set with contain-intrinsic-size when the children of the element aren't being laid out.

[@DennisJ42]

@@jakearchibald Oh I think I understand now. Thanks for the explanation Jake!

[@hobbyturystaSEO]

I have agreed with Surma => its magic => You should write the BOOK how without BLACK MAGIC You Hide the content by using style. The Jake T-shirt logo displays the timeline of how this process was made step by step. Scroll horizontal ??? hmmm does it work as well? Does it CRAWLER friendly and does it impact SEO and DA ?

[@jakearchibald]

Yeah it works with horizontal scrolling using the same mechanism

[@hobbyturystaSEO]

@@jakearchibald good job!

[@ranbuch]

I'm having a problem when using content-visibility with box-shadow, it's not rendering it at all. It does renders the box-shadow when using inset shadow, probably because the shadow is outside the component but that's always the case when using inset shadow. I thing chromium should change it.

[@ranbuch]

Actually inset doesn't work for the element itself, only outer does. For the child only inset works but outer doesn't.

[@jakearchibald]

@@ranbuch Remember that content-visibility also prevents child elements drawing outside the parent, like overflow:hidden.

[@ranbuch]

@@jakearchibald so I guess it makes sense. I guess you can hack around it by wrapping with another element and add some padding. Thanks.

[@yasinyaqoobi]

This is great. The problem I am having is that content visibility creates layout shifts.

[@jakearchibald]

The layout shifts shouldn't be visible though, aside from the scrollbar.

[@denovichas]

this will be nice when i works correctly :) the demo doesn't work in chrome on windows if you use the scroll bar. this feature also breaks element.scrollTo() if the element is off the screen.

[@jakearchibald]

Have you tried in Canary? I filed some bugs about this, and many have been fixed. If not, can you file them at crbug.com? We're pretty keen to get this fully working.

[@denovichas]

@@jakearchibald no... I wish I had time to. #crazydeadlines

[@jonathan-._.-]

ctrl +f puts the jump marks on the scroll bar so it has to know the layout

[@jakearchibald]

True, but that can be lazy once a match is found

[@adasjdaksjdlkasldjas]

Tested it on a page that has some heavy gradients and images. But it got slightly slower and the scroll got janky.

[@jakearchibald]

This improves layout time, not paint time. It shouldn't make things janky though. Is the example public?

[@nicewithacupoftea]

I feel like this was built mainly for buzzfeed

[@hobbyturystaSEO]

DISLIKE

[@31redorange08]

Thoughts on the Jabras?

[@jakearchibald]

For sound quality and isolation, I prefer my Shures, but the Jabras are just so much easier to take in & out that I don't really use the Shures anymore. Might be a different story if I was still commuting.

[@dustinpoissant]

What happened to Paul?

[@jakearchibald]

He hasn't been part of the show for years

[@dustinpoissant]

I realize this, on his personal channel his last video was about 16 months ago. Just wondering if he is still doing development.

[@samirsaeedi74]

He is on the DevTools team now.

[@aaronhedgesmusic]

Who is the gone but not forgotten dude on the right hand side? This mystery has been bugging me haha

[@dassurma]

That’s Paul Lewis. He was a host on this show before me: kzbin.info/www/bejne/f6TOmoeMpq2jZ5o

[@quintinmaseyk6975]

Very cool!

[@issam2901]

Paul lewis ❤

[@davidmaxwaterman]

"melt through the table"?!? you mean, "melt through the grid"....or at least, "melt through the flexbox".

[@Benimation]

I know a number bigger than 5000

[@jakearchibald]

impossible

[@jyz]

Perfect!

[@SJ-gm7oh]

Nice...!!

[@kmylodarkstar2253]

it's looks like css observables? XD

[@jakearchibald]

I think ResizeObserver and IntersectionObserver are lower-level layout observers.

[@Ostap1974]

Interesting option, but feels really hacky for my taste.

[@jakearchibald]

Then throw away your phone in disgust! This pattern is used a lot in native apps 😀

[@samirsaeedi74]

Well we were supposed to beat them, not join them!

[@RickBeacham]

HTML is typically better then JS.

[@moto_venom]

The scroll twitches as if in seizures.. dislike

[@jakearchibald]

If you see this happening, please report it at crbug.com