I'll cut the crap out and jump directly to the two line of css that you need to add to improve your performance by approx 7x:
{
content-visibility: auto;
contain-intrinsic-size: 1px 5000px;
}
Why do you need this?
Website's nowadays need to be optimal and performant, users on the web have very short attention span. According to Doherty threshold response time to be 400 milliseconds.
Now imagine a website like Facebook,Instagram etc.. taking more time then the threshold ? No one would be coming back to these sites again.
When would you use this?
Most common use cases for this is when you have huge list/grid of data that needs to render at the mount of the application.
Example: Static website like specs or documentation or travel blogs etc...
Would love hear in comments if you have any other use cases for it.
How does it work ?
The browser acts smart by skipping rendering work with the class you applied with content-visibility: auto
.
Browser needs to know the layout of the DOM in order to render, those elements which are not in viewport are not rendered and infact have empty box with contain-intrinsic-size
you provided.
To summarize all of the rendering is deferred until it reaches the viewport at which the browser renders the actual layout with the width, height and styles you provided.
P.S: the layout which are not outside of the viewport would have a height: 0
, so when deferred layout comes to viewport it would stack on top of each other, so that's why contain-intrinsic-size
is needed, However, no worries these are just a fallback values, browser will render the actual ones when it renders in viewport.
Hence one drawback of this is the scrollbars would be wacky and jump to places if the contain-intrinsic-size
not given properly. :)
Browser Support
content-visibility
relies on the the CSS Containment Spec. While content-visibility
currently is supported on mostly chromium tech as at the date of writing.
However, content-visibility
support is not bad for a good to have feature on high end systems, however with progressing web development it will soon be supported in all browsers too. Hopefully :)
Alternatives
There are alternatives to improve performance using JavaScript, such using List virtualization, but who wants to write 100's of line of js
and maintain it when you could do it in 2 lines of css
Further reading; that you could do it in js:
react-window
react-virtualized
Excellent demo and explanation:
Further readings:
https://web.dev/content-visibility/#support
https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
Regards,
Oldest comments (58)
This sounds too good to be true π I'm definitely gonna try it out. Thanks for sharing!
Haha.. the world is surely a better place to live in :p
Let us know what you find out after trying.. it's always good to share knowledge :)
Let us know when you try it out.. would love to hear your findings
It depends on your usecase of where this feature is best used for...
Yes one side effects of this is the scrollbars position, but in my understanding it's not issue considering Infinite pages or huge static chunk that needs to render
Not really sure what your usecase is... however for example if you have a list of items/elements, then try adding it on item..
One of the best way to test it using chrome dev tools.
Nice! I never knew about this, I'll have to give it a try when I my hectic schedule isn't too hectic!
haha yea.. try with your on going work ;)
This is awesome
Awesome article.
Thanks π
I had trouble getting this to work for my use case, which also involves lazy loading images inside the sections where I attempted to apply this CSS trick. The negative side-effect of lazy loading images inside a section with this CSS applied was that when I rapidly scrolled down the page to a given section, the image didn't always render correctly (weirdly pixelated or obscured) until I scrolled away and then back. In the end, what seems to work best for my particular scenario is relying entirely on the JS Intersection Observer API:
developer.mozilla.org/en-US/docs/W...
Ummm, interesting...
Just a thought do we need to lazy load image's if you already rendering only what's in viewport ?.. since we aren't rendering other than what's in viewport, so for me it looks like tradeoff..
Also maybe try playing with different
contain-intrinsic-size
, might help with obscureness. ?Moreover, intersection observer is also a good option.. there's always more than one solution to do it.. whichever suit's the best.. )
Nice. Thanks!
Welcome
Great article.
Looking forward to trying this
Thanks π
This looks very promising!
It makes me wonder... if you are a 10x developer and apply this boost...
Do you become a legendary 70x developer?
Well in this case if you are 0x, and apply this boost... then no, still 0x π€ͺπ
There is no support in Firefox,ΒΉΒ² and it is only marked as "worth prototyping", with some remarks calling early versions of the spec actively harmful, especially to accessibility technology.Β³
Both points together instantly squelched my enthusiasm.
ΒΉ: developer.mozilla.org/en-US/docs/W...
Β²: developer.mozilla.org/en-US/docs/W...
Β³: github.com/mozilla/standards-posit...
As long as that does not change, this is not viable to use and other methods to speed up the site are preferable.
Yeah that's very unfortunate.. but i am optimistic.
However, what I like is it supports chrome mobile devices too, where we have most of the low end devices...
Shouldnβt that also be the case for every of the well-supported optimization techniques?
It is tempting to have a two-lines-solve-my-problems tool, but as long as there is no native FF support, itβs just not there. A polyfill wonβt do here, because it wonβt provide the performance of native, and performance is the very reason why this looks interesting.
It's really depends on your app and your users.. so if 80% of your app is used by chrome users then it's not a bad solution, considering you do not have resources to do proper optimization using JS.
Moreover, on the web we have a huge ecosystem and I think it's hard for browsers to coupe up with all these optimization...
In my view: it's a good to have feature, maybe FF or safari needs to do so many others required thing's that maybe this could not be there priority
If you donβt have the resources to do proper optimization (not with JS but by doing whatβs fast, also in CSS and by keeping your DOM sane), then thatβs a problem by itself. If 80% of your app is used by Chrome users and you enable this feature, then it wonβt be long until 100% of your users are Chrome users, because you will break performance for FF and Safari β after all, you still wonβt have the resources to do proper optimization if you donβt have it before using this β so those users will leave.
EDIT: You will break performance, because you will have to cram in features without proper optimization until you hit the 400ms limit again with the optimization. Those without the optimization will then have an unusable App.
FF devs plan to prototype this feature, but their concerns were not βsomething else is more importantβ, but βthis is actively harmfulβ, so depending on the outcome of the prototype, this might never get cross-browser support, locking you firmly into Chrome if you depend on it to get good load performance.
I kinda agree on the optimization point of view...
There's always more than one ways to do it, although might require more effort but why not.. that's how optimization comes in...
However, I highly doubt about being harmful.. it's very harsh term to use..
I will read again the Mozilla specification link to understand..
Thanks for contribution
If the outcome of the prototype in FF is βyes, implementing this version is possible without causing deep other problemsβ, your solution might allow realizing the huge speedup you saw across different browsers, so please donβt let the wording keep you from experimenting with what might come.
After all, that Mozillians decided to prototype at all means that the changes in specification since this was declared harmful might have solved enough problems.
Question re: contain-intrinsic-size: how did you come up with the values you used? Is 1px 5000px the max the screen will allow? Thx in advanceππΌ
Hii,
It's just a random value, you can put whatever value you want according to design..
In my understanding it has these effects:
Furthermore, I came up with this value when was watching the YouTube video I have attached, it's really a great explanation to understand the concept.
Thx! That covers it π
Where to put these two lines ?
For example in the * or in the body ... etc
Consider it like you have a scrollable list, and few items are visible from the list, so in order to optimize, browser needs to know not to render rest of items.
So in this case the css will be added on each item of the list to work.
Hi, how did you measure 7x? Do you have any benchmarks?
Hey.. I learned this stats from link attached in doc.. where it shows how a travel blog FCP changed from 232ms to 30ms.. which is 7x faster
web.dev/content-visibility/#example
Moreover, you can also check the benchmarks using
profiler/performance
in chrome dev tools as well..try running with and without it.. would be a cool learning :)