Na&nbsp;začátku nového školního roku jsem navštívil konferenci pořádanou [Smashing magazínem ve&nbsp;Freiburgu](https://smashingconf.com/freiburg-2023/). Jeden z&nbsp;hlavních sponzorů byla firma [SpeedCurve](https://app.speedcurve.com/), jejichž nástroj hojně využíváme k&nbsp;monitoringu&nbsp;webů našich klientů v&nbsp;[PageSpeed.cz](https://www.pagespeed.cz/).

Celá konference je&nbsp;zaměřena spíše na&nbsp;tvorbu frontendu, CSS a&nbsp;na&nbsp;webdesign, než na&nbsp;performance webu, ale několik přednášek a&nbsp;vystoupení bylo velmi přínosných i&nbsp;pro&nbsp;mou prácí v&nbsp;PageSpeed.cz

<h2>WarmUp s&nbsp;metrikou INP</h2>

Hned v&nbsp;neděli po&nbsp;příjezdu jsme vyrazili na&nbsp;menší workshop, který&nbsp;vedl [Andy Davies](https://twitter.com/AndyDavies). Andy je&nbsp;Performance konzultant ve&nbsp;SpeedCurve a&nbsp;vyplatí se&nbsp;ho sledovat na&nbsp;platformě X (Twitter), kde&nbsp;přináší dobré tipy právě z&nbsp;oblasti performance (rychlosti webů).

Na&nbsp;workshopu nás Andy uvedl do&nbsp;nové [metriky INP](https://www.vzhurudolu.cz/prirucka/metrika-inp), která&nbsp;bude v&nbsp;březnu 2024 nahrazovat stávající metriku FID z&nbsp;kolekce metrik [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals). Po&nbsp;rychlém úvodu jsme se&nbsp;dozvěděli, jak INP metriku změřit, dále také jak najít nejslabší místa na&nbsp;webu a&nbsp;také pár tipů, jak INP metriku zlepšit.

Zde je&nbsp;pár základních rad a&nbsp;tipů.

* Metrika INP je&nbsp;velice úzce spjata s&nbsp;metrikou Total Blocking Time.
* Čím máte menší počet DOM elementů, tím lepší je&nbsp;Total Blocking Time.
* Pokud máte nastaveno měření [reálných uživatelů na&nbsp;webu (RUM)](https://www.pagespeed.cz/speedcurve-rum-nastaveni-mereni), můžete problémy s&nbsp;INP najít přes nástroj SpeedCurve.
* INP na&nbsp;jednotlivých stránkách webu můžete nalézt také přes Google Search Console.

Pokud nemáte možnost měřit všechny uživatele na&nbsp;webu, můžete hledat problémy s&nbsp;INP ručně.

![](/uploads/smashingconf2023-02.jpg "Andy Davies ladí metriku INP")

Postup je&nbsp;asi takový:

* Otevřete anonymní okno prohlížeče. Zapnuté pluginy by&nbsp;mohly ovlivňovat měření.
* Otevřete `DevTools`.
* Zapněte v&nbsp;záložce `Performace` nahrávání `Timeline` a&nbsp;zkuste proklikávat web, případně skrolovat a&nbsp;provádět další interakce.
* Na&nbsp;`Timeline` potom vidíte jednotlivé interakce a&nbsp;k&nbsp;nim důležité informace.
* Nás zajímají zejména `Long Tasky`, které&nbsp;po&nbsp;interakcích vznikají.
* Tyto `Long tasky` je&nbsp;následně potřeba analyzovat, rozdělit nebo odložit.


<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>Postup při&nbsp;hledání a&nbsp;ladění INP metriky se&nbsp;stále zdokonaluje. Již nyní pro&nbsp;vás připravujeme obsáhlejší článek o&nbsp;metrice INP.</p></div></div>

Jak otestovat další metriky Core Web Vitals se&nbsp;můžete dozvědět také v&nbsp;[našem článku](https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci) od&nbsp;Zuzany Šumlanské.

<h2>První den konference</h2>


První den jsme sledovali přednášky týkající design systému, přístupnosti na&nbsp;webu, ukázek nových CSS vlastností nebo novinek v&nbsp;DevTools prohlížeče Chrome.

[Jecelyn Yeen](https://twitter.com/jecfish) v&nbsp;přednášce „Modern Web Debugging“ ukázala spousty tipů z&nbsp;DevTools. Mně osobně nejvíce zaujala záložka Quick Source, která&nbsp;zobrazuje rychlý náhled na&nbsp;soubory, které&nbsp;můžete pak přímo pomocí funkce Overrides editovat na&nbsp;svém lokálním disku.

Záložku zapnete přes příkaz `Cmd+Shift+P` a&nbsp;napíšete „Quick source”.


![](/uploads/smashingconf2023-03.jpg "Quick source v&nbsp;DevTools")


Další tip, který&nbsp;mě zaujal, je&nbsp;možnost nahrávání posloupnosti příkazů na&nbsp;webu pomocí funkce `Recorder`. To&nbsp;umožňuje odeslání ve&nbsp;formátu JSON například kolegovi, který&nbsp;následně dokáže posloupnost příkazů přehrát.

Jak může takové nahrávání probíhat, ukazuje Jecelyn ve&nbsp;svém videu na&nbsp;YouTube.

<div class="video"><div class="video__holder"><iframe width="560" height="315" loading="lazy" src="https://www.youtube.com/embed/rMUayh1QPYs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div></div>

<h2>Druhý den konference</h2>


Druhý den nás čekaly techničtější přednášky. Například [Christine Vallaure](https://www.moonlearning.io/site/about) nám v&nbsp;přednášce „Design Beyond Breakpoints“ předvedla spousty novinek z&nbsp;grafického nástroje Figma. [Miriam Suzanne](https://www.miriamsuzanne.com/) nám ve&nbsp;svém vystoupení předvedla, co&nbsp;vše je&nbsp;možné v&nbsp;CSS udělat za&nbsp;pomocí Container Queries a&nbsp;které&nbsp;vlastnosti se&nbsp;teprve chystají.

V čase oběda byla možnost se&nbsp;přihlásit na&nbsp;další mini workshop s&nbsp;[Andy Daviesem](https://twitter.com/AndyDavies). Andy tentokrát v&nbsp;hodinovém vystoupení ukázal nejčastější chyby, které&nbsp;kazí Core Web Vitals. Z&nbsp;obecenstva si vybral 3 webové stránky a&nbsp;přímo na&nbsp;nich ukazoval nedostatky. Šlo vesměs o&nbsp;stále se&nbsp;opakující problémy, které&nbsp;zhoršují metriky [LCP](https://www.pagespeed.cz/blog/metrika-lcp) a&nbsp;[CLS](https://www.pagespeed.cz/blog/metrika-cls).

Čeho se&nbsp;tedy máte na&nbsp;svém webu vyvarovat?


* Nepoužívejte velké množství externích webových fontů.
* Pro&nbsp;webové fonty používejte výhradně formát `Woff2`.
* Nedávejte lazy loading na&nbsp;obrázek, který&nbsp;je&nbsp;LCP prvkem a&nbsp;je&nbsp;potřeba stáhnout co&nbsp;nejdříve.
* Využívejte priority hints. Obrázku, který&nbsp;chcete upřednostnit přidejte parametr `fetchpriority=”high”` a&nbsp;zvyšte tím jeho prioritu stažení.
* Odložte stažení a&nbsp;zpracování nepotřebných Javascriptových souborů.
* Hlídejte, aby&nbsp;všechny obrázky měli uvedeny rozměry `width` a&nbsp;`height`.

Byla to&nbsp;hezká a&nbsp;praktická ukázka toho, že&nbsp;i&nbsp;drobné úpravy dokáží rychle vylepšit metriky Core Web Vitals LCP a&nbsp;CLS.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>Tip: <a href="https://www.pagespeed.cz/blog/webexpo-2023">WebExpo 2023</a> - naše tipy na&nbsp;přednášky o&nbsp;rychlosti webu z&nbsp;největší české konference.</p></div></div>

Konference se&nbsp;konala v&nbsp;nádherném historickém městě Freiburg na&nbsp;západě Německa. Večery jsme trávili ochutnávkou místního piva a&nbsp;německé kuchyně. Vše bylo výborné a&nbsp;již nyní se&nbsp;těším na&nbsp;nějakou další společnou konferenci.

![](/uploads/smashingconf2023-04.jpg "Freiburg")



Také vám vadí, když&nbsp;reklama na&nbsp;webu odsune text, který&nbsp;zrovna čtete? Jste naštvaní když&nbsp;vám těsně před&nbsp;kliknutím odskočí obsah a&nbsp;vy kliknete nechtěně jinam?

Tyto nežádoucí situace při&nbsp;používání webu se&nbsp;nazývají posuny layoutu (layout shift). Všechny posuny na&nbsp;jedné stránce se&nbsp;počítají do&nbsp;metriky Kumulativní posun layoutu, zkráceně CLS.

Pojďme se&nbsp;na&nbsp;tuto metriku podívat hlouběji. Co&nbsp;se&nbsp;zde dozvíte?

* Co&nbsp;je&nbsp;to&nbsp;metrika CLS?
* Jaké jsou její doporučené hodnoty?
* Proč je&nbsp;důležitá?
* Jak přesně se&nbsp;počítá?
* Jak a&nbsp;kde&nbsp;ji doporučujeme měřit?
* Jaké jsou časté chyby a&nbsp;možnosti optimalizace?

## Seznamte se&nbsp;s&nbsp;metrikou CLS

Cílem při&nbsp;optimalizaci CLS je&nbsp;zajistit co&nbsp;nejvyšší vizuální stabilitu během vykreslování stránky a&nbsp;také při&nbsp;následném pohybu uživatele na&nbsp;stránce. To&nbsp;pomáhá lidem snadněji konzumovat obsah stránky.

Technicky je&nbsp;definice složitější: CLS udává součet posunů layoutu (layout shift) v&nbsp;rámci nejhoršího pětivteřinového okna během používání stránky.

Tato metrika je&nbsp;součástí [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals), používaných Googlem pro&nbsp;měření kvality webových stránek. Metriky Core Web Vitals jsou také jedním ze&nbsp;signálů zohledňovaných mimo jiné i&nbsp;při&nbsp;řazení výsledků vyhledávání.


## Limitem pro&nbsp;hodnotu metriky CLS je&nbsp;0,1

Pokud chcete mít Cumulative Layout Shift v&nbsp;zeleném vyhovujícím pásmu, hodnota metriky musí být do&nbsp;0,1. Pokud se&nbsp;vám to&nbsp;povede, máte vyhráno.

Pokud máte CLS 0,1 - 0,25, jste v&nbsp;oranžovém pásmu a&nbsp;bude potřeba vylepšení.

V případě, že&nbsp;měření u&nbsp;uživatelů odhalí hodnotu vyšší než 0,25, Google vaše CLS hodnotí jako nevyhovující.

|                      | Dobrá | Vyžaduje zlepšení | Špatná |
|----------------------| --- | --- |--------|
| <strong>CLS</strong> | < 0,1 | 0,1 - 0,25| > 0,25 |


## Důležitost dobrého CLS skóre

Metrika Cumulative Layout Shift (CLS) může být důležitá i&nbsp;pro&nbsp;váš web:



* CLS má vliv na&nbsp;SEO a&nbsp;cenu reklamy díky zařazení v&nbsp;Core Web Vitals.
* Optimalizace CLS zvýšila počet zobrazení stránek Yahoo! JAPAN News za&nbsp;jednu session o&nbsp;15 %. Více je&nbsp;v&nbsp;[případové studii na&nbsp;Web.dev](https://web.dev/yahoo-japan-news/).
* Zvýšení konverzního poměru o&nbsp;10&nbsp;% dosáhli na&nbsp;webu Mail.ru také optimalizací této metriky, viz [studie](https://web.dev/mailru-cwv/).
* CLS má také vliv na&nbsp;Lighthouse skóre. V&nbsp;nástrojích [Lighthouse](https://www.vzhurudolu.cz/prirucka/lighthouse) se&nbsp;od&nbsp;verze 10 metrika CLS do&nbsp;[celkového skóre (LPS)](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/) projevuje váhou 25&nbsp;% stejně jako třeba [metrika LCP](https://www.pagespeed.cz/blog/metrika-lcp).

Někteří naši klienti po&nbsp;optimalizaci CLS viděli kromě jiného i&nbsp;zvýšení návštěvnosti.

![](/uploads/metrika-cls-01.png "Obrázek: Na&nbsp;jednom obsahovém webu jsme po&nbsp;optimalizaci dosáhli na&nbsp;„zelené Core Web Vitals“. Po&nbsp;nasazení tzv. Page Experience update ze&nbsp;strany Googlu nastalo významné zvýšení návštěvnosti.")

## Jak se&nbsp;CLS přesně počítá?

Nejprve si řekneme co&nbsp;obnáší jeden posun layoutu.

![](/uploads/metrika-cls-02.png "Cumulative Layout Shift")

1. Jednotlivé posuny layoutu se&nbsp;počítají z&nbsp;celkové velikosti dotčené plochy (**Impact Fraction**) a&nbsp;vzdálenost posunu nestabilního prvku (**Distance Fraction**) v&nbsp;**ose X i&nbsp;Y**.

2. V&nbsp;příkladu na&nbsp;obrázku níže je&nbsp;**velikost nestabilního prvku** zhruba **90 %** viewportu.

3. Prvek se&nbsp;posunul o&nbsp;**4 %** celkové výšky viewportu. Vyjádření **vzdálenosti posunutí** je&nbsp;tedy **0,04**.

4. V&nbsp;tomto příkladu je&nbsp;tedy celková **velikost dotčené plochy 0,9** a&nbsp;**vzdálenost posunutí 0,04**.

5. **Layout shift** je&nbsp;v&nbsp;tomto případě **0,04 * 0,9 = 0,036**.

Takových prvků ale může být na&nbsp;stránce více, proto Cumulative v&nbsp;názvu metriky.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>Tip: <a href="https://www.pagespeed.cz/blog/proc-mit-rychly-web">Proč mít rychlý web</a>? Může to&nbsp;pomoci vašim konverzím i&nbsp;návštěvnosti.</p></div></div>

### „Session window“ přichází

Je&nbsp;důležité si uvědomit, že&nbsp;do&nbsp;Chrome UX Reportu se&nbsp;počítá CLS z&nbsp;celého pobytu uživatele ve&nbsp;stránce.

Aktuálně se&nbsp;ale celkové CLS skóre limituje jako maximální CLS naměřené v&nbsp;okně relace omezené na&nbsp;5 sekund se&nbsp;sekundovou mezerou. Prostě se&nbsp;bere nejhorších pět vteřin:

![](/uploads/metrika-cls-03.png "Obrázek: Počítání metriky CLS. Vezme se&nbsp;jen&nbsp;jedno, nejhorší okno. Zde Session Window 1.")

1. Nechtěné posuny (layout shifty), viz popis výše, se&nbsp;počítají vždy do&nbsp;oken relací (session window) o&nbsp;délce maximálně pět vteřin.

2. Pokud nastane vteřina bez posunů, okno se&nbsp;ukončí dříve než po&nbsp;pěti vteřinách.

3. V&nbsp;rámci celého trvání návštěvy konkrétního URL&nbsp;se&nbsp;pak vybere jen&nbsp;to&nbsp;nejhorší okno (na obrázku hned to&nbsp;první). To&nbsp;se&nbsp;uvede jako CLS skóre pro&nbsp;tuto stránku.


Výpočet v&nbsp;průběhu jednotlivých relací má zamezit zbytečně velkým hodnotám CLS u&nbsp;návštěv, kde&nbsp;je&nbsp;uživatel dlouho na&nbsp;jednom URL.

Více informací o&nbsp;měření CLS můžete najít na&nbsp;[web.dev](https://web.dev/cls/#layout-shifts-in-detail).


### Jak vlastně CLS vzniká

V praxi jsou nechtěné posuny způsobeny nejčastěji těmito obecnými příčinami:

1. **Posuny způsobené postupným načítáním prvků uvnitř obsahu.**<br>
   Jedná se&nbsp;o&nbsp;prvky, které&nbsp;nemají předem definované rozměry, jako obrázky nebo&nbsp;JS komponenty.

2. **Špatnými animacemi a&nbsp;posuny prvků pomocí CSS vlastností.**<br>
   Vyhněte se&nbsp;CSS animacím, které&nbsp;nepodporují [transformace](https://developer.mozilla.org/en-US/docs/Web/CSS/transform).

3. **Nestihnutím vyžádaného posunu do&nbsp;500 ms.**<br>
   Pokud nezvládnete obsah překreslit včas, je&nbsp;potřeba stihnout alespoň vytvořit prostor pro&nbsp;nový obsah. Týká se&nbsp;například ajaxového stránkování.

![](/uploads/metrika-cls-04.png "Obrázek: Pozor na&nbsp;asynchronně načítané prvky, jako jsou obrázky. Rády posouvají.")


## Měříme CLS

### Chrome UX Report

Ideální je&nbsp;samozřejmě sbírat data o&nbsp;CLS na&nbsp;skupině téměř všech vašich návštěvníků pomocí [Chrome UX Reportu](https://www.vzhurudolu.cz/prirucka/chrome-ux-report). Ten vám pro&nbsp;vaši doménu vrátí 75. percentil hodnot CLS u&nbsp;všech shlédnutí stránek.

Tato data obsahují měření od&nbsp;uživatelů s&nbsp;prohlížečem Chrome a&nbsp;to&nbsp;jak desktop, tak&nbsp;také mobil. Nejsou tam tedy zahrnuta měření například uživatelé Apple produktů.

Data z&nbsp;Chrome UX Reportu jsou k&nbsp;dispozici v&nbsp;nástrojích jako je&nbsp;PageSpeed Insight, náš [tester PageSpeed.cz](https://app.pagespeed.cz/login) nebo třeba Google Search Console.


### Chrome DevTools

Výbornou možností pro&nbsp;vývojáře a&nbsp;pokročilé je&nbsp;měřit CLS vašeho webu lokálně. Měříme na&nbsp;každé jednotlivé stránce zvlášť. Ideálním pomocníkem je&nbsp;Chrome a&nbsp;jeho DevTools, kde&nbsp;si zapněte [Core Web Vitals overlay](https://www.pagespeed.cz/blog/rychlejsi-web-snadno-a-rychle#8-web-vitals-overlay-nen%C3%A1padn%C3%BD-ale-skv%C4%9Bl%C3%BD-pomocn%C3%ADk) a&nbsp;hned můžete začít měřit.

Na&nbsp;začátku měřte první CLS v&nbsp;prvním viewportu a&nbsp;postupně pokračujte na&nbsp;interakce jako scrollování a&nbsp;klikání na&nbsp;prvky webu.


### PageSpeed Insights nebo Lighthouse

[PageSpeed Insights](https://pagespeed.web.dev/) nebo [Lighthouse](https://www.webpagetest.org/lighthouse) vám změří CLS na&nbsp;jednotlivých stránkách vašeho webu v&nbsp;prvním viewportu.&nbsp;Je&nbsp;to&nbsp;dobrý odrazový můstek, například pro&nbsp;vyladění základních prvků layoutu, posuny v&nbsp;menu, mobilní hlavičce, reklamní bannery okolo webu atd.

Nevýhodou je, že&nbsp;měří CLS právě jen&nbsp;na&nbsp;prvním viewportu a&nbsp;my chceme měřit kumulativně všechny posuny.

## Konkrétní doporučení, jak se&nbsp;vyhnout posunům layoutu

Z praxe našeho [poradenství k&nbsp;rychlosti webů](https://www.pagespeed.cz/sluzby) jsme vybrali několik často se&nbsp;opakujících problémů:



* **Obrázkům a&nbsp;asynchronním elementům vždy doplňte velikost**<br>
  Hlídejte, aby&nbsp;všechny obrázky na&nbsp;webu měly definovanou šířku a&nbsp;výšku pomocí atributů `width` a&nbsp;`height`. Asynchronní elementy jako&nbsp;JS komponenty nebo reklama pak pomocí CSS vlastnosti [`aspect-ratio`](https://www.vzhurudolu.cz/prirucka/css-aspect-ratio).

* **Nevkládejte cizí komponenty na&nbsp;web bez placeholderů**<br>
  Vždy před&nbsp;inicializací reklamních systémů nebo pluginů sociálních sítí (Facebook, Instagram, TikTok) nejprve připravte prostor pomocí zástupného symbolu (placeholderu) nebo opět pomocí vlastnosti `aspect-ratio`. Rozměry placeholderu zvolte tak, aby&nbsp;rezervoval podobnou plochu jako obsah vygenerovaný pluginem.

* **Využívejte BFcache**<br>
  Umožněte prohlížeči [využívat BFcache](https://web.dev/optimize-cls/#reduce-cls-by-ensuring-pages-are-eligible-for-the-bfcache) a&nbsp;snížíte CLS skóre na&nbsp;vašem webu. Prohlížeč tak&nbsp;při&nbsp;pohybu historií prohlížení nemusí znovu renderovat stránku a&nbsp;zobrazí ji z&nbsp;paměti, tudíž se&nbsp;vyhne všem posunům při&nbsp;renderu. Tato mezipaměť již funguje dlouhá léta, ale nově ji od&nbsp;roku 2023 začal podporovat prohlížeč Chrome na&nbsp;mobilech i&nbsp;desktopech.

* **Vylaďte vlastní fonty**<br>
  Náhrada systémových fontů za&nbsp;vlastní často způsobuje nechtěné posuny.

  Máme pro&nbsp;vás několik doporučení:<br>
  Čím méně jednotlivých řezů a&nbsp;variant, tím lépe.<br>
  Fonty začněte stahovat co&nbsp;nejdříve. <br>
  Pro&nbsp;prioritizaci stažení využijte [preload](https://web.dev/codelab-preload-web-fonts/).<br>
  Používejte výhradně moderní formát WOFF2.<br>
  Zajistěte pomocí vlastnosti [`font-display`](https://www.vzhurudolu.cz/prirucka/css-font-display) čitelnost textu ještě dříve, než bude externí font kompletně načten.<br>
  Pomocí [`size-adjust`](https://www.vzhurudolu.cz/prirucka/css-size-adjust) slaďte externí font a&nbsp;zástupný systémový font.

* **Na&nbsp;vyžádaný posun reagujte do&nbsp;500 ms**<br>
  Pokud po&nbsp;kliknutí pomocí JavaSriptu překreslíte část stránky a&nbsp;nový obsah bude mít jiné rozměry než obsah původní, dojde k&nbsp;posunutí prvků okolo. Tento posun je&nbsp;potřeba stihnout do&nbsp;500 ms.<br>
  Toto se&nbsp;týká např. ajaxového stránkování.
  Pokud nejste schopni nový obsah do&nbsp;této doby bezpečně doručit i&nbsp;na&nbsp;pomalejších zařízeních, je&nbsp;potřeba prvky okolo posunou ihned po&nbsp;kliknutí a&nbsp;reálný obsah do&nbsp;připraveného místa vložit později.

* **CSS umísťujte do&nbsp;`<head>`**<br>
  CSS styly držte pokud možno v&nbsp;hlavičce. Budou zpracovány hned na&nbsp;začátku načtení stránky a&nbsp;všechny naráz. Přidáním dalších CSS vlastností dovnitř HTML dokumentu může dojít k&nbsp;dalším posunům layoutu vlivem postupného zpracování těchto stylů.

* **Rezervujte místo pro&nbsp;ikonky**<br>
  Pokud používáte IconFont nebo SVG sprite s&nbsp;velkým množstvím ikon, může se&nbsp;tento soubor stahovat delší dobu. Teprve po&nbsp;načtení těchto objemných souborů se&nbsp;na&nbsp;webu objeví ikony a&nbsp;mohou začít posunovat s&nbsp;obsahem. Vždy definujte rozměry ikon ještě před&nbsp;jejich načtením.

* **Animace jen&nbsp;pomocí `transform`**<br>
  Vlastnost transformace CSS umožňuje animovat prvky, aniž by&nbsp;došlo k&nbsp;posunům rozvržení layoutu. Místo změny vlastností výšky a&nbsp;šířky použijte `transform: scale()`. Chcete-li prvky posunout, vyhněte se&nbsp;změně vlastností `top`, `right`, `bottom` nebo `left` a&nbsp;místo toho použijte `transform: translate()`.


<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>TIP na&nbsp;závěr: <a href="https://slideslive.cz/39000539/shift-happens-dealing-with-cumulative-layout-shift-case-study?ref=speaker-1202">Případová studie</a> optimalizace CLS na&nbsp;webu našeho klienta Goldea.cz od&nbsp;Martina Michálka z&nbsp;konference Webexpo 2023.</p></div></div>


### Bonus: pozor na&nbsp;scrollbary

Pokud naměříte CLS 1,00 hned po&nbsp;načtení stránky a&nbsp;už nevíte, co&nbsp;byste zoptimalizovali, zkuste `overflow-y: scroll`. Postupným zpracování HTML a&nbsp;CSS souborů totiž může docházet k&nbsp;vypínání a&nbsp;zapínání bočního scrollbaru na&nbsp;stránce.

Vložte do&nbsp;CSS stylů tento snippet, možná vám to&nbsp;ušetří spousty nervů s&nbsp;hledáním dalších CLS.

```
html {
	height: 100%;
	overflow-y: scroll;
}
```



Svět metriky Largest Contentful Paint (LCP)&nbsp;by&nbsp;se&nbsp;dal přirovnat k&nbsp;adrenalinovému prostředí automobilových závodů - jde o&nbsp;nekonečný souboj s&nbsp;časem. Pojďme teď projet všechny zatáčky a&nbsp;nástrahy naší závodní dráhy, ať jsme co&nbsp;nejlépe připravení. Co&nbsp;se&nbsp;tedy dozvíme?

* Co&nbsp;je&nbsp;metrika LCP?
* Jaké jsou její doporučené hodnoty?
* Proč je&nbsp;důležitá?
* Jak se&nbsp;metrika LCP počítá?
* Jak a&nbsp;kde&nbsp;ji doporučujeme měřit?
* Jaké jsou časté chyby a&nbsp;možnosti optimalizace?


## Seznamte se&nbsp;s&nbsp;metrikou LCP

Metrika LCP měří dobu, po&nbsp;které&nbsp;na&nbsp;stránce zobrazí největší element. To&nbsp;pomáhá uživatelům vyhodnotit užitečnost stránky.

Tato metrika je&nbsp;součástí [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals), používaných pro&nbsp;měření rychlosti načítání webových stránek. Metriky Core Web Vitals jsou také jedním ze&nbsp;signálů zohledňovaných Googlem při&nbsp;řazení výsledků výhledávání.


## Držte LCP pod&nbsp;2,5 sekundy

Pokud chcete mít Largest Contentful Paint v&nbsp;zeleném vyhovujícím pásmu, hodnota musí být do&nbsp;2,5 sekundy. LCP mezi 2,5 až 4 sekundy je&nbsp;v&nbsp;oranžovém pásmu a&nbsp;vyžaduje úpravy. Čas metriky LCP nad&nbsp;4 sekundy Google hodnotí jako nevyhovující.

|                      | Dobrá | Vyžaduje zlepšení | Špatná |
|----------------------| --- | --- |--------|
| <strong>LCP</strong> | ≤ 2,5 s&nbsp;| 2,5 - 4 s&nbsp;| > 4 s&nbsp; |



Metrika Largest Contentful Paint (LCP)&nbsp;je&nbsp;důležitá z&nbsp;několika klíčových důvodů, které&nbsp;mají zásadní vliv na&nbsp;celkový uživatelský zážitek a&nbsp;úspěšnost webových stránek.

Patří mezi ně například snížení míry okamžitého opuštění webu, vliv na&nbsp;konverze e-shopů, důvěryhodnost značky nebo pozice ve&nbsp;výsledcích vyhledávání.

![](/uploads/metrika-lcp-002.png "Metrika LCP na&nbsp;webech našich klientů často koreluje s&nbsp;konverzním poměrem. Toto děláme v&nbsp;rámci [analýzy konverzí](https://www.pagespeed.cz/speedcurve-rum-analyza-konverzi).")

## Co&nbsp;je&nbsp;to&nbsp;LCP element?

Zjednodušeně jde o&nbsp;největší vizuální prvek na&nbsp;stránce, který&nbsp;je&nbsp;zobrazen během procesu načítání stránky v&nbsp;hlavním viewportu uživatele. LCP element je&nbsp;ten prvek, který&nbsp;prohlížeč sleduje a&nbsp;měří dobu, za&nbsp;jakou nastane jeho zobrazení.

LCP element můžeme identifikovat v&nbsp;některém z&nbsp;vývojářských nástrojů - Lighthouse, Performance Tab v&nbsp;DevTools nebo Web Vitals rozšíření do&nbsp;Chrome. Do&nbsp;detailu si můžete o&nbsp;hledání a&nbsp;testování (nejen) LCP přečíst v&nbsp;mém článku [Klíčová dovednost vývojáře: testování Web Vitals v&nbsp;prohlížeči](https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci).

<br/>

Jako [LCP element](https://www.w3.org/TR/largest-contentful-paint/) se&nbsp;mohou vyhodnotit následující prvky:

* `<img>` elementy
* `<image>` element uvnitř `<svg>` elementu
* `<video>` element s&nbsp;„poster“ obrázkem
* obrázek na&nbsp;pozadí, pomocí vlastnosti `background-image` ([CSS gradient](https://developer.mozilla.org/docs/Web/CSS/CSS_Images/Using_CSS_gradients) je&nbsp;ignorován)
* [block-level](https://developer.mozilla.org/docs/Web/HTML/Block-level_elements) elementy obsahující text nebo další textové inline-level potomky

<br/>

LCP elementem naopak nemohou být následující prvky:

* Elementy s&nbsp;vlastností `opacity: 0` a&nbsp;dalšími, které&nbsp;jsou pro&nbsp;uživatele neviditelné.
* Elementy, které&nbsp;vyplňují celý viewport. Ty jsou spíše považovány za&nbsp;ilustrační než obsahové.
* Zástupné obrázky s&nbsp;nízkou mírou obsažené informace. Zde jde o&nbsp;ochranu před&nbsp;LCP hacky, kdy&nbsp;vývojáři vložili do&nbsp;stránky velký obrázek bez informace. Pokud máte pochybnosti o&nbsp;míře informací ve&nbsp;vašich obrázcích, můžete si je&nbsp;otestovat v&nbsp;[kalkulačce](https://bpp-calculator.netlify.app/) Image BPP&nbsp;(bits per pixel).


![](/uploads/metrika-lcp-003.png "Základem je&nbsp;identifikovat „LCP element“. Jen&nbsp;pozor, na&nbsp;v&nbsp;různých rozlišeních může jít o&nbsp;různý prvek.")

## Jak se&nbsp;LCP element vyhodnocuje?

Pro&nbsp;správné vyhodnocení a&nbsp;optimalizace je&nbsp;potřeba pochopit, jak se&nbsp;metrika LCP počítá. U&nbsp;LCP elementu se&nbsp;obvykle vyhodnotí jeho velikost viditelná na&nbsp;obrazovce uživatele. V&nbsp;úvahu se&nbsp;neberou ořezané části, části skryté pomocí `overflow:hidden`, ani vlastností `padding`, `margin`, `border` a&nbsp;další. Pokud chcete do&nbsp;detailů vyhodnocení LCP zabrousit více, je&nbsp;tu na&nbsp;toto téma fajn článek na&nbsp;[web.dev](https://web.dev/lcp/#how-is-an-elements-size-determined).


## Měříme LCP na&nbsp;vlastním webu

Spolehlivným zdrojem dat o&nbsp;metrikách Core Web Vitals jsou datasety [Chrome UX Reportu](https://www.vzhurudolu.cz/prirucka/chrome-ux-report) (CrUX). S&nbsp;těmito daty můžete pracovat jak pro&nbsp;celou doménu, tak&nbsp;pro&nbsp;jednotlivá URL.

Práce se&nbsp;surovými CrUX daty je&nbsp;nicméně docela náročná na&nbsp;technické schopnosti. Naštěstí již máme nástroje, které&nbsp;tato data zpracovávají a&nbsp;zobrazují v&nbsp;grafech automaticky. Jedná se&nbsp;Pagespeed.cz nebo Pagespeed Insights.


![](/uploads/metrika-lcp-004.png "Základní data o&nbsp;stavu metriky LCP vám poskytnou [PageSpeed Insights](https://pagespeed.web.dev/). Pokud chcete mít přehled o&nbsp;vývoji v&nbsp;čase, vyzkoušejte [náš tester](https://app.pagespeed.cz/).")

Pokud je&nbsp;pro&nbsp;vás omezení na&nbsp;uživatele prohlížeče Chrome příliš limitující, vždy můžete přistoupit k&nbsp;vlastnímu měření pomocí [RUM](https://developer.mozilla.org/en-US/docs/Glossary/Real_User_Monitoring)&nbsp;(real user monitoring), nebo si napsat vlastní sběr dat pomocí JavaScriptu a&nbsp;[Performance Observer API](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver).

![](/uploads/metrika-lcp-005.png "Google Search Console je&nbsp;jedním ze&nbsp;zdrojů, které&nbsp;nám dají důležité informace o&nbsp;prioritách při&nbsp;optimalizaci LCP.")

Další možností jsou syntetická měření, která&nbsp;si můžete zajistit pomocí nástrojů jako je&nbsp;SpeedCurve, Google Lighthouse, WebPageTest a&nbsp;podobně.

## Chyby a&nbsp;možnosti optimalizace LCP

Metrika LCP je&nbsp;poměrně komplexní.&nbsp;Je&nbsp;potřeba si uvědomit, že&nbsp;ji může ovlivnit spousta faktorů. V&nbsp;první řadě se&nbsp;jedná o&nbsp;zdroje kritické pro&nbsp;první vykreslení:

* Rychlost času backendu (TTFB).
* Velikost a&nbsp;složitost HTML.
* Velikost CSS a&nbsp;dalších kritických zdrojů.


![](/uploads/metrika-lcp-006.png "Optimalizace času backendu (metrika TTFB) velmi často pomůže ke&nbsp;zlepšení metriky LCP.")

Do&nbsp;LCP se&nbsp;ale počítají i&nbsp;asynchronní zdroje, tedy například obrázky nebo webfonty, které&nbsp;mohou tvořit LCP element. LCP tedy může ovlivnit i&nbsp;následující:

* Formát, fyzická a&nbsp;datová velikost samotného obrázku.
* Velikost souborů s&nbsp;fonty atd.
* Přítomnost obrázku v&nbsp;atributu poster značky `<video>`.

Obecně tedy držte všechny časy a&nbsp;velikosti na&nbsp;co&nbsp;nejnižší úrovni. Náš tajný tip? Používejte líné načtení obrázků a&nbsp;používejte jej dobře.


![](/uploads/metrika-lcp-007.png "Tady by&nbsp;lazy loading pomohl. Líně načtené obrázky (všechny kromě prvního) by&nbsp;pomohly prioritizaci prvního obrázku, který&nbsp;má vliv na&nbsp;LCP.")

LCP ale můžete zlepšit i&nbsp;komplexnějšími úpravami, které&nbsp;si popíšeme níže:


### Lazy loading může uškodit LCP

Pravidlo je&nbsp;takové, že&nbsp;se&nbsp;obrázky bez líného načtení v&nbsp;prohlížeči stahují jako první. Obrázky s&nbsp;lazy loadingem až posléze, i&nbsp;když&nbsp;jsou ve&nbsp;viditelné části viewportu. Pokud máte lazy loading na&nbsp;obrázku, který&nbsp;je&nbsp;zároveň LCP element, stáhne se&nbsp;o&nbsp;dost později, což&nbsp;zvyšuje čas LCP.&nbsp;Z&nbsp;LCP prvků na&nbsp;vašem webu proto odstraňte lazy loading a&nbsp;na&nbsp;všechny ostatní prvky lazy loading naopak přidejte:


```
<img src="image-non-lcp.webp" loading="lazy" alt="Image">
```



### Fetch Priority popostrčí stahování souboru

Složitá struktura HTML nebo příliš mnoho stahovaných souborů může způsobit, že&nbsp;náš LCP prvek se&nbsp;bude stahovat příliš pozdě. Pomocí atributu [fetchpriority](https://web.dev/fetch-priority/) ale můžeme zvýšit prioritu vybranému stahovanému souboru. To&nbsp;zlepší metriku LCP.&nbsp;S&nbsp;touto technikou je&nbsp;nicméně potřeba zacházet opatrně a&nbsp;dopad [důkladně otestovat](https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci).


```
<img src="image.webp" fetchpriority="high" alt="">
```



### Preloadujte zdroje webfontů LCP elementů

Pokud zjistíte, že&nbsp;jako LCP element se&nbsp;na&nbsp;stránce vyhodnotí textový prvek, musíte zajistit co&nbsp;nejrychlejší stažení souborů s&nbsp;webfonty a&nbsp;jejich zobrazení. Abyste tohoto cíle dosáhli, můžete využít techniky přednačtení (preload). Drobné upozornění: Preloadem je&nbsp;potřeba šetřit, proto preloadujte učitě jenom ten jediný řez fontu, který&nbsp;má vliv na&nbsp;LCP:


```
<link rel="preload" href="font-1.woff2" as="font" type="font/woff2" crossorigin>
```



## Co&nbsp;byste si měli ohledně LCP zapamatovat



* Largest Contentful Paint (LCP)&nbsp;je&nbsp;metrika měřící dobu, kdy&nbsp;se&nbsp;na&nbsp;stránce zobrazí největší vizuální prvek.
* Doporučené hodnoty pro&nbsp;LCP jsou do&nbsp;2,5 sekundy, 2,5 - 4 sekundy vyžaduje úpravy a&nbsp;nad&nbsp;4 sekundy je&nbsp;LCP nevyhovující.
* LCP je&nbsp;klíčová součást Core Web Vitals, která&nbsp;ovlivňuje uživatelský zážitek a&nbsp;velmi často také míru opuštění webu, konverze e-shopů nebo jejich pozice ve&nbsp;vyhledávačích.
* Při&nbsp;optimalizaci LCP se&nbsp;zaměřte na&nbsp;zlepšení rychlosti načítání kritických zdrojů, správné použití lazy loadingu&nbsp;nebo využití atributu `fetchpriority` pro&nbsp;zvýšení priority stahování souborů.

Ilustrace z hlavního obrázku: [Unsplash](https://unsplash.com/photos/HUJDz6CJEaM).


Nedávno jsem měl na&nbsp;plzeňském meetupu naší [komunity Frontendisti.cz](https://frontendisti.cz/) přednášku s&nbsp;desítkou tipů na&nbsp;novinky ohledně rychlosti webů, dělanou přímo na&nbsp;tělo vývojářům.

<div class="video"><div class="video__holder"><iframe width="560" height="315" loading="lazy" src="https://www.youtube.com/embed/dCONMLKgMsk" title="Frontendisti.cz" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div></div>

Pojďme si&nbsp;ty krásné, čerstvé a&nbsp;ještě teplé technologie a&nbsp;nástroje projít také v&nbsp;psané formě. Vývojářky a&nbsp;vývojáři mohou použít následující text jako rozcestník toho, co&nbsp;se&nbsp;naučit o&nbsp;prázdninách, aby&nbsp;od&nbsp;září mohli začít dělat rychlejší weby.

Nebudu to&nbsp;příliš obkecávat, takže pojďme rovnou na&nbsp;ty tipy.

## 1) WebP,&nbsp;AVIF, stále málo používaní obrázkoví spořílci
Když&nbsp;to&nbsp;trochu zjednodušíme, tradiční obrázkové formáty mají své primární určení:

- Gif slouží pro&nbsp;animace
- JPEG umí ztrátovou kompresi[]()
- PNG dokáže poloprůhlednost
- SVG je&nbsp;jediný formát, který&nbsp;zvládá vektory

Nové obrázkové formáty [WebP](https://www.vzhurudolu.cz/prirucka/webp) a&nbsp;[AVIF](https://www.vzhurudolu.cz/prirucka/avif) zvládnou ztrátovou i&nbsp;bezztrátovou kompresi, animace i&nbsp;poloprůhlednost. Obojí ale s&nbsp;výrazně menším datovým objemem.

![](/uploads/rychlejsi-web-001.png "WebP může ušetřit až násobky dat oproti JPEG a&nbsp;AVIF až násobky dat oproti WebP.")

SVG na&nbsp;vektory budete potřebovat stále, ale všechny ostatní starší formáty strčí do&nbsp;kapsy&nbsp;ty nové.

Že&nbsp;ještě WebP ani AVIF nepoužíváte? Měli byste:

- WebP má prakticky [plnou podporu](https://caniuse.com/webp) ve&nbsp;všech moderních prohlížečích.
- U&nbsp;[formátu Avif](https://caniuse.com/avif) čekáme na&nbsp;Microsoft a&nbsp;jeho prohlížeč Edge. Díky [značce ](https://www.vzhurudolu.cz/prirucka/picture)[picture](https://www.vzhurudolu.cz/prirucka/picture) ale nemusíme zase tak&nbsp;moc čekat.

Obrázky na&nbsp;webech prostě vždy servírujte ve&nbsp;WebP a&nbsp;pokud můžete, zvažte i&nbsp;Avif.
## 2)  Priority Hints, zrychlete LCP raz dva
Priority Hints jsou kořením optimalizátora metriky [LCP (Vykreslení největšího obsahu)](https://www.vzhurudolu.cz/prirucka/metrika-lcp).

[Preload](https://www.vzhurudolu.cz/prirucka/preload) se&nbsp;občas docela hodí pro&nbsp;zvýšení priority načtení konkrétního prvku, třeba fontů:

	<link rel="preload" href="font-1.woff2" as="font" type="font/woff2" crossorigin>

Nový [atribut ](https://www.vzhurudolu.cz/prirucka/priority-hints)[fetchpriority](https://www.vzhurudolu.cz/prirucka/priority-hints) umožní definovat vyšší prioritu načtení na&nbsp;HTML prvku. Ale také prioritu snížit.

Vezměme třeba dva obrázky v&nbsp;karuselu. Prvnímu prioritu zvýším, druhému snížím. Ten první se&nbsp;díky tomu načte a&nbsp;zobrazí o&nbsp;dost rychleji a&nbsp;zlepší&nbsp;mi metriku LCP:

	<img fetchpriority="high" href="image-1.webp">
	<img fetchpriority="low" href="image-2.webp">

Velmi zajímavá je&nbsp;možnost snížit prioritu stažení souboru pomocí fetche v&nbsp;JS:

	<script>
		fetch('https://example.com/', {priority: 'low'})

		.then(data => {
			// Spustíme fetch s&nbsp;vyšší prioritou
		});
	</script>

V záznamu přednášky (viz výše) zmiňuji možnost zvýšení priority fetche, ale to&nbsp;je&nbsp;blbost. V&nbsp;případě přidávání priority k&nbsp;fetchi je&nbsp;možné ji jen&nbsp;snížit. Vyšší priorita je&nbsp;její výchozí stav.

Preload je&nbsp;[podporovaný všemi prohlížeči](https://caniuse.com/?search=preload), fetchpriority zatím jen&nbsp;těmi s&nbsp;jádrem Chromium, ale chystá se&nbsp;na&nbsp;to&nbsp;i&nbsp;Safari.

Chybějící podpora ve&nbsp;Firefoxu (a zatím také v&nbsp;Safari) nemusí příliš vadit. Dívejme se&nbsp;na&nbsp;to&nbsp;z&nbsp;pohledu postupného vylepšování (progressive enhancement) – někteří uživatelé získají výhodu rychlejšího načtení, ale chybějící podpora u&nbsp;jiných nic nerozbíjí.

Jen&nbsp;pozor, s&nbsp;kořením je&nbsp;potřeba šetřit. Změnu prioritizace využívejte, jen&nbsp;když&nbsp;opravdu víte, co&nbsp;děláte a&nbsp;umíte si změřit dopady přímo v&nbsp;prohlížeči.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em><a href="https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci" target="_blank" rel="noreferrer noopener">Měření rychlosti přímo v&nbsp;prohlížeči</a> je&nbsp;klíčová dovednost vývojáře.</em>
</p></div></div>

## 3) aspect-ratio, všechno asynchronní musí mít poměr stran

Tento obrázek je&nbsp;pěkný, ale smutný:

	<img src="image.webp" alt="Image">

Víte proč? Prohlížeč po&nbsp;jeho vykreslení pravděpodobně bude muset překreslit i&nbsp;obsah pod&nbsp;ním. Takhle je&nbsp;to&nbsp;lepší:

	<img src="image.webp" width="500" height="500" alt="Image">

Obrázkům vždy [definujte atributy width a&nbsp;height](https://www.vzhurudolu.cz/prirucka/img-pomer-stran). Slouží k&nbsp;nastavení rezervovaného prostoru. Díky tomu se&nbsp;nestane layout shift a&nbsp;nezhorší metriku [CLS (Kumulativní posun layoutu)](https://www.vzhurudolu.cz/prirucka/metrika-cls).

Nemáte obrázek, ale třeba javascriptovou komponentu? Dejte tam [aspect-ratio](https://www.vzhurudolu.cz/prirucka/css-aspect-ratio):

	p {
		aspect-ratio: 4/3;
	}

CSS vlastnost aspect-ratio nastavuje poměr stran u&nbsp;prvků, které&nbsp;nejsou obrázky. Odstraňuje nutnost [použití „padding triku“](https://www.vzhurudolu.cz/prirucka/padding-trik).

Podpora je&nbsp;plná ve&nbsp;všech moderních prohlížečích, viz [width/height](https://caniuse.com/mdn-html_elements_img_aspect_ratio_computed_from_attributes) a&nbsp;[aspect-ratio](https://caniuse.com/mdn-css_properties_aspect-ratio). Tohle používejte u&nbsp;všech asynchronních prvků, včetně reklamy.
## 4) size-adjust, zamezte poskakování layoutu způsobeném fonty

Problém můžete vidět na&nbsp;následujícím obrázku z&nbsp;optimalizace u&nbsp;našeho klienta, Sazka.cz:

![](/uploads/rychlejsi-web-002.png "Nejprve se&nbsp;to&nbsp;vykreslí systémovým fontem, pak webfontem. A&nbsp;přitom to&nbsp;celé poskočí.")

Častý problém v&nbsp;oblasti posunu layoutu, který&nbsp;měří metrika CLS, je&nbsp;jiná velikost systémového písma a&nbsp;vlastního fontu.

Řeší to&nbsp;[deskriptor size-adjust](https://www.vzhurudolu.cz/prirucka/css-size-adjust):

	@font-face {
		font-family: "Montserrat-fallback";
		size-adjust: 113.56999999999995%;
		src: local("Arial Bold"), local("Arial");
	}

Tento zápis upraví velikost systémového písma k&nbsp;vlastnímu fontu a&nbsp;minimalizuje posuny layoutu a&nbsp;tudíž zhoršení CLS kvůli vlastním fontům.

[Podporují](https://caniuse.com/mdn-css_at-rules_font-face_size-adjust) to&nbsp;všechny prohlížeče s&nbsp;výjimkou Safari. Ale opět to&nbsp;nevadí.
## 5) BFcache, aneb jak se&nbsp;Chrome konečně probudil

[BFcache](https://web.dev/bfcache/) je&nbsp;zkratka pro&nbsp;„back & forward cache“. Jde o&nbsp;mezipaměť v&nbsp;prohlížeči, která&nbsp;ukládá stránky procházené v&nbsp;historii prohlížeče. Není na&nbsp;tom nic nového, ale možná vás překvapí, že&nbsp;Chrome se&nbsp;tuhle vlastnost pořádně naučil až nyní.

Zrychlení webu s&nbsp;back/forward cache je&nbsp;viditelné na&nbsp;první pohled:

<div class="video"><div class="video__holder"><iframe width="560" height="315" loading="lazy" src="https://www.youtube.com/embed/cuPsdRckkF0" title="bfcache on Chrome for Android" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div></div>

Správně nasadit BFcache (a nerozbít si přitom například měření nebo jiné věci) je&nbsp;docela složité. Raději si o&nbsp;tom přečtěte více, například na&nbsp;odkaze výše.

Podstatné je, že&nbsp;jako vývojáři byste, kromě jiného, neměli používat následující vlastnosti:

- Události unload, beforeunload.
- Hlavičky Cache-Control: no-store.
- Reference na&nbsp;window.opener.

Testování podpory BFcache u&nbsp;vašich webů je&nbsp;možné v&nbsp;DevTools Chrome. Buď v&nbsp;záložce Application nebo přes Lighthouse.

Podpora BFcache je, poté co&nbsp;se&nbsp;rozhoupal Chrome, plná. Existují [případové studie](https://www.smashingmagazine.com/2022/05/performance-game-changer-back-forward-cache/), které&nbsp;říkají, že&nbsp;to&nbsp;může opravdu hodně pomoci. My jsme zatím u&nbsp;klientů skokové zlepšení rychlosti nezaznamenali, spíše BFcache bereme jen&nbsp;jako jeden z&nbsp;potenciálně snadných kroků pro&nbsp;mírný posun k&nbsp;lepší rychlosti.&nbsp;Je&nbsp;to&nbsp;podobné jako u&nbsp;nasazení [komprese Brotli](https://www.pagespeed.cz/blog/komprese-na-webu).
## 6) Prerender, nová verze předběžného vykreslení stránek
Pomocí [instrukcí k&nbsp;„prerender“](https://developer.chrome.com/blog/prerender-pages/) je&nbsp;možné během pobytu uživatele na&nbsp;jedné stránce říct, že&nbsp;chcete stáhnout a&nbsp;připravit k&nbsp;vykreslení jinou stránku.

Hodí se&nbsp;to&nbsp;hlavně u&nbsp;přímočarých navigací jako je&nbsp;procházení nákupním procesem.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>Hledali jsme <a href="https://www.pagespeed.cz/blog/reshoper-2023" target="_blank" rel="noreferrer noopener">nejrychlejší český e-shop</a> Jak dopadl ten váš?</em>
</p></div></div>

Také předrenderování může mít velký vliv na&nbsp;uživatelský prožitek. Kdysi byl&nbsp;kolem předrenderování stránek ve&nbsp;vývojářské komunitě docela „hajp“:

	<link rel="prerender" href="/next-page/">

Tento starý způsob předrenderování bude ale z&nbsp;Chrome odstraněn. Nevyhovuje hlavně z&nbsp;důvodu přílišné jednoduchosti.

Nově se&nbsp;instrukce k&nbsp;předvykreslení od&nbsp;Chrome 108 definuje takto:

	<script type="speculationrules">
	{
		"prerender": [
			{
				"source": "list",
				"urls": ["next.html", "next2.html"]
			}
		]
	}
	</script>

Všimněte si zápisu *speculationrules*. Ano, jde opravdu doslova o&nbsp;„spekulativní pravidla“. Vyjadřujeme jimi pravděpodobnost, že&nbsp;uživatel může pokračovat na&nbsp;některé konkrétní stránky. V&nbsp;další verzi implementace v&nbsp;Chrome by&nbsp;nemělo chybět i&nbsp;číselné vyjádření této pravděpodobnosti.

S [podporou](https://caniuse.com/mdn-api_document_prerendering)&nbsp;můžete zatím opět počítat jen&nbsp;v&nbsp;prohlížečích založených na&nbsp;jádře Chromium. A&nbsp;co&nbsp;my? U&nbsp;klientů zatím vyčkáváme, jak se&nbsp;to&nbsp;vyvrbí.
## 7) INP,&nbsp;úplně nová metrika interaktivity

Na&nbsp;přednášce jsem říkal, že&nbsp;[metrika INP (Interaction to&nbsp;Next Paint)](https://www.vzhurudolu.cz/prirucka/metrika-inp) nahradí metriku [FID](https://www.vzhurudolu.cz/prirucka/metrika-fid) nejspíš v&nbsp;roce 2024. Nyní už termín změny v&nbsp;Core Web Vitals známe, jde o&nbsp;březen 2024.

Nová metrika se&nbsp;opět zabývá rychlosti reakce rozhraní na&nbsp;klikání (nebo jiné vstupy) uživatele. Jejími nepřáteli jsou tedy pomalu vykonávané „ajaxové“ dotazy nebo dlouhé úlohy v&nbsp;JS, které&nbsp;zaseknou vykreslovací jádro.

[Spočítal jsem](https://twitter.com/machal/status/1658367878096142338), že&nbsp;ze&nbsp;100 nejvíce navštěvovaných českých e-shopů tuto metriku splňuje jen&nbsp;17 %.

![](/uploads/rychlejsi-web-003.png "Velké české e-shopy zatím metriku INP (a pomalé odpovědi na&nbsp;interakce uživatelů) neřeší.")

FID celosvětově splňuje 95&nbsp;% webů ⨉ INP jen&nbsp;66 %. Obávám se, že&nbsp;to&nbsp;bude vývojářskou komunitu v&nbsp;dalším roce trošku bolet, hlavně pak weby postavené na&nbsp;[javascriptových frameworcích](https://www.linkedin.com/feed/update/urn:li:activity:7064132126434062336?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A%28V2%2Curn%3Ali%3Aactivity%3A7064132126434062336%29).

Jaké jsou hlavní rozdíly mezi metrikami INP a&nbsp;FID?

- FID = první interakce &times; INP = celý pobyt ve&nbsp;stránce. Nestačí vám tedy rychle reagovat jen&nbsp;na&nbsp;první klik. Počítá se&nbsp;ten nejhorší ze&nbsp;všech.
- FID = první část reakce &times; INP = celá reakce. FID měří jen&nbsp;čas než se&nbsp;klik začne zpracovávat JavaScriptem. INP vyloženě čeká na&nbsp;až překreslení stránky do&nbsp;nového stavu.

Optimalizace metriky INP na&nbsp;vašem webu může nějakou dobu zabrat, proto doporučujeme se&nbsp;tomuto tématu začít věnovat brzy. INP zobrazujeme nově také v&nbsp;našem [testeru rychlosti](https://app.pagespeed.cz/), včetně jejího [monitoringu](https://www.pagespeed.cz/blog/monitoring-rychlosti-webu-s-pagespeed). Umíme vám samozřejmě pomoci i&nbsp;s&nbsp;[optimalizací této metriky](https://www.pagespeed.cz/sluzby).

V dalších tipech se&nbsp;od&nbsp;technologií a&nbsp;metrik přesuneme k&nbsp;nástrojům.
## 8) Web Vitals overlay, nenápadný, ale skvělý pomocník

Abyste jako vývojáři dokázali ladit správné problémy, musíte umět správně [měřit metriky](https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci).

Lišta Web Vitals overlay je&nbsp;pro&nbsp;lokální testování výrazně lepší než Lighthouse. Ukazuje správné metriky a&nbsp;jsou i&nbsp;správně vypočítané.

Je&nbsp;potřeba si uvědomit, že&nbsp;Lighthouse bez speciálního nastavení měří synteticky a&nbsp;tedy nedokáže správně změřit metriky získávané od&nbsp;uživatele za&nbsp;celou dobu jeho pobytu ve&nbsp;stránce.

Jak se&nbsp;k&nbsp;Web Vitals overlay dostat?

- Otevřete Chrome Dev Tools (F12).
- Cmd + Shift + P na&nbsp;Macu, případně Ctrl + Shift + P na&nbsp;Windows.
- Začněte psát „Web Vitals Overlay“.

![](/uploads/rychlejsi-web-004.png "Web Vitals overlay. Čísla od&nbsp;uživatele vypadají jinak než&nbsp;ty z&nbsp;Lighthouse.")

U metriky jako CLS nebo nově INP se&nbsp;tak&nbsp;nedostanete ke&nbsp;stejným číslům, které&nbsp;pak vidíte v&nbsp;datech od&nbsp;Google.

Rozumnou alternativou k&nbsp;Web Vitals overlay je&nbsp;[Web Vitals extension](https://web.dev/debug-cwvs-with-web-vitals-extension/).
## 9) Perf. Insights, nový nástroj ladění rychlosti
[Performance Insights](https://www.pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci) je&nbsp;něco jako záložka Performance, Ale pro&nbsp;lidi.

![](/uploads/rychlejsi-web-005.png "Performance Insights. Když&nbsp;chcete znát detaily a&nbsp;nechcete se&nbsp;v&nbsp;nich ztratit.")

V Insights Chrome ukazuje konkrétní informace pro&nbsp;ladění konkrétní metriky, viz například u&nbsp;CLS:

- Konkrétní nechtěné posuny u&nbsp;CLS (1).
- Skóre CLS (2).
- Potenciální příčiny problému (3).

Pokud potřebujete detaily k&nbsp;ladění rychlosti a&nbsp;záložka Performance je&nbsp;pro&nbsp;vás příliš složitá, zvažte Performance Insights.
## 10) Trace.Cafe, sdílejte výstupy z&nbsp;detailního měření rychlosti
Jeden velmi stručný tip na&nbsp;závěr. [Trace.cafe](https://trace.cafe/) vám umožní nasdílet výstup z&nbsp;Trace (záložka Performance) na&nbsp;konkrétním URL.

Stáhněte si data v&nbsp;JSON, přetáhněte do&nbsp;Trace.cafe a&nbsp;nasdílejte vzniklé URL&nbsp;kolegům. Paul Irish, autor této skvělé appky, říká, že&nbsp;vaše trace na&nbsp;daném URL&nbsp;vydrží tři měsíce:

![](/uploads/rychlejsi-web-006.png "Stáhněte si JSON z&nbsp;nástroje Performance nebo Performance Insights a&nbsp;nasdílejte jej kolegům.")

A jsme na&nbsp;konci tohoto stručného průvodce novinkami kolem rychlosti pro&nbsp;vývojáře.

Chtěli byste dostávat další tipy? Každý měsíc [vydáváme newsletter](https://www.pagespeed.cz/newsletter), publikujeme ale také na&nbsp;[LinkedIn](https://www.linkedin.com/company/42805034/), [Twitteru](https://twitter.com/pagespeedcz) nebo [Facebooku](https://www.facebook.com/PageSpeed.cz).




Letošní [WebExpo](https://webexpo.net/) je&nbsp;za&nbsp;námi. Bylo to&nbsp;krásné. Bylo to&nbsp;intenzivní.

Patřím mezi velké fanoušky multioborových přesahů téhle webařské konference. Ale když&nbsp;se&nbsp;v&nbsp;programu objeví něco kolem rychlosti, pak jasně, že&nbsp;sedím v&nbsp;první řadě.

WebExpo už vypouští [záznamy](https://slideslive.com/webexpo/webexpo-2023), takže se&nbsp;můžete podívat na&nbsp;několik přednášek, které&nbsp;se&nbsp;dotýkaly rychlosti a&nbsp;vylepšit tak&nbsp;své dovednosti při&nbsp;optimalizacích.

## Harry Roberts: Optimising Largest Contentful Paint

Když&nbsp;přijede Harry, jdeme na&nbsp;Harryho. To&nbsp;je&nbsp;zákon. Dřívější expert na&nbsp;CSS aka [CSS Wizardry](https://csswizardry.com/) se&nbsp;nyní plně ponořil do&nbsp;performance. Své přednášky vždy koncipuje jako detailní a&nbsp;hloubkový průzkum konkrétního tématu.

<div class="video"><div class="video__holder video__holder--810-306"><iframe src="https://slideslive.com/embed/presentation/39000635" width="810" height="266" allow="autoplay; fullscreen" sandbox="allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts" frameborder="0" scrolling="no"></iframe></div></div>

Pokud o&nbsp;[metrice LCP](https://www.vzhurudolu.cz/prirucka/metrika-lcp) nic nevíte, tohle si pusťte. A&nbsp;vězte, že&nbsp;o&nbsp;metrice vykreslení největšího obsahu pravděpodobně zase tak&nbsp;moc nevíte, i&nbsp;když&nbsp;si to&nbsp;třeba myslíte. LCP totiž ze&nbsp;všech Web Vitals splňuje doporučené limity na&nbsp;nejmenším počtu webů. I&nbsp;já jsem se&nbsp;v&nbsp;Harryho přednášce naučil leccos nového, třeba význam atributu decoding na&nbsp;obrázcích, které&nbsp;jsou LCP prvky.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>
Doporučujeme: <a href="https://www.pagespeed.cz/blog/chyby-ktere-kazi-web-vitals" target="_blank" rel="noreferrer noopener">Zuzana Šumlanská - Nejčastější chyby, které&nbsp;kazí Web Vitals</a>.</em>
</p></div></div>

## Scott Jehl: Experimenting with performance at the edge

První část téhle přednášky osloví ty, kteří stále nejsou přesvědčení, že&nbsp;rychlost webu má cenu řešit. Čekejte spoustu užitečných čísel, grafů, argumentů, které&nbsp;už třeba konečně přesvědčí vašeho šéfa nebo klienta, že&nbsp;[rychlost je&nbsp;důležitá](https://www.pagespeed.cz/blog/proc-mit-rychly-web).

<div class="video"><div class="video__holder video__holder--810-316"><iframe src="https://slideslive.com/embed/presentation/39000633" width="810" height="277" allow="autoplay; fullscreen" sandbox="allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts allow-top-navigation" frameborder="0" scrolling="no"></iframe></div></div>

Po&nbsp;dlouhém úvodu Scott ukázal [Experiments ve&nbsp;WebpageTestu](https://product.webpagetest.org/experiments), které&nbsp;vám umožní otestovat vliv změny kódu na&nbsp;rychlost přímo na&nbsp;produkčním webu. To&nbsp;je&nbsp;velmi zajímavé a&nbsp;určitě si to&nbsp;zkuste.

## Martin Michálek: Shift happens: Dealing with Cumulative Layout Shift (Case Study)

Musím vás pozvat také na&nbsp;sledování záznamu své přednášky, což&nbsp;je&nbsp;pro&nbsp;mě vždycky trochu ošemetné. Ve&nbsp;dvaceti minutách jsem se&nbsp;pokusil ukázat detailní znalosti potřebné pro&nbsp;optimalizaci nové a&nbsp;méně probádané [metriky CLS](https://www.vzhurudolu.cz/prirucka/metrika-cls).

Ukazoval jsem to&nbsp;na&nbsp;případové studii práce pro&nbsp;našeho milého klienta – [Goldea.cz](https://www.goldea.cz/). Některé optimalizace už zvládáme docela snadno, ale zde jsme se&nbsp;zapotili a&nbsp;sami se&nbsp;o&nbsp;Cumulative Layout Shiftu dozvěděli leccos nového a&nbsp;překvapivého.

<div class="video"><div class="video__holder video__holder--810-306"><iframe src="https://slideslive.com/embed/presentation/39000539" width="810" height="266" allow="autoplay; fullscreen" sandbox="allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts allow-top-navigation" frameborder="0" scrolling="no"></iframe></div></div>

Víte, jakými [nástroji](https://pagespeed.cz/blog/testovani-web-vitals-v-prohlizeci) CLS měřit a&nbsp;proč to&nbsp;nedělat pomocí Lighthouse? Víte, co&nbsp;s&nbsp;CLS udělá udělá flexbox v&nbsp;navigaci a&nbsp;co&nbsp;posuvník na&nbsp;Windows? Zodpoví vám to&nbsp;moje přednáška.

Velmi příjemně mě překvapily ještě další dvě přednášky, které&nbsp;se&nbsp;tématu rychlosti webů dotýkaly:

-   [Ondřej Čermák: How to&nbsp;make sure your system doesn’t blow (up)](https://slideslive.com/39000540/how-to-make-sure-your-system-doesn-t-blow-up?ref=folder-117551) - škálování pro&nbsp;performance nemusí vždy pomoci. Základ je&nbsp;dobře měřit. Přesně tak! A&nbsp;ještě jedna věc – dávejte si pozor na&nbsp;fronty.

-   [Server-Side: The newest website tracking concept: Pavel Šabatka](https://slideslive.com/39000648/serverside-the-newest-website-tracking-concept?ref=folder-117551) - pěkně podané argumenty proč zvážit serverové GTM, jak to&nbsp;zhruba udělat a&nbsp;co&nbsp;to&nbsp;stojí.&nbsp;Je&nbsp;to&nbsp;jednodušší než jsem si myslel a&nbsp;s&nbsp;rychlostí to&nbsp;může docela slušně pomoci.

Bylo to&nbsp;bezva. Tak&nbsp;ahoj na&nbsp;WebExpu 2024!

Ale ještě dříve se&nbsp;uvidíme na&nbsp;[Reshoperu 2023](https://www.reshoper.cz/cs/veletrh/pagespeed-cz), už 17.&nbsp;května 2023.


Core Web Vitals jsou metriky, které&nbsp;používáme k&nbsp;hodnocení výkonu webových stránek v&nbsp;oblastech jako jsou rychlost načítání, interaktivita a&nbsp;stabilita layoutu. Tyto metriky jsou [stále více důležité](https://www.pagespeed.cz/blog/proc-mit-rychly-web) pro&nbsp;zajištění dobré uživatelské zkušenosti a&nbsp;Google je&nbsp;používá jako jedno z&nbsp;hledisek pro&nbsp;umístění ve&nbsp;výsledcích vyhledávání.

V naší praxi se&nbsp;ale stále setkáváme, že&nbsp;vývojářům a&nbsp;vývojářkám chybí znalosti, jak si Core Web Vitals spolehlivě otestovat v&nbsp;prohlížeči. Při&nbsp;ladění totiž nestačí jenom udělat změnu, o&nbsp;které&nbsp;si myslíme, že&nbsp;metriky zlepší. Své úpravy je&nbsp;nutné také umět otestovat z&nbsp;hlediska vlivu na&nbsp;ně.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>
Může vás zajímat také <br><a href="https://www.pagespeed.cz/blog/novinky-2022" target="_blank" rel="noreferrer noopener">12 technických novinek ohledně rychlosti webu</a>.</em>
</p></div></div>

Určitě nedoporučujeme dělat optimalizace „naslepo“, metodou pokus-omyl a&nbsp;nejlépe ani testovat v&nbsp;Lighthouse. V&nbsp;článku se&nbsp;proto pokusíme přiblížit nejefektivnější cestu, jak si Core Web Vitals otestovat.

## Co&nbsp;jsou Core Web Vitals?

Opakování je&nbsp;matka moudrosti. Základní Core Web Vitals metriky jsou tři, [First Input Delay (FID)](https://www.vzhurudolu.cz/prirucka/metrika-fid), [Largest Contentful Paint (LCP)](https://www.vzhurudolu.cz/prirucka/metrika-lcp) a&nbsp;[Cumulative Layout Shift (CLS)](https://www.vzhurudolu.cz/prirucka/metrika-cls). Všechny metriky mají doporučené hodnoty, které&nbsp;vidíte na&nbsp;obrázku.

![Core Web Vitals](/uploads/testing-01.png "Core Web Vitals")

First Input Delay se&nbsp;zaměřuje na&nbsp;odezvu webu po&nbsp;první interakci uživatele, Largest Contentful Paint na&nbsp;rychlost načtení největšího prvku na&nbsp;stránce a&nbsp;Cumulative Layout Shift zase na&nbsp;stabilitu layoutu.

## Proč nepoužívat Lighthouse

Lighthouse může při&nbsp;ladění rychlosti pomoci, ale máme k&nbsp;němu všeobecně mnoho výhrad, proto jej nedoporučujeme ani při&nbsp;testování vašich metrik po&nbsp;vývojářských úpravách.

Neměří totiž uživatelské metriky, ale synteticky, tedy jako stroj. S&nbsp;tím se&nbsp;pojí další problém – jím uvedené metriky platí jenom pro&nbsp;první načtení a&nbsp;to, co&nbsp;se&nbsp;uživateli odehrává v&nbsp;prvním viewportu (CLS tak&nbsp;změří špatně, FID nebo INP vůbec).

Ideální není ani pro&nbsp;měření LCP,&nbsp;kdy&nbsp;zvládá otestovat jenom jeden kontext (stav), např. web s&nbsp;cookie lištou. Do&nbsp;výhod a&nbsp;nevýhod nástroje Lighthouse a&nbsp;jeho metriky LPS&nbsp;se&nbsp;hlouběji noří Martin Michálek v&nbsp;jeho článku [Lighthouse Performance Score (LPS): krásy i&nbsp;pasti metriky všech metrik](https://www.vzhurudolu.cz/prirucka/metrika-lps).

![Lighthouse](/uploads/testing-02.png "Lighthouse")

## Jak otestovat Core Web Vitals v&nbsp;prohlížeči

Základním nástrojem pro&nbsp;naše testování budou Dev Tools v&nbsp;prohlížeči Google Chrome. Ty totiž obsahují další, často dobře skryté vychytávky, které&nbsp;nám značně ulehčí práci.

Konkrétně se&nbsp;dneska budeme bavit o&nbsp;Core Web Vitals Overlay a&nbsp;panelech Performance a&nbsp;Performance Insights.

### Core Web Vitals Overlay

Nejjednodušším způsobem, jak otestovat metriky Core Web Vitals, je&nbsp;otevřít si v&nbsp;Dev Tools „nativní“ Core Web Vitals Overlay. Ten ukazuje metriky pro&nbsp;jakoukoliv stránku, kterou zrovna navštívíte.

![Core Web Vitals Overlay](/uploads/testing-03.png "Core Web Vitals Overlay")

Overlay pro&nbsp;Core Web Vitals se&nbsp;na&nbsp;desktopu zobrazí v&nbsp;pravém horním rohu. Pro&nbsp;zobrazení použijte klávesovou zkratku Cmd + Shift + P na&nbsp;Macu, případně Ctrl + Shift + P na&nbsp;Windows, která&nbsp;vyvolá vyhledávací panel s&nbsp;nástroji Dev Tools. Do&nbsp;něj pak jednoduše začněte psát „Web Vitals Overlay“ a&nbsp;Chrome vám brzy našeptá výsledek.

![Core Web Vitals Overlay](/uploads/testing-04.png "Core Web Vitals Overlay")

Core Web Vitals Overlay používáme pro&nbsp;testování všech tří metrik. Výhodou je, že&nbsp;si můžete zpomalit síť v&nbsp;panelu Network a&nbsp;změřit si metriky v&nbsp;simulovaných podmínkách.

Naopak nevýhodou je&nbsp;nedostatek dat, Overlay vám neřekne žádné podrobnosti například k&nbsp;LCP elementu, nebo elementům způsobující CLS. Pro&nbsp;tato data se&nbsp;musíme podívat do&nbsp;sofistikovanějších nástrojů.

### Panel Performance

Tomuto nástroji přezdíváme&nbsp;mu „žížalky“, podle způsobu zobrazování vykonávaného JavaScriptu. Nicméně obsahuje spoustu dalších a&nbsp;užitečných záložek. Pro&nbsp;naše potřeby je&nbsp;nejdůležitější sekce „Web Vitals“ (na obrázku níže jde o&nbsp;číslo 1), „Timings“ (2) a&nbsp;„Experience“ (3).

![Panel Performance](/uploads/testing-05.png "Panel Performance")

Web Vitals je&nbsp;první sekce v&nbsp;panelu Performance, která&nbsp;nám sděluje časové údaje metrik.

![Panel Performance](/uploads/testing-06.png "Panel Performance")

Sekce Timings&nbsp;je&nbsp;dost podobná, nicméně v&nbsp;případě metriky LCP obsahuje i&nbsp;cenné informace, například o&nbsp;konkrétním elementu, velikosti a&nbsp;typu.

![Panel Performance](/uploads/testing-07.png "Panel Performance")

Naopak sekci Experience nejčastěji využijete při&nbsp;testování metriky CLS, protože zobrazuje podrobný rozbor naměřeného posunu layoutu na&nbsp;stránce. Stačí se&nbsp;prokliknout do&nbsp;červeného čtverečku označujícího problém a&nbsp;zobrazí se&nbsp;vám informace jako níže na&nbsp;obrázku.

![Panel Performance](/uploads/testing-08.png "Panel Performance")

### Panel Performance Insights

Posledním nástrojem v&nbsp;našem seznamu jsou Performance Insights, které&nbsp;se&nbsp;dají charakterizovat jako zjednodušený panel Performance. Najdeme zde přehlednější a&nbsp;stručnější rozbory webu.

Co&nbsp;se&nbsp;týká ladění metrik je&nbsp;zde daleko více informací. V&nbsp;případě problémů s&nbsp;CLS nabízí nejen konkrétní nechtěné posuny (1), ale také jejich skóre (2) nebo často i&nbsp;potenciální příčiny problému (3).

![Panel Performance Insights](/uploads/testing-09.png "Panel Performance Insights")

Také se&nbsp;nemusíte v&nbsp;Performance Insights trápit, že&nbsp;nerozumíte tolik samotnému fungování prohlížeče. Zobrazené informace a&nbsp;navržené UI pomáhá v&nbsp;orientaci i&nbsp;méně zkušeným vývojářům.

Pro&nbsp;hlubší pochopení doporučujeme článek od&nbsp;Google o&nbsp;[Performance Insights](https://developer.chrome.com/docs/devtools/performance-insights/).

## Závěrem

Pamatujte, že&nbsp;optimalizace metrik Core Web Vitals mimojiné napomáhají dobré uživatelské zkušenosti na&nbsp;webu. Případné úpravy pro&nbsp;zlepšení metrik je&nbsp;potřeba vždy otestovat.

Ideálními nástroji pro&nbsp;toto testování jsou Core Web Vitals Overlay a&nbsp;panely Performance a&nbsp;Performance Insights. Všechny zmíněné nástroje součástí Dev Tools v&nbsp;Chrome, což&nbsp;značně usnadňuje práci.

Pro&nbsp;testování naopak nedoporučujeme používat Lighthouse, ani pokus-omyl (vystavím a&nbsp;čekám na&nbsp;dopad v&nbsp;uživatelských datech).


Nově si můžete upravovat nastavení testů, vylepšili jsme měsíční reporting e&#8209;mailem, vyměnili jsme pár metrik, zjednodušili pár složitostí a&nbsp;pochytali mnoho bugů.

Pojďme se teď spolu podívat na konkrétní změny.


## 1) Nastavení: aliasy pro URL adresy

![ ](/uploads/31.png " ")
U&nbsp;testů, které máte přidané do vašeho dashboardu, můžete měnit nastavení. Kromě úpravy měřených URL adres můžete také nově přidat alias, tedy jejich pojmenování.

Je to užitečné zejména z&nbsp;pohledu přehlednosti reportů a&nbsp;grafů.

## 2) Nastavení: typ domény

![ ](/uploads/31-1.png " ")
V&nbsp;nastavení testu je nyní také možné vybrat typ domény. Můžete zvolit například „Produkce“ (tedy vaše veřejné domény), „Test“ (testovací verze vašich webů) nebo „Konkurence“ (pokud monitorujete také konkurenci).

Dále s&nbsp;tím pak pracujeme, zejména v&nbsp;e&#8209;mailových reportech.

## 3) E&#8209;maily: lepší reporting

![ ](/uploads/31-2.png " ")

Pokud si v&nbsp;nastavení testu u&nbsp;vašich domén zvolíte „Produkce”, budeme vám v&nbsp;e&#8209;mailovém reportu posílat upozornění jen na změny metrik u&nbsp;vašich domén.

Dostanete tak přesnější informaci o&nbsp;tom, co se na webu děje.

## 4) Dashboard: přidání testu rovnou do dashboardu

![ ](/uploads/31-3.png " ")

Původně bylo přidání testu přímo do vašeho dashboardu poněkud těžkopádné. Nyní je to možné udělat na jedno kliknutí.

Tip: Jak na [monitoring rychlosti webů](https://www.pagespeed.cz/blog/monitoring-rychlosti-webu-s-pagespeed) s&nbsp;našim testerem?

## 5) Lighthouse: možnost stažení souboru JSON

![ ](/uploads/31-4.png " ")
K&nbsp;reportům nástroje Lighthouse jsme nově přidali možnost stáhnout výsledky ve&nbsp;formátu JSON.

Ty pak můžete použít například v&nbsp;[Lighthouse Vieweru](https://googlechrome.github.io/lighthouse/viewer/) nebo [Diff Tool](https://googlechrome.github.io/lighthouse-ci/difftool/), který umožňuje srovnávat dva různé reporty a&nbsp;najít, co přesně se změnilo.

## 6) Reporty: odstranění zastaralých metrik - SI, TTI

Metrika Time To Interactive (TTI) se nově [v&nbsp;nástroji Lighthouse desáté verze](https://www.vzhurudolu.cz/blog/222-lighthouse-10) neměří, proto jsme ji odstranili z&nbsp;reportů.

Grafy a&nbsp;tabulky jsme očistili také o&nbsp;metriku Speed Index (SI), kterou rovněž považujeme za relativně zastaralou. Nicméně ve výsledných testech Lighthouse ji stále ještě najdete.

## 7) Reporty: přidání metriky INP


![](/uploads/31-5.png)

Jak asi víte, Google již nějakou dobu „hrozí“ náhradou metriky [First Input Delay (FID)](https://www.vzhurudolu.cz/prirucka/metrika-fid) za [Interaction to Next Paint (INP)](https://www.vzhurudolu.cz/prirucka/metrika-inp). Nestane se to nejspíš v&nbsp;dohledné době, ale je určitě zajímavé tuto metriku interaktivity vidět.

Nově je tedy ve všech datech od uživatelů, které stahujeme z&nbsp;Chrome UX Reportu.

## Drobnosti a&nbsp;opravy chyb

Menších úprav bylo více, stejně jako lapání bugů. Zde pro zájemce uvádím seznam:

1. Domény: zobrazování dat
2. Domény: odstranění navigace tablet, mobil, desktop
3. Nastavení: lepší hlášení, pokud není test v&nbsp;dashboardu
4. Přepnutí týmu podle abecedy
5. Homepage: promo testeru
6. Lepší proces při pozvánce nového uživatele
7. Příležitosti: lepší rady
8. Nastavení: chyba po smazání domén
9. Dashboard: občas špatné zobrazování LCP
10. Nastavení: lepší info, když uživatel není admin
11. Reporty: chybné barvy u&nbsp;metriky CLS

Budeme samozřejmě rádi za vaši zpětnou vazbu, pište na [team@pagespeed.cz](mailto:team@pagespeed.cz).

Pracujeme zároveň na verzi 4, která novinek přinese ještě daleko více. Přihlaste se do [našeho newsletteru](https://www.pagespeed.cz/newsletter), aby vám ta velká změna neutekla.




## Základy: komprese, Gzip a&nbsp;Brotli

V nejobecnější rovině se&nbsp;jedná o&nbsp;zpracování počítačových dat s&nbsp;cílem zmenšit jejich objem, při&nbsp;zachování informací v&nbsp;datech obsažených. My se&nbsp;zde zaměříme na&nbsp;bezztrátovou kompresi, která&nbsp;šetří datový objem při&nbsp;stahování textových souborů jako CSS nebo&nbsp;JS ze&nbsp;serveru do&nbsp;prohlížeče.

Známe dva hlavní způsoby komprese:

* GZIP je&nbsp;starší, rozšířenější a&nbsp;méně efektivní.
* S&nbsp;Brotli dosáhnete obecně větší úspory. Není tak&nbsp;rozšířený, ale podporu v&nbsp;prohlížečích má plnou.

## Proč je&nbsp;důležité zabývat se&nbsp;kompresí?

Komprimovat textové soubory na&nbsp;webu je&nbsp;základ. Komprimaci používáme na&nbsp;HTML,&nbsp;JS a&nbsp;CSS soubory, což&nbsp;jsou zdroje ovlivňující dobu prvního vykreslení stránky. Logicky tedy chceme tyto zdroje co&nbsp;nejmenší.

Dále ji využíváme u&nbsp;favicon, SVG souborů a&nbsp;fontů. Fonty jsou ale speciální kategorie,&nbsp;ty moderní ve&nbsp;formátu WOFF a&nbsp;WOFF2 mají již implementovanou komprimaci v&nbsp;okamžiku generování souboru. Pokud tedy na&nbsp;fonty v&nbsp;těchto formátech zapnete další komprimaci, výsledkem bude soubor s&nbsp;vyšší datovou náročností než ten původní. Tak&nbsp;pozor na&nbsp;to. :)

Způsob komprimace se&nbsp;dá zjistit jednoduše v&nbsp;prohlížeči. Otevřete si DevTools a&nbsp;záložku Network. V&nbsp;tabulce najděte sloupeček `content-encoding`.

![Content-Encoding v&nbsp;DevTools: Když&nbsp;tam nic není, není do&nbsp;dobře.](/uploads/komprese-image4.jpg "Content-Encoding v&nbsp;DevTools: Když&nbsp;tam nic není, není do&nbsp;dobře.")

## Odhalení tajemství úrovní komprese

Nastavením Brotli a&nbsp;GZIPu&nbsp;ale určitě naše práce nekončí, to&nbsp;by&nbsp;bylo moc jednoduché. Oba dva způsoby komprese mají ještě možnost nastavit úroveň (level) komprese. GZIP má takových úrovní celkem 9, Brotli dokonce 11.

Jak se&nbsp;taková úspora různých úrovní komprese projeví na&nbsp;55&nbsp;kB souboru HTML nebo na&nbsp;261&nbsp;kB dat jQuery? Hodně.

![Nudná komprese? Ale co&nbsp;když&nbsp;vám ušetří až dvě třetiny datového objemu?](/uploads/komprese-image5.jpg "Nudná komprese? Ale co&nbsp;když&nbsp;vám ušetří až dvě třetiny datového objemu?")

Velký skok vidíme samozřejmě při&nbsp;porovnávání nekomprimovaného a&nbsp;komprimovaného souboru úrovně 1. Další úrovně ušetří řádově jednotky procent datové velikosti. Měli bychom se&nbsp;tedy ptát na&nbsp;otázku: Jaká úroveň komprimace je&nbsp;nejlepší?

## Hon na&nbsp;ideální nastavení úrovně komprese

V úvahu u&nbsp;nastavení úrovně komprese musíte totiž vzít také vaši infrastrukturu a&nbsp;servery. Pravdou totiž je, že&nbsp;čím vyšší úroveň komprese, tím vyšší nároky na&nbsp;výpočetní výkon. Vyšší úroveň komprese si totiž vyžádá více času na&nbsp;provedení.

![Od&nbsp;šesté úrovně dále už tolik nezískáte.](/uploads/komprese-image2.jpg "Od&nbsp;šesté úrovně dále už tolik nezískáte.")

Všeobecně za&nbsp;PageSpeed.cz doporučujeme jako ideální úroveň 6. Pokud preferujete podrobnější vysvětlení, mrkněte se&nbsp;na&nbsp;video [What is the GZIP compression level sweet spot](https://www.youtube.com/watch?v=9jJrg6L3-Hc)?

## Nejrychlejší způsob zjištění úrovně komprimace

Možná jste se&nbsp;tady zastavili a&nbsp;ptali sami sebe, jak zjistíte na&nbsp;vlastním webu úroveň komprimace. K&nbsp;rychlé kontrole může být užitečný [online nástroj](https://tools.paulcalvano.com/compression.php), do&nbsp;kterého vložíte URL. Vyhodnocením zjistíte pravděpodobnou úroveň komprimace.

![Tímto nástrojem odhalíte, jakou úroveň komprese máte nastavenou.](/uploads/komprese-image3.jpg "Tímto nástrojem odhalíte, jakou úroveň komprese máte nastavenou.")

## Dobře nastavená komprimace není samozřejmost

V PageSpeed.cz jsme si udělali průzkum webů některých [našich klientů](https://www.pagespeed.cz/reference). Výsledkem je, že&nbsp;6 z&nbsp;24 webů nemělo ideálně nastavenou úroveň komprimace.

Řešení takového problému ale není nikterak složité. U&nbsp;GZIPu&nbsp;by&nbsp;se&nbsp;o&nbsp;nastavení úrovně komprimace měl postarat člověk zodpovědný za&nbsp;infrastrukturu, někdo z&nbsp;webhostingu&nbsp;nebo šikovný backend vývojář. Level komprimace se&nbsp;[nastavuje na&nbsp;úrovni APACHE](https://serverfault.com/questions/607778/how-to-set-apache-2-2-gzip-compression-level) a&nbsp;jde o&nbsp;jeden řádek kódu:

`DeflateCompressionLevel 9`

Jednoduché, že? Takové přenastavení jsem řešili s&nbsp;jedním z&nbsp;našich klientů. Na&nbsp;HTML byl&nbsp;původně nastavený GZIP LEVEL 1, který&nbsp;jsme po&nbsp;konzultaci nechali přenastavit na&nbsp;LEVEL 6.

Výsledek? Dosáhli jsme díky tomu cca 22&nbsp;% úspory ve&nbsp;velikosti HTML (z 81&nbsp;kB na&nbsp;63 kB).

![Co&nbsp;to&nbsp;udělá s&nbsp;datovým objemem HTML, když&nbsp;se&nbsp;nastaví lepší úroveň Gzipu.](/uploads/komprese-image1.jpg "Co&nbsp;to&nbsp;udělá s&nbsp;datovým objemem HTML, když&nbsp;se&nbsp;nastaví lepší úroveň Gzipu.")

Konzultovali jsme také zapnutí komprese Brotli, nicméně to&nbsp;nebylo možné. Novější algoritmus sice zařídí větší úsporu dat, ale uživateli by&nbsp;se&nbsp;stránka reálně načetla později. Brotli komprese totiž trvá delší dobu, obzvláště jeho „runtime“ verze, spouštěná až při&nbsp;dotazu na&nbsp;server.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>Odebíráte už <a href="https://www.pagespeed.cz/newsletter" target="_blank" rel="noreferrer noopener">náš newsletter</a>? Každý měsíc dostanete tipy, jak zlepšit rychlost webu.</em>
</p></div></div>

Může se&nbsp;také stát, že&nbsp;z&nbsp;nějakého důvodu u&nbsp;klienta vypadává celá komprimace dat.

V grafu to&nbsp;vyjadřují&nbsp;ty velké „kopečky“. Zda se&nbsp;stahuje 600&nbsp;kB nebo 100&nbsp;kB CSS je&nbsp;zcela zásadní rozdíl a&nbsp;je&nbsp;to&nbsp;argument pro&nbsp;to&nbsp;[měřit na&nbsp;webech technická data](https://www.pagespeed.cz/management-rychlosti-webu) a&nbsp;velikosti. Tyto problémy pak celkem jednoduše odhalíte.

![Tohle v&nbsp;grafu vidět nechcete. Aneb když&nbsp;vám občas vypadne komprese.](/uploads/komprese-image6.jpg "Tohle v&nbsp;grafu vidět nechcete. Aneb když&nbsp;vám občas vypadne komprese.")

## Záchrana pro&nbsp;lenochy: Cloudflare

Další možností, jak vyřešit úroveň komprimace, je&nbsp;nastavit pro&nbsp;svoji doménu službu Cloudflare. Ta&nbsp;začne ukládat vaše textové soubory a&nbsp;aplikuje na&nbsp;ně nejlepší možnou komprimaci. Pokud se&nbsp;budeme bavit konkrétně, Cloudflare zapíná na&nbsp;CSS, JS, SVG atd. rovnou Brotli.

Jestliže tuto službu využíváte, můžete si své nastavení zkontrolovat. U&nbsp;některých tarifů je&nbsp;Brotli potřeba [zapnout](https://support.cloudflare.com/hc/en-us/articles/200168396-What-will-Cloudflare-compress-).

## Shrnutí na&nbsp;závěr

* Zkontrolujte si nastavení komprimace v&nbsp;DevTools (Network Tab), nebo v&nbsp;nástroji Lighthouse.
* Obecně se&nbsp;u&nbsp;komprimace doporučuje nastavit úroveň 6.
* Vyšší úrovně než 6 nepřináší zásadní rozdíly ve&nbsp;velikosti souborů.
* Fonty (WOFF a&nbsp;WOFF2) jsou již komprimované.
* Čím vyšší stupeň komprimace, tím vyšší náročnost na&nbsp;výkon serveru a&nbsp;čas.
* Pokud zjistíte problém, přenastavte level komprese.
* Cloudflare to&nbsp;může vyřešit automaticky za&nbsp;vás.

Rok 2022 byl&nbsp;pro&nbsp;PageSpeed.cz ostrým startem. Více než dříve jsme poskytovali poradenské [služby zaměřené na&nbsp;optimalizaci rychlosti webu](https://www.pagespeed.cz/sluzby) a&nbsp;rozvíjeli vlastní [tester rychlosti](https://app.pagespeed.cz/). Začali jsme také pracovat ve&nbsp;[čtyřčlenném týmu](https://www.pagespeed.cz/kontakty) – kromě mě, Michala a&nbsp;Zuzky ještě s&nbsp;Radkem.

Co&nbsp;je&nbsp;ale nejdůležitější – mnoha klientům jsme rychlost webu reálně pomohli zvýšit. Pracovali jsme také na&nbsp;stále podstatnějším tématu kultury rychlosti.

## Vybrané optimalizace rychlosti

Někdy to&nbsp;jde rychle, někdy pomaleji. Bezpečně ale víme, že&nbsp;pokud má rychlost na&nbsp;straně klienta prioritu a&nbsp;pokud jde komunikace dobře, výsledky se&nbsp;vždy dostaví. Vybral jsem tři z&nbsp;nejzajímavějších případů.

### Dr.&nbsp;Max: Optimalizace CLS a&nbsp;LCP

S [Dr.&nbsp;Max Group](https://www.drmax.eu/) spolupracujeme na&nbsp;zrychlování jejich farmaceutických e-shopů od&nbsp;roku 2021. Vypracovali jsme pro&nbsp;tým kolem [Petera Vargy](https://www.linkedin.com/in/35collin35/) náš [audit](https://www.pagespeed.cz/audit), pomocí kterého se&nbsp;povedlo vylepšit metriku [Cumulative Layout Shift (CLS)](https://www.vzhurudolu.cz/prirucka/metrika-cls), kumulativní posun layoutu:

![Cumulative Layout Shift na&nbsp;webech Dr.&nbsp;Max: vývoj za&nbsp;rok 2022.](/uploads/success-2022-image5.png "Cumulative Layout Shift na&nbsp;webech Dr.&nbsp;Max: vývoj za&nbsp;rok 2022.")

Především jsme se&nbsp;zaměřili na&nbsp;optimalizaci zobrazování personalizovaného obsahu, které na&nbsp;e-shopech dělá komponenta Persoo. Klient se&nbsp;pak na&nbsp;naše doporučení soustředil na&nbsp;vylepšení backendu, tedy [metriku TTFB](https://www.vzhurudolu.cz/prirucka/ttfb):

![Měření reálných uživatelů ve&nbsp;SpeedCurve. Schody dolů vidíme moc rádi!](/uploads/success-2022-image3.png "Měření reálných uživatelů ve&nbsp;SpeedCurve. Schody dolů vidíme moc rádi!")

Aktuální metriky [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals) všech webů jsou krásné…

![Data o&nbsp;rychlosti od&nbsp;Googlu na&nbsp;webech Dr.&nbsp;Max: začalo se&nbsp;nám to&nbsp;zelenat.](/uploads/success-2022-image4.png "Data o&nbsp;rychlosti od&nbsp;Googlu na&nbsp;webech Dr.&nbsp;Max: začalo se&nbsp;nám to&nbsp;zelenat.")

U Dr.&nbsp;Maxe s&nbsp;optimalizacemi ještě nekončíme. Čeká nás analýza vlivu rychlosti na&nbsp;konverze, posílení Performance Culture a&nbsp;další technické optimalizace metrik.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>Mimochodem, chtěli byste stejný dashboard jako Dr.&nbsp;Max? V&nbsp;našem testeru je&nbsp;možné si&nbsp;jej&nbsp;<a href="https://www.pagespeed.cz/blog/monitoring-rychlosti-webu-s-pagespeed" target="_blank" rel="noreferrer noopener">vytvořit zdarma</a>.</em>
</p></div></div>

### Sazka: pokračování čtyřleté spolupráce, blíží se&nbsp;šťastný konec

Sazka je&nbsp;jeden z&nbsp;mých nejstarších klientů, pracovat jsem pro&nbsp;ni začal v&nbsp;roce 2018, v&nbsp;týmu s&nbsp;ostatními pod&nbsp;značkou PageSpeed.cz pak od&nbsp;loňska.

U takto velkých firem je&nbsp;optimalizace rychlosti spíše otázkou budování „Performance Culture“, kultury rychlosti. I&nbsp;díky tomu se&nbsp;nám za&nbsp;mohutné pomoci [Martina Kocourka](https://www.linkedin.com/in/kocourekm/?originalSubdomain=cz) na&nbsp;straně Sazky a&nbsp;jejich vývojářů povedlo loni s&nbsp;rychlostí opravdu významně pohnout:

![Padá metrika, něco si přej.](/uploads/success-2022-image2.png "Padá metrika, něco si přej.")

K našemu cíli – „zeleným Web Vitals“ pro&nbsp;celou doménu – už nám zbývá jenom kousek. I&nbsp;přes to, že&nbsp;se&nbsp;naši snahu loni pokoušeli zhatit různí dodavatelé nových komponent třetích stran. Ale o&nbsp;tom zase jindy.

### Goldea: Optimalizace CLS

Náš zlínský klient MIONET provozuje síť e-shopů s&nbsp;bytovým textilem pod&nbsp;značkou [Goldea](https://www.goldea.cz/). Oslovil nás, abychom optimalizovali Core Web Vitals, v&nbsp;jejich případě hlavně metriku Cumulative Layout Shift.

Optimalizace CLS na&nbsp;mobilech byla snadná – většinou jsme si vystačili jen&nbsp;s&nbsp;drobnými úpravami HTML a&nbsp;CSS kódu, případně dolaďování ajaxového stránkování, které&nbsp;bývá z&nbsp;pohledu rychlosti problematické.

V případě desktopu jsme se&nbsp;trošku zapotili. Nechtěné poskakování stránky bylo problematické hlavně při&nbsp;filtrování v&nbsp;seznamu produktů:

![Procházení filtry v&nbsp;seznamu produktů zde zvyšuje CLS.](/uploads/success-2022-image6.png "Procházení filtry v&nbsp;seznamu produktů zde zvyšuje CLS.")

… ale nakonec jsme to&nbsp;zvládli také:

![Už se&nbsp;to&nbsp;zelená, je&nbsp;to&nbsp;báječné.](/uploads/success-2022-image7.png "Už se&nbsp;to&nbsp;zelená, je&nbsp;to&nbsp;báječné.")

U téhle spolupráce jsme se&nbsp;naučili hodně o&nbsp;[metrice CLS](https://www.vzhurudolu.cz/prirucka/metrika-cls), jejich specifikách a&nbsp;také nevýhodách. Ještě si od&nbsp;nás určitě přečtete detailnější případovou studii.

<div class="b-tip b-tip--lg"><div class="b-tip__inner"><svg viewBox="0 0 28 38"><path d="M14 0c-.9 0-1.9.1-2.8.3-5.5 1.1-9.9 5.5-11 11-1 5.2 1 10 4.4 13.1.9.8 1.4 1.9 1.4 3V32c0 2.2 1.8 4 4 4h.6c.7 1.2 2 2 3.4 2s2.8-.8 3.4-2h.6c2.2 0 4-1.8 4-4v-4.6c0-1.1.4-2.2 1.3-2.9C26.2 21.9 28 18.2 28 14c0-7.7-6.3-14-14-14zm4 32h-8v-2h8v2zm0-4h-8v-2h8v2zm-3-11.2V22h-2v-5.2l-3.7-3.6 1.4-1.4L14 15l3.2-3.2 1.4 1.4-3.6 3.6z" fill="#fec245"></path></svg><p>
<em>Loni jsme také byli vidět na&nbsp;několika konferencích, jmenujme alespoň naší <a href="https://blog.development.pagespeed.cz/blog/pagespeed-na-webexpu" target="_blank" rel="noreferrer noopener">přednášku a&nbsp;diskuzi na&nbsp;WebExpo</a>.</em>
</p></div></div>


## Performance Culture, budování kultury rychlosti v&nbsp;organizacích

Stále větší část naší práce spadá do&nbsp;oblasti tzn. Performance Culture, kultury rychlosti, kdy&nbsp;klientům pomáháme s&nbsp;interními procesy tak, aby&nbsp;se&nbsp;dařilo rychlost dále zlepšovat i&nbsp;bez naší intenzivní spoluúčasti.

Uvedu tři příklady tohoto typu spolupráce z&nbsp;loňska:

1. Pro&nbsp;[HP Tronic](https://www.hptronic.cz/), konkrétně [weby Datartu](https://www.datart.cz/), jsme dělali [audit rychlosti](https://www.pagespeed.cz/audit), školení netechnických zaměstnanců a&nbsp;s&nbsp;pomocí SpeedCurve RUM jsme hledali korelace mezi byznysovým a&nbsp;rychlostními metrikami. Nyní víme, na&nbsp;jaké metriky se&nbsp;máme primárně zaměřovat a&nbsp;snadněji se&nbsp;nám prioritizují optimalizace.
2. V&nbsp;[Sazce](https://www.sazka.cz/) jsme loni kromě výše uvedených běžných optimalizací dělali workshopy pro&nbsp;vývojáře. Cílem bylo předat co&nbsp;nejvíce našich znalostí na&nbsp;technické lidi, aby&nbsp;leccos dokázali řešit sami. Dále jsme na&nbsp;workshopech společně vytyčili další optimalizační cíle. Workshopy byly velmi úspěšné a&nbsp;díky nim se&nbsp;v&nbsp;Sazce povedlo dostat rychlost webu na&nbsp;aktuální úroveň.
3. Pro&nbsp;[Dr.&nbsp;Max Group](https://www.drmax.eu/en/default) jsme připravili online školení vývojářů a&nbsp;o&nbsp;rychlosti povídali také na&nbsp;jejich vydařené interní konferenci:

![Konference Dr.&nbsp;Max: krásný graf a&nbsp;optimalizátor rychlosti u&nbsp;něj.](/uploads/success-2022-image8.jpg "Konference Dr.&nbsp;Max: krásný graf a&nbsp;optimalizátor rychlosti u&nbsp;něj.")

S většinou klientů pracujeme na&nbsp;dlouhodobé bázi, v&nbsp;rámci služby management rychlosti webu. S&nbsp;týmem na&nbsp;straně klienta se&nbsp;pravidelně slýcháváme, vzděláváme tým, aktivně sledujeme metriky a&nbsp;přicházíme s&nbsp;nápady na&nbsp;snadné technické optimalizace.

Umíme pomoci malým i&nbsp;velkým a&nbsp;čas najdeme i&nbsp;na&nbsp;váš projekt. Neváhejte se&nbsp;[ozvat](https://www.pagespeed.cz/kontakty).

Ať se&nbsp;vám daří v&nbsp;roce 2023, a&nbsp;to&nbsp;nejen s&nbsp;rychlostí webu!

V tomto článku se podíváme na některé vlastnosti, techniky nebo nástroje, které nás v roce 2022 nejvíce zaujaly.

## 1) Obrázky WebP i AVIF téměř ve všech prohlížečích

Podpora nových formátů se opět zlepšila. Moderní formáty obrázků, jako jsou WebP a AVIF, mohou výrazně urychlit webové stránky tím, že stejné informace zakódují do menších souborů.

Zatímco [WebP je široce podporován](https://caniuse.com/?search=webp) již více než dva roky, [podpora AVIF](https://caniuse.com/?search=avif) se v Safari objevila až letos v září s vydáním iOS 16 a macOS Ventura. Mějte na paměti, že ne všichni uživatelé Safari již provedli upgrade a že Edge stále nepodporuje AVIF. WebP ale můžete používat vcelku bez zaváhání.

![](/uploads/news-2022-image5.png)

## 2) Změna výpočtu metriky CLS

Jak jsme sami v týmu konzultantů PageSpeed.cz zjistili, správně pochopit počítání metriky je základní předpoklad pro úspěšnou optimalizaci.

Metodika měření metriky Cumulative Layout Shift se změnila několikrát, naposledy docela zásadně. Pokud chcete tedy pochopit pojmy jako Session Window, Session Gap a zjistit, jak to funguje všechno dohromady, přečtěte si [český článek o CLS na Vzhůru Dolů](https://www.vzhurudolu.cz/prirucka/metrika-cls).

![](/uploads/news-2022-image7.png)

## 3) Early Hints: načtěte zdroj ještě dříve než preloadem

Do Chrome v roce 2022 zamířila také zajímavá novinka pod názvem [Early Hints](https://developer.chrome.com/blog/early-hints/). Jedná se o HTTP status code (103 Early Hints), který umožňuje odesílat serveru „nápovědu“ o kritických dílčích zdrojích.

Zatímco server generuje hlavní zdroj, do prohlížeče se díky Early Hints už stahují kritické soubory (soubory s CSS, JS), což může vylepšit rychlost webů.

![](/uploads/news-2022-image2.png)

## 4) Priority Hints v Chrome a Edge od verze 101

Chrome a Edge od verze 101 přináší novinku, která jde v práci s prioritami mnohem dál. [Priority Hints](https://web.dev/priority-hints/) (doporučení pro prioritizaci) totiž pracují s atributem _fetchpriority_, který lze přidat k prvku HTML a prioritu jeho stažení zvýšit či snížit. Více se můžete dozvědět také na webu [Vzhůru dolů](https://www.vzhurudolu.cz/prirucka/priority-hints).

![](/uploads/news-2022-image6.png)

## 5) Měření rychlosti webu krok za krokem (a náš tester 3.0)

Martin Michálek pro vás připravil [aktuální návod na měření rychlosti webu](https://www.pagespeed.cz/blog/mereni-seo-restart?utm_source=overview&utm_medium=email&utm_campaign=202204). Měříte správně? A měříte doménu, konkrétní URL a také skupiny stránek podle toho, co po nás chce Google? Text je určený hlavně netechnickým lidem a ukazuje, jak si měření usnadnit s pomocí třetí verze našeho testeru.

![](/uploads/news-2022-image8.png)

## 6) Příchod nové metriky: Interaction to Next Paint (INP)

[Interaction to Next Paint](https://web.dev/inp/) je prozatím experimentální metrika, která měří odezvu webu po interakci uživatele. Google tvrdí, že by měla v Core Web Vitals časem nahradit First Input Delay (FID), protože FID aktuálně plní 95 % webů. FID také měří pouze první interakci a jednu část cyklu interakce. INP bude měřit všechny interakce během procházení stránek a její hranice je prozatím stanovena na 200 ms. Více najdete také na webu [Vzhůru dolů](https://www.pagespeed.cz/blog/mereni-seo-restart?utm_source=overview&utm_medium=email&utm_campaign=202204). Přidáváme i pár tipů, jak metriku [INP optimalizovat](https://web.dev/optimize-inp/).

![](/uploads/news-2022-image10.png)

## 7) Performance Insights: Jednodušší a přehlednější pohled na rychlost

Pokud chcete ladit rychlost, ale záložka Performance v Chrome DevTools vám přijde složitá, zkuste [Performance Insights](https://developer.chrome.com/docs/devtools/performance-insights/). Ten zobrazuje jenom nejrelevantnější informace, především týkající se Web Vitals. [Podrobný návod](https://developer.chrome.com/docs/devtools/performance-insights/), jak nástroj používat, sepsali na webu Chrome Developers.

![](/uploads/news-2022-image1.png)

## 8) CSS size-adjust: systémová a webová písma v harmonii

Začali jsme hojně využívat [CSS pravidlo size-adjust](https://caniuse.com/?search=%40font-face%20%20size-adjust), které má již vysokou podporu v prohlížečích. Rozdíl mezi webfontem z designu vašeho webu a systémovým fontem může způsobovat nechtěné posuny layoutu (CLS). Pro tyto situace je zde nová CSS vlastnost _size-adjust_ a _ascent-override_ a [tento nástroj](https://screenspan.net/fallback), který vám usnadní implementaci.

![](/uploads/news-2022-image9.png)

## 9) CLS: Jak zajistit poměr stran obrázků a vyhnout se nechtěným posunům layoutu

Jake Archibald ve [svém článku](https://jakearchibald.com/2022/img-aspect-ratio/?utm_source=overview) popisuje dvě techniky, jak docílit stabilního layoutu, ve kterém jsou obrázky. Jednou z nich je CSS vlastnost _aspect-ratio_, druhou staré dobré atributy _width_ a _height_ v HTML. K tomu autor přidává spoustu zajímavých detailů. Znali jste například zápis _aspect-ratio: auto 16/9_? Ten zajišťuje, že elementu je nastaven poměr 16:9, ale pokud má obrázek jiný poměr, ten se po načtení aplikuje.

![](/uploads/news-2022-image3.png)

## 10) Plná podpora nativního lazyloadu již i v Safari

Od Safari verze 15.4, která vyšla letos březnu, podporují atribut [loading="lazy"](https://caniuse.com/loading-lazy-attr) všechny prohlížeče u obrázků. Pro podporu líného načtení u `<iframe>` je potřeba ještě v některých prohlížečích funkci zapnout. Nativní líné načtení obrázků zajišťuje, že se obrázky načítají pouze v okamžiku, kdy se chystají objevit ve viewportu, což šetří síť a upřednostňuje důležitější obsah stránky.

![](/uploads/news-2022-image11.png)

## 11) Back/Forward Cache v Chrome

[Bfcache](https://web.dev/bfcache/) je mezipaměť v paměti prohlížeče, která ukládá kompletní snímek stránky (včetně spousty JavaScriptu), zatímco uživatel odchází. Pokud je celá stránka v paměti, může ji prohlížeč rychle a snadno obnovit, když se uživatel rozhodne vrátit.

Od Chrome verze 96 je Bfcache použitelná pro všechny uživatele prohlížeče Chrome, jak na desktopu tak i na mobilních zařízeních. Může to mít zajímavé dopady na rychlost u reálných uživatelů, takže i data z Chrome UX Reportu.

![](/uploads/news-2022-image12.png)

## 12) Dopředné vykreslení celé stránky v prohlížeči Chrome

Někdy je velmi pravděpodobné, že uživatel brzy přejde na novou stránku, a od vydání Chrome verze 108 začne prohlížeč [načítat stránku ještě před přechodem na tuto stránku](https://developer.chrome.com/blog/prerender-pages/).

Když dojde k přechodu na tuto stránku, stránka, která byla načtena na pozadí, se „přednačte“, případně se okamžitě vykreslí.

![](/uploads/news-2022-image4.png)

Tím končí naše shrnutí roku 2022. Co očekáváme v roce 2023? Určitě dojde ke zlepšení podpory již představených vlastností ve všech prohlížečích.

Dále se těšíme, jak a kdy přesně Google využije metriku INP. Rozhodně budeme novinky kolem Web Performance sledovat a přinášet vám o nich čerstvé informace. Sledujte nás na [Twitteru](https://twitter.com/pagespeedcz), [LinkedIn](https://www.linkedin.com/company/42805034/) nebo [Facebooku](https://www.facebook.com/PageSpeed.cz/).


Blog

Reportáž ze SmashingConf Freiburg 2023 🥨

Metrika Kumulativní posun layoutu (CLS): jak najít a odstranit nechtěné posuny stránky

Metrika Largest Contentful Paint (LCP): průvodce rychlejším načtení webu

Rychlejší web snadno a rychle: Nové technologie a nástroje pro vývojáře

Nejrychlejší český eshop má Hornbach, 3v1 a T-shock

WebExpo 2023: přednášky o optimalizaci rychlosti

Klíčová dovednost vývojáře: testování Web Vitals v prohlížeči

Tester rychlosti PageSpeed.cz: novinky ve verzi 3.1

Komprese na webu s Gzip a Brotli: máte to dobře?

Co se nám povedlo: úspěšné optimalizace rychlosti a noví klienti v roce 2022

Rychlost webu: 12 novinek roku 2022