Napjainkban hatalmasra duzzadtak a weboldalak, és ez főként a mobil böngészőkre ró komoly terhet. A content-visibility CSS tulajdonsággal azonban lehetőségünk van ezt a terhet jelentősen mérsékelni.
A képeknél mindenki ismeri a lazy-loading technikát, ami annyit tesz, hogy az oldalba illesztett képeket csak akkor kezdjük el betölteni, ha azok megjelenítésére már valóban szükség van. Egyszerű és nagyszerű. Nos, a content-visibility:auto beállítás is valami ehhez hasonló, de itt nem a képek letöltését késleltetjük, hanem az egyes elemek megjelenítését.
A content-visibility tulajdonsággal meghatározhatjuk, hogy egy adott elemmel kell-e foglalkoznia a böngészőnek az oldal betöltésekor. Az alapértelmezett visible és az elemet teljesen elrejtő hidden beállítás nem különösebben érdekes, de az auto már annál inkább. Ezzel megvalósíthatjuk azt, hogy a böngésző csak akkor kezdjen el dolgozni egy adott elem megjelenítésén, amikor az már valóban szükséges, mert például a felhasználó görgetéssel a közelébe ért.
A content-visibility:auto előnyei
Főképp hosszabb és sok szakaszra osztható oldalaknál előnyös, ha egy gyenge hardveren futó böngészőnek nem kell a teljes oldalt renderelnie a látogatás első pillanatában. Ennek számtalan előnye van, a Core Web Vitals mutatóknál látványos javulást is elérhetünk a beállításával.
- A keresők elvárásai miatt az oldalak egyre terjedelmesebbek, és az ezzel együtt növekvő oldalbetöltési idő problémás lehet. A mobil eszközökön egy több tízezer pixeles magasságú lap renderelése már komoly feladat. Ezt a feladatot redukálhatjuk a töredékére néhány content-visibility:auto beállítással.
- A layout-thrashing hatása is jelentősen csökkenhet, hiszen a böngésző a távoli elemek renderelését meg sem kezdi, ha azok content-visibility:auto beállítással rendelkeznek.
- A Core Web Vitals mutatók közül az INP, az FCP és az LCP értékek is jelentősen javulhatnak. A javulás mértéke persze függ a lap méretétől, és a content-visibility:auto beállítású elemek mennyiségétől és elhelyezkedésétől.
A beállítással optimális körülmények között néhány tizedmásodpercet faraghatunk le, de akár ennyin is múlhat az, hogy a gyengéről az elfogadható szintre hozzuk fel a lapunk Core Web Vitals mutatóit.
Néhány content-visibility probléma
Ahogy minden jó dolognak, a content-visibility:auto beállításnak is van árnyoldala, ez pedig a várható méretek meglehetősen körülményes beállítása. Sajnos, ha nem tudjuk egységes méretű szekciókra osztani a lapot, akkor még az is kérdéses lehet, hogy érdemes-e egyáltalán belevágnunk.
- A böngésző a renderelésnél átugrott elemek méreteit nem ismeri, így a scrollbar hossza problémás lehet. Ha az átugrandó elemek méretet nem állítjuk be (pl. contain-intrinsic-height tulajdonsággal), akkor a scrollbar kezdetben megtévesztően rövid lesz, majd elég csúnyán ugrálni fog görgetés közben.
- A content-visibility tulajdonságot még nem minden böngésző támogatja, például a Safari aktuális verziója sem. Ez persze nem halálos probléma, hiszen a megjelenítést valójában nem befolyásolja, csak a megjelenítés sebességét optimalizáljuk a segítségével.
Bár remek lehetőségeket rejt a tulajdonság, valós környezetben néha sokkal nehezebb beállítani, mint azt elsőre gondolnánk. Őszinte leszek, a tulajdonság megjelenése óta én csak néhány lapnál implementáltam ezt. Ennyinél érte meg a méret és felépítés miatt a pixelszámolgatás, de ezeknél az FCP és az LCP értéke jellemzően 200-300 ms értékkel csökkent mobilon.
Egy gyors content-visibility teszt eredménye
Az alábbi képen egy teszt eredménye látható. Ehhez egy olyan HTML fájl generáltam, amely 50 section elemet tartalmazott, egyenként 500 karakternyi szöveggel és egy képpel. Ezt a fájlt teszteltem a Chrome DevTools Performance eszközével 20x CPU lassítás mellett. A bal oldalon látható az eredmény content-visibility beállítás nélkül, a jobb oldalon pedig content-visibility:auto beállítás mellett.
Ez csak egy szintetikus teszt volt, melynél egy végtelenül egyszerű HTML kód volt a tesztalany. Ennél jelentősebb eltérést kapunk egy valós, komplexebb HTML/CSS kóddal felépített, vagy JavaScripttel jobban terhelt oldalak esetén. Azonban már ez is elég meggyőző, hiszen egy primitív HTML lapnál is közel 70%-ot nyertünk a renderelési időn.
Egy egyszerű content-visibility példa
Az alábbi példa néhány elemre beállítja a content-visibility és a contain-intrinsic-size tulajdonságokat mobil szélesség esetén. Ezzel a mobil böngészők a hajtás alatti tartalmakat csak akkor kezdik renderelni, ha azokhoz a felhasználó már közel jár.
HTML
...
<main>
<section>
<!-- Hajtás fölötti tartalom -->
</section>
<section class="lazy-mobile-content">
<!-- Hajtás alatti tartalom #1 -->
</section>
<section class="lazy-mobile-content">
<!-- Hajtás alatti tartalom #2 -->
</section>
<section class="lazy-mobile-content">
<!-- Hajtás alatti tartalom #3 -->
</section>
</main>
...
<footer>
<!-- Lábléc tartalma -->
</footer>
...CSS
@media screen and (max-width:480px) {
footer {
content-visibility: auto;
contain-intrinsic-size:auto 400px;
}
.lazy-mobile-content {
content-visibility: auto;
contain-intrinsic-size:auto 600px;
}
}A példában én egyszerűen 600px magasságot rendeltem a lazy-mobile-content osztállyal megjelölt section elemekhez, illetve 400px magasságot a lap alján lévő footer elemhez. Egy valós weboldalon persze ezeknél komplikáltabb beállítás is szükséges lehet.
A content-visibility csak mobil szélességhez (480px alatt) van beállítva, hiszen a mobil böngészőknél profitálhatunk ezzel a legtöbbet. A mobiloknál a scrollbar hossza is kevésbé jelentős, így a pontos méretbeállítás is kevésbé kritikus fontosságú.
Összegzés
A képek esetében alkalmazott lazy-loading beállítást nem helyettesíti content-visibility:auto CSS tulajdonság, de nagyon jól kiegészíti azt. A két lehetőség együttes használata minden más technikánál hatékonyabban terelheti a problémás Core Web Vitals mutatókat a zöld sávba. Ezekkel a gyengébb eszközökön a teljes oldalbetöltési időn akár másodperceket is lefaraghatunk, ami már drasztikusan javítja a visszafordulási arányt is.
Összefoglalva, a content-visibility:auto egyértelműen egy szuper CSS tulajdonság. Nem minden esetben egyszerű használni, de néha igen jelentős hasznot hoz. Csak a kisördög miatt vetődik fel bennem egy gonosz kérdés, amelyre nem hiszem, hogy valaha is választ kapok. 2024-ben miért CSS szinten vacakolunk még az optimalizálással, ha egy böngésző automatikusan is optimalizálhatná a renderelést?
Ha elakadnál a content-visibility használatában, akkor lépj be a Facebook csoportunkba, segítünk!
További információ:
