content-visibility: zrychlete renderování dlouhých stránek v roce 2026

Aktualizováno: 1. září 2026

Vlastnost content-visibility: auto umožňuje prohlížeči přeskočit renderování prvků mimo viewport, dokud nejsou blízko obrazovky. U dlouhých stránek to typicky zkracuje čas prvního vykreslení o 30 až 60 % a dramaticky snižuje práci hlavního vlákna. Od roku 2026 je API dostupné ve všech hlavních prohlížečích (Chrome 85+, Edge 85+, Firefox 125+ a Safari 18) a stalo se prvním sáhnutím pro optimalizaci dlouhých článků, produktových výpisů a datových tabulek. Poprvé jsem ho nasadil na blog s 4 000 slovy, kde se TBT propadl skoro o polovinu za jedno odpoledne. Pojďme se podívat, jak content-visibility funguje pod pokličkou, jak zabránit skokům layoutu pomocí contain-intrinsic-size a kdy se mu radši vyhnout.

• content-visibility: auto odloží renderování, layout a paint u prvků mimo viewport a snižuje tak Rendering time měřený v Lighthouse.
• Vždy párujte content-visibility: auto s contain-intrinsic-size, jinak riskujete zvýšení CLS a nesprávnou výšku scrollbaru.
• Od Safari 18 (září 2024) je vlastnost podporována ve všech evergreen prohlížečích, polyfill už není potřeba.
• Nepoužívejte na LCP prvek nebo obsah přímo above the fold. Přeskočení renderování zpozdí první vykreslení.
• content-visibility: hidden je alternativa k display:none, která zachovává renderovací cache. Hodí se pro tab panely a offscreen navigaci.
• V Chrome DevTools lze změřit skutečný přínos pomocí panelu Performance a metriky „Rendering" před a po.

Co je content-visibility a jak funguje

CSS vlastnost content-visibility patří do specifikace CSS Containment Module Level 2 a dává prohlížeči povolení přeskočit fáze renderovacího pipeline (style, layout, paint) pro prvky, které uživatel právě nevidí. Když nastavíte content-visibility: auto, prohlížeč každý takový prvek považuje za „možná neviditelný", a dokud se neblíží k viewportu, jeho potomci se vůbec nerenderují.

Technicky vlastnost aplikuje kombinaci contain: layout paint style a přidává tzv. skipping. Prvek zabírá místo v layoutu (aby nedošlo ke skoku), ale jeho vnitřek se nespočítá. Jakmile uživatel doscrolluje blíž (typicky 50 % výšky viewportu nad a pod), prohlížeč vypustí „renderovací brzdu" a prvek se plně vykreslí.

Rozdíl oproti loading="lazy" je zásadní. Lazy-loading obrázků odkládá pouze síťový download bitmapy, ale prvek <img> se stále počítá do layoutu a stylu. content-visibility: auto odkládá celou renderovací práci, což znamená úsporu na CPU, ne jen na síti. U dlouhé stránky s tisícem komentářů, produktů nebo řádků tabulky je rozdíl v době do interaktivity dramatický.

/* Základní použití, sekce se renderují až při přiblížení k viewportu */
.article-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.product-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 320px;
}

Kdy content-visibility skutečně zrychlí stránku

Ne každý web má z content-visibility stejný přínos. Největší zisky přináší tam, kde je hodně opakující se struktury pod foldem: dlouhé články, výpisy produktů, feed komentářů, tabulky s tisíci řádky. Google v oficiálním článku na web.dev uvádí příklad stránky s 20 sekcemi, kde se čas prvního renderu zkrátil ze 232 ms na 30 ms. To je snížení o 87 %.

V praxi se mi osvědčily tyhle scénáře:

