Content-visibility: jedna CSS vlastnost všem rychlé vykreslení káže

Celý článek

Ale pozor, automatické vykreslování se přeskočí u všech elementů s touto CSS vlastností jen tehdy, nacházejí-li se mimo viewport. Pokud se tedy změní uspořádání elementů na obrazovce anebo uživatel okno posune – „zascrolluje“ – prvek se začne okamžitě vykreslovat. Nová vlastnost má za cíl urychlit počáteční načtení stránky a umožnit tak rychlejší interakci uživatele s webovkou.

Podpora? Zatím jen Chrome

Content-visibility je založena na W3C specifikaci CSS containment, konkrétně editorského návrhu druhé verze ze 17. srpna letošního roku. A přestože první verzi ve chvíli psaní tohoto článku zvládá Edge, Firefox, Chrome a Opera; globálně tedy lehce přes 77 %, s podporou druhé verze je to bohužel mnohem horší. Umí ji jen Chrome 85 v poslední, aktuální verzi. Firefox ji eviduje jako „worth-prototyping“ a ostatní zatím mlčí.

(Ne)udržitelný CSS Containment

Hlavním cílem specifikace omezení CSS jsou potenciální možnosti vylepšení výkonu webového obsahu jednoduše tím, že je možné, cituji: „předvídatelně manipulovat s izolací DOMu“. Vývojář má tak možnost prohlížeči říct, které části jsou důležitější než jiné.

Dle samotné specifikace existují čtyři typy CSS containment:

• Omezení velikosti (size containment)
• Omezení layoutu (layout containment)
• Omezení stylu (style containment)
• Omezení paintu (paint containment)

První případ contain: size ovlivňuje rychlost načtení minimálně. Navíc, pokud zapomeneme přidat prvku velikost, prohlížeč ji předpokládá jako nulovou, což nemusí být vždy kýžený efekt. Jeho hlavní benefit leží v propojení s JavaScriptovými knihovnami, které volají různé „dotazy na kontejner“, a neustálé cyklení dotazů by mohlo, třeba v případě chyby, zvětšovat element do nekonečna, či jinak ztěžovat práci se stránkou.

Druhý případ contain: layout má vliv na všechny potomky prvku, ale jednotliví potomci sebe sama už neovlivňují. Tvůrci specifikace předpokládají kombinovaní s prvním zápisem, tedy například contain: layout size.

Třetí případ úzce souvisí s counter-increment a counter-set vlastnostmi, používané např. pro číslované odrážky. Kdykoli se změní vlastnost potomků prvku s contain: style, dojde k výpočtu, která část DOMu je „znečištěná“ a které elementy je třeba přepočítávat.

Poslední contain: paint omezuje potomky elementu, nedovolí se jim zobrazit mimo své hranice. Nic nemůže viditelně přetéct prvek, pokud je mimo obrazovku. Je-li neviditelný, potomci nejsou vidět taky. A to z něj dělá z výše zmíněných nejzajímavější optimalizační techniku. Jenže…

Úplné utlačování viditelnosti obsahu

Už jenom popis jednotlivých typů vlastností CSS containment je matoucí a vyčerpávající. A co teprve trable přijít na to, kterou z nich nakonec použít, protože každý prohlížeč je optimalizuje trochu jinak?

Naštěstí po čtyřech letech od první specifikace přichází CSS vlastnost, která optimalizační techniky výrazně zjednodušuje: content-visibility. Novinka zajištuje, že vývojář získá co největší výkon, který může prohlížeč poskytnout. S minimálním úsilím.

Vlastnost akceptuje různé hodnoty, ale teprve content-visibility: auto, dělá veškerou dřinu automaticky. A paradoxně nejde o nic nového, je to pod pokličkou jenom spojený contain: paint, layout a style, a pokud se element nachází mimo viewport, tak zároveň i size.

Jak to funguje? Překvapivě dobře

Nová vlastnost se dá shrnout jednou větou: pokud je element mimo viewport, jeho potomci se nevykreslí. Prohlížeč určí velikost prvku bez ohledu na jeho obsah (pozor, to se dá obejít pomocí contain-intrinsic-size) a žádné přepočty už nedělá. Většina vykreslování, jako jsou styly a rozvržení podstromu prvku, je přeskočena.

No a postupně, jak se element v prohlížeči scrollujícího návštěvníka přibližuje k viewportu, browser si řekne, že trvat na size containment už není to pravé ořechové a začne vykreslovat a hit-testovat obsah elementu. To umožní, aby rendering proběhl těsně předtím, než se potká element a oko návštěvníka.

Novinky si zasluhují test

Přestože jsem vytvořil nejjednodušší CodePen test, který ukazuje výhody užívání nové CSS vlastnosti, upřímně rozdíly v 10 % nejsou něco, co by vytřelo zrak. Mnohem lepší je ukázka přímo v praxi.

Metodika testování

• Testuji v Google Chrome Canary, sestavení 87, ale naprosto identický test je možný ve stabilní verzi. Ve všech případech je vypnutá cache, bez doplňků a přeinstalovaný prohlížeč.
• U každé stránky přes DevTools sbírám profil s obnovením stránky. Ten se dá získat vícero způsoby, buď kliknutím na tlačítko šipky znázorňující obnovit v záložce Performance anebo stiskem klávesové zkratky Ctrl+Shift+E po otevření DevTools.
• Poté naleznu klíčový CSS soubor každé stránky, a přes Local Overrides v záložce Sources vytvořím lokální kopii do které vložím pro nejčastěji se opakující obsahový element (typicky section, nebo article) kód „content-visibility: auto“.

• Po vytvoření Local Override znovu sbírám profil s obnovením stránky. Zapnutý Override je viditelný na přiložených screenech jako trojúhelník u záložky Network.

Výsledky

Asi nikoho nepřekvapí, že čím více optimalizovaná stránka, tím menší efekt má použití content-visibility: auto. V jednom případě, u pokusu se stránkou Youtube, došlo dokonce k pomalejšímu renderu než bez této CSS vlastnosti. Nejvýznamnější rozdíl byla celá 1 sekunda u serveru Zive.cz, který je obvykle zatížen velkým množstvím reklam a jiného balastu.

Je třeba zmínit, že test proběhl na poměrně silném počítači a 1Gbit internetu, test u mobilů by dopadl o dost jinak a zcela určitě ve prospěch nové vlastnosti CSS. Už jenom proto, že viewport u mobilů je mnohem menší, a tedy dává více prostoru k off-screen optimalizacím.

Jednotlivé rozdíly mezi testovanými stránkami

Pozn.: u rozdílu v milisekundách je více lépe, ale u rozdílu v procentech jsou nejlepší hodnoty mínusové

Pro ukázku přikládáme náhledy obrazovky z měření weby Nytimes.com.

Nytimes před úpravou

Nytimes po úpravě

Verdikt

Content-visibility má obrovský smysl už teď u neoptimalizovaných anebo nad míru obrovských stránek. Největší potenciál se skrývá u mobilů a tabletů, ale zatím chybí širší podpora (Dívám se na tebe, novodobé IE, tedy chci říct Safari!). Nevýhody, což je hlavně nutnost webového vývojáře přidat řádek nového kódu, hravě překonávají výhody. Ale je určitě třeba aplikaci řádně otestovat, protože v mezních a raritních případech může nová vlastnost stránku naopak zpomalovat.