• Blog a dokumentace s dlouhými články nad 3 000 slov. Obalte každou <section> nebo blok mezi dvěma h2 a měřte pokles Rendering time.
• E-shop výpisy s 50+ produktovými kartami na stránce. Každá karta dostane content-visibility: auto.
• Datové tabulky a admin dashboardy. Řádky mimo viewport jsou perfektní kandidáti.
• Diskuzní vlákna a komentáře. Hluboko vnořené odpovědi se často vůbec nezobrazí.

Naopak nasazovat vlastnost na obsah přímo above the fold nemá smysl, protože prohlížeč tak jako tak musí prvek vykreslit hned. A pozor na hero sekci s LCP obrázkem: kdybyste ji obalili content-visibility: auto, mohli byste zpomalit metriku Largest Contentful Paint o desítky milisekund. Detailní postup, jak měřit LCP dopad, najdete v našem průvodci jak zlepšit LCP skóre.

Proč potřebujete contain-intrinsic-size

Když prohlížeč přeskočí renderování prvku, neví, jak vysoký ten prvek bude, a nastaví mu výšku 0. To znamená, že scrollbar zobrazí špatnou pozici, browser skáče při scrollování a metrika Cumulative Layout Shift raketově roste. Řešením je contain-intrinsic-size, deklarace, která říká: „než tě vykreslím, počítej s touto výškou".

/* Statická výška, nejjednodušší, ale nepřesná pokud sekce mají různé rozměry */
.section-static {
  content-visibility: auto;
  contain-intrinsic-size: 100% 500px;
}

/* Automatická velikost, prohlížeč si pamatuje skutečnou výšku po prvním renderu */
.section-auto {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;  /* 500px jen jako první odhad */
}

Klíčové slovo auto před rozměrem (podporované od Chrome 98) je skutečně užitečný trik. Prohlížeč použije zadanou hodnotu jen při prvním setkání s prvkem, a jakmile ho jednou vykreslí, uloží si skutečné rozměry do interní cache. Při dalším scrollu už tedy zná přesnou výšku a nedochází k žádnému skoku.

Jak zvolit dobrý odhad? Změřte průměrnou výšku sekcí na produkci pomocí JavaScriptu:

// Změř medián výšky karet a doporuč hodnotu pro contain-intrinsic-size
const cards = document.querySelectorAll('.product-card');
const heights = [...cards].map(el => el.getBoundingClientRect().height).sort((a, b) => a - b);
const median = heights[Math.floor(heights.length / 2)];
console.log(`Doporučená contain-intrinsic-size: auto ${Math.round(median)}px`);

Rozdíl mezi content-visibility: auto a hidden

Specifikace nabízí tři hodnoty: visible (výchozí, nic se neděje), auto (skryj a přeskoč mimo viewport) a hidden. Právě hidden je často přehlížený nástroj. Chová se podobně jako display: none, ale zásadně jinak z pohledu renderovací cache.

Vlastnost	display: none	content-visibility: hidden	content-visibility: auto
Prvek zabírá místo v layoutu	Ne	Ne	Ano (dle contain-intrinsic-size)
Zachová renderovací cache při skrytí	Ne	Ano	Ano
Přeskočí render mimo viewport	N/A	Vždy skryté	Automaticky
Rychlost opětovného zobrazení	Pomalá (nový render)	Velmi rychlá	Rychlá
Vhodné pro	Trvale skrytý obsah	Tab panely, modaly, offscreen menu	Dlouhé feedy, výpisy

Typickým použitím content-visibility: hidden jsou tab komponenty. Když uživatel přepne mezi taby, obsah druhého tabu je stále v DOM, ale prohlížeč ho nerenderuje, a při návratu se zobrazí prakticky okamžitě, protože layout tree je zachovaný. Kdybyste použili display: none, browser musí při každém přepnutí vše přepočítat.

<div class="tab-panel" data-active="true">
  <h3>Popis produktu</h3>
  <p>Obsah viditelného tabu…</p>
</div>
<div class="tab-panel">
  <h3>Technické specifikace</h3>
  <table>…</table>
</div>

<style>
  .tab-panel:not([data-active="true"]) {
    content-visibility: hidden;  /* skryto, ale render tree zachován */
  }
</style>

Jak content-visibility ovlivňuje CLS a jak past obejít

CLS je nejčastější „past" při nasazení této vlastnosti. Když prohlížeč objeví, že skutečná výška prvku se liší od odhadu v contain-intrinsic-size, dojde k posunu následujícího obsahu. Google počítá tento posun do metriky Cumulative Layout Shift, pokud nastane během prvních 500 ms po interakci nebo dokud uživatel scrolluje.

Klíčové kroky pro CLS bez ztrát:

1. Změřte reálné rozměry na produkčních datech, ne na dev fixtures.
2. Použijte auto keyword. Cache zabrání opakovanému skoku po prvním renderu.
3. Nasaďte gradually. Nejprve na jednu sekci, sledujte CLS v CrUX (Chrome UX Report), pak škálujte.
4. Vyvarujte se dynamického obsahu s velmi variabilní výškou (video přehrávače, iframes s neznámou velikostí). U nich vlastnost nedávejte vůbec.

Pokud potřebujete jemnější kontrolu nad layoutovými skoky, přečtěte si náš detailní návod jak opravit CLS pro stabilní layout.

Podpora v Safari, Firefoxu a fallback strategie

V roce 2026 je situace s podporou příznivá: Chrome a Edge od verze 85 (2020), Firefox od verze 125 (duben 2024), Safari od verze 18 (září 2024). Podle Can I Use je global support přes 94 %. Zbývajících zhruba 6 % tvoří převážně starší iOS Safari verze na neaktualizovaných zařízeních, a pro tyto uživatele bude stránka fungovat, jen bez optimalizace.

Progresivní vylepšení funguje díky charakteru CSS. Pokud prohlížeč vlastnost nezná, prostě ji ignoruje a stránka se renderuje po staru. Není potřeba žádný JavaScript feature-detection ani polyfill:

/* Bezpečné pro všechny prohlížeče, starší jednoduše ignorují */
@supports (content-visibility: auto) {
  .comment-thread {
    content-visibility: auto;
    contain-intrinsic-size: auto 200px;
  }
}

/* Ekvivalent bez @supports, přiřazení k neznámé vlastnosti se zahodí */
.comment-thread {
  content-visibility: auto;
  contain-intrinsic-size: auto 200px;
}

Měření dopadu v Chrome DevTools a Lighthouse

Bez měření je optimalizace jen dohad (a to je hloupé). Chrome DevTools nabízí několik nástrojů, kterými lze skutečný přínos content-visibility kvantifikovat:

1. Performance panel: nahrajte stránku s vypnutým a zapnutým content-visibility. V summary se zaměřte na hodnoty „Rendering" a „Painting".
2. Lighthouse audit: metriky „Total Blocking Time" a „Speed Index" bývají u dlouhých stránek s content-visibility znatelně lepší.
3. Rendering tab → Layout Shift Regions: zvýrazní všechny prvky, které způsobují CLS. Skvělé pro odhalení špatně nastaveného contain-intrinsic-size.
4. User Timing API: obalte kritické cesty pomocí performance.mark() a měřte na reálných uživatelích přes RUM.

// Změř Time to First Render pro sekce s content-visibility
performance.mark('sections-visible-start');
document.querySelectorAll('.article-section').forEach(section => {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        performance.mark(`section-rendered-${entry.target.id}`);
        observer.unobserve(entry.target);
      }
    });
  });
  observer.observe(section);
});

Reálná studie z produkce Etsy z roku 2024 ukázala 40% snížení Total Blocking Time na produktových stránkách po nasazení content-visibility: auto na filtry a boční panely. Podobný výsledek naměřil tým eBay na výpisech kategorií.

Reálné příklady: blog, e-shop a dashboard

Dlouhý blogový článek

<article>
  <header><!-- above the fold, žádné content-visibility --></header>

  <section class="cv-section"><h2>Úvod</h2><p>…</p></section>
  <section class="cv-section"><h2>Kapitola 1</h2><p>…</p></section>
  <!-- desítky dalších sekcí -->
</article>

<style>
  .cv-section {
    content-visibility: auto;
    contain-intrinsic-size: auto 600px;
  }
</style>

E-shop kategorie s 60 kartami

.product-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
  gap: 1rem;
}

.product-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 380px;  /* výška karty včetně obrázku a CTA */
}

Dashboard s virtualizovanou tabulkou

/* Kombinace s CSS containment pro maximální izolaci */
.data-row {
  content-visibility: auto;
  contain-intrinsic-size: auto 48px;
  contain: layout style;
}

Pokud pracujete s vlastními <iframe> a third-party skripty, doplňte optimalizaci naším průvodcem jak zkrotit third-party skripty. Kombinace obou technik dá největší dopad na Interaction to Next Paint.

Časté chyby a antivzory

• Aplikace na LCP prvek: hero obrázek nebo hlavní nadpis nikdy neobalujte, přeskočení renderu zpomalí LCP.
• Vynechání contain-intrinsic-size: bez odhadu výšky prohlížeč použije 0 a scrollbar bude nesmyslný.
• Použití na malé prvky: aplikace na jednotlivé <p> nebo <li> nemá smysl, protože režie kontroly viewportu převáží úsporu renderu. Cíl: prvky nad 200 px výšky.
• Kombinace s CSS animacemi: animace uvnitř skrytého prvku se nespouštějí, dokud není viewport blízko. To může způsobit drobné vizuální glitches.
• Zapomenutí na accessibility: obsah s content-visibility: auto je stále v DOM a dostupný pro screen readery. Ale content-visibility: hidden ne, to je ekvivalent display: none pro AT.
• Ignorování Ctrl+F: v Chrome 96+ prohlížeč automaticky prohledává skrytý obsah v auto prvcích, ale u hidden je nutné použít hidden-until-found.

Časté dotazy

Co znamená content-visibility: auto v CSS?

Je to pokyn prohlížeči, aby přeskočil renderování, layout a paint prvku, dokud není blízko viewportu. U dlouhých stránek to typicky sníží počáteční Rendering time o 30 až 90 % v závislosti na počtu a složitosti offscreen sekcí.

Zlepšuje content-visibility skóre Core Web Vitals?

Ano, přímo pomáhá Total Blocking Time (TBT) a Interaction to Next Paint (INP) tím, že sníží práci hlavního vlákna při načítání stránky. Nepřímo může zlepšit i LCP, pokud jste dosud renderovali velké množství offscreen obsahu blokujícího kritický render path.

V čem je rozdíl mezi content-visibility a lazy loading?

loading="lazy" odkládá pouze síťový download obrázku, ale prvek se stále počítá do layoutu. content-visibility: auto odkládá celý renderovací proces (layout, style, paint) pro libovolný typ prvku. Nejlepší výsledky získáte kombinací obou.

Proč mi content-visibility způsobuje layout shifty?

Protože jste vynechali contain-intrinsic-size, nebo je odhad výšky výrazně nižší než reálné rozměry. Použijte contain-intrinsic-size: auto 500px (kde 500px je průměrná výška z produkce) a klíčové slovo auto zajistí, že se výška po prvním renderu uloží do cache.

Podporuje Safari content-visibility v roce 2026?

Ano. Safari 18 (září 2024) přidalo plnou podporu content-visibility: auto, hidden i contain-intrinsic-size. V kombinaci s Chrome, Edge a Firefoxem 125+ dosahuje global support přes 94 % podle Can I Use.

Kdy bych neměl content-visibility používat?

Vyhněte se použití na LCP prvcích, obsahu above the fold, malých elementech pod 200 px a prvcích s CSS animacemi závislými na scroll pozici. Pro dynamické obsahové bloky s velmi variabilní výškou (embedovaná videa, iframes bez fixní výšky) také ne, způsobí to CLS problémy.