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://docs.pagespeed.cz/docs/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 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](https://docs.pagespeed.cz/docs/webp) ani AVIF nepoužíváte? Měli byste:

- [WebP](https://docs.pagespeed.cz/docs/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](https://docs.pagespeed.cz/docs/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://docs.pagespeed.cz/docs/cls-img-width-height). 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://developer.mozilla.org/en-US/docs/Web/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 to vykreslí systémovým fontem, pak webfontem. A přitom to 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 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://pagespeed.cz/monitoring-plus), 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/services).

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 uživatele vypadají jinak než ty z 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ž chcete znát detaily a nechcete se v 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 nástroje Performance nebo Performance Insights a 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.


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/services) 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/contacts) – 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 webech Dr. Max: vývoj za rok 2022.](/uploads/success-2022-image5.png 'Cumulative Layout Shift na webech Dr. Max: vývoj za 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://docs.pagespeed.cz/docs/ttfb):

![Měření reálných uživatelů ve SpeedCurve. Schody dolů vidíme moc rádi!](/uploads/success-2022-image3.png 'Měření reálných uživatelů ve 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 rychlosti od Googlu na webech Dr. Max: začalo se nám to zelenat.](/uploads/success-2022-image4.png 'Data o rychlosti od Googlu na webech Dr. Max: začalo se nám to 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 seznamu produktů zde zvyšuje CLS.](/uploads/success-2022-image6.png 'Procházení filtry v seznamu produktů zde zvyšuje CLS.')

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

![Už se to zelená, je to báječné.](/uploads/success-2022-image7.png 'Už se to zelená, je to 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. Max: krásný graf a optimalizátor rychlosti u něj.](/uploads/success-2022-image8.jpg 'Konference Dr. Max: krásný graf a optimalizátor rychlosti u 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/contacts).

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](https://docs.pagespeed.cz/docs/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/).


Za dva dny jsme s Michalem slyšeli celkem 14 špičkových přednášek v prostoru bývalého kostela. Ano, čtete správně, letošní ročník [Performance.now()](https://perfnow.nl/) se konal na místě zvaném [Zuidekerk](https://en.wikipedia.org/wiki/Zuiderkerk), což byl původně protestantský kostel ze 17. století. Nyní tento prostor slouží ke konání akcí.

Výběr místa musím opravdu pochválit, jelikož je netradiční. Nicméně kdo alespoň trochu zná povahu Amsterdamu, nediví se. Pro uvolněnou a volnomyšlenkářskou atmosféru Amsterdamu je to velmi typické. Pauzy mezi přednáškami a volný čas jsme strávili poznáváním města.

![](/uploads/img_1391.jpg " ")

## Co nám Perf.now() nabídl?

Po skončení konference jsme samozřejmě vybrali nejlepší letošní přednášky. Níže je náš seznam:

### Nolan Lawson - CSS runtime performance

[Přednáška](https://nolanlawson.github.io/css-talk-2022/#1) pro geeky, kteří chtějí vytřískat ze své frontendové performance maximum. I přes velký spoiler na začátku, že se „jedná o mikrooptimalizace“, [Nolan](https://nolanlawson.com/) ukázal detail toho, jak náročné je pro browser vypočítat styl a sestavit layout. Nasdílel s námi také nástroj [Chrome Trace Event Profiling](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/), který pomáhá debugovat např. [rychlost selektorů](https://twitter.com/mattzeunert/status/1585656791920156677).

### Alex Rusell - The Global Baseline, 2022

[Alex](https://twitter.com/slightlylate) se ve své přednášce zaměřuje na věčné téma uživatelů a jejich systémových (hardwarových) a síťových podmínek. Jak v jednom slidu trefně připomíná, „váš iPhone není reálný svět“. S jakými parametry tedy pracujeme a na jaký výkon můžeme naše weby stavět? Celosvětově je telefon na 75. percentilu ve 4. čtvrtletí roku 2022 zařízení s cenou okolo 200 USD, což odpovídá Samsungu Galaxy A50 apod. Stále bychom tedy měli preferovat HTML a CSS nad JS. Dostačujícím maximem může být 150 kB HTML/CSS a 300-300 kB JS.

![](/uploads/z2qx_mju2rz8rrfj9knxc0bvmpvc0ufzk-wawhil4jzlw0ranb27a6njfdsycbpsf4ncypb2vsxtcvbn0ifht3mgiitxka1bu_8zuic5uoln0hm57arypjaz80yep7kscltexulucm7p8nrqqmnimrouo8ulnxncn10rutzv5mo6zbh3xzkfl_7ftqik9q.jpeg " ")

### Harry Roberts - Optimising Largest Contentful Paint

[Harryho](https://twitter.com/csswizardry) není třeba dlouze představovat (viz naše [zápisky](https://www.pagespeed.cz/blog/srovnejte-si-to-v-head) o pořadí prvků v `<head>`) a jeho přednáška rozhodně nezklamala. Klobouk dolů před tím, jak postavil přednášku na 40 minut pouze kolem metriky LCP. Tuto přednášku bych doporučila asi všem, protože jak říká Harry „na optimalizaci LCP nic není, jen je potřeba znát jak to funguje“. Harry mimojiné vysvětlil, jak se změní metrika LCP, pokud obrázek na stránku vložíte jako `<svg>`, jako background-image nebo klasicky v `<img>`. Krátká odpověď: Způsob vložení na stránku má zásadní vliv na metriku LCP.

### Ivan Akulov - React 18 Concurrency, Explained

Více programátorská přednáška o Reactu 18 a jeho novém API useTransition a `<Suspense>`. Ivan názorně ukázal jak lze v Reactu využívat tzv. konkurence, kdy start aplikace resp. datová hydratace či náročný UI update neblokuje uživatelský vstup. Ideální nástroj pro boj s FID a INP.

### Katie Sylor-Miller - How to be a Performance Detective?

Nejenom obsah dělá skvělou přednášku, ale také forma je důležitá. Z tohoto pohledu byla přednáška Katie nezapomenutelná. Na příkladu detektiva Pikačua nás provedla svým procesem monitorování performance. Praktické nám přijde hlavně její použití [Distribučních funkcí](https://cs.wikipedia.org/wiki/Distribu%C4%8Dn%C3%AD_funkce) (vypadají jako „obrácené histogramy“) k vyhodnocování a porovnávání naměřených dat před a po změnách na webu.

![](/uploads/nywh0_s049yt9lrn6thgfq0a-i8dunnjnrtrjfnfriomizj5hr3v4rsbhqwwka9eyhb4yfr6-lxykdpokz5scrgavc3u8zszp_n2b5wagu_2lc8dalspa8b1d9odem39thwxcauxfyujzlqbrlgmxnk4zypuss2qc2why4viygat_6vgrw8i88vgh37ntg.jpeg " ")

Na závěr organizátoři oznámili skvělou zprávu. Další ročník [Performance.now()](https://perfnow.nl/) se bude konat 2. a 3. listopadu 2023, na stejném místě jako letos. Těšíme se!

Všechny přednášky si můžete pustit na [Youtube](https://www.youtube.com/playlist?list=PLjnstNlepBvN4Cpv_Io-GpvJKdo1Bu-Vz), kde budou postupně zveřejňovány.


Pojďte se naučit, jak efektivně hlídat rychlost vašich webů s pomocí našeho [testeru rychlosti](https://app.pagespeed.cz/). Je to snadné a tester je zdarma k dispozici.

<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: Pokud dáváte přednost videotutoriálu, pusťte si video, v opačném případě pokračujte ve čtení níže.</p></div></div>

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

V uplynulých měsících jsme spustili [třetí verzi testeru](https://www.pagespeed.cz/blog/pagespeed.cz-tester-verze-3) s novými vlastnostmi, jako je možnost přihlášení, práce v týmech a sledování rychlosti vašich webů v dashboardu.

Dashboard vám pak ukazuje všechny vaše testy (na obrázku číslo 1), u nich jednotlivé domény (2), stav [metrik Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals) z Chrome UX Reportu a jejich případné zlepšení nebo zhoršení (3):

![Dashboard ukazuje všechny vaše testy](/uploads/ps-dashboard.png 'Dashboard ukazuje všechny vaše testy')

Nedávno jsme také upravili způsob rozesílání e-mailových reportů. Každý měsíc se e-mailem dozvíte největší změny (na následujícím obrázku číslo 1), u vámi sledovaných webů a připomeneme vám aktuální hodnoty Web Vitals (2):

![E-mailem se dozvíte největší změny](/uploads/ps-mail.png 'E-mailem se dozvíte největší změny')

Pojďme si teď krok za krokem ukázat, jak tohoto pohodlného sledování rychlosti vašich webů můžete dosáhnout i vy.

## Krok 1: Zaregistrujte se a založte si tým

[Vytvoření nového účtu](https://pagespeed.cz/register) je zdarma, stejně jako celý nástroj. Rovnou se vás při zřízení účtu ptáme na název týmu, což může být buď jméno firmy nebo vaší osoby, pokud pracujete sami:

![Vytvoření nového účtu](/uploads/ps-team.png 'Vytvoření nového účtu')

Můžete si ale pořídit hned několik týmů, například pro každého vašeho klienta. Počtem to limitováno není:

![Můžete si vytvořit několik týmů](/uploads/ps-teams.png 'Můžete si vytvořit několik týmů')

Do každého týmu pak můžete pozvat uživatele, vaše kolegy nebo třeba klienty a přidělit jim různé úrovně oprávnění, například pro správu uživatelů, nebo jen pro čtení:

![Můžete přidělit různé úrovně oprávnění](/uploads/ps-teams-admin.png 'Můžete přidělit různé úrovně oprávnění')

První krok máme za sebou, pojďme na další.

## Krok 2: Přidat testy do dashboardu

Pokud náš nástroj používáte, nejspíš už nějaké testy máte. URL testů platí trvale – pokud je navštěvujete alespoň jednou za dva měsíce, nemažeme je.

[Vytvořit nový test](https://app.pagespeed.cz/) je snadné:

![Vytvoření testu](/uploads/ps-test.png 'Vytvoření testu')

Jak vybrat URL?

- Pokud testujete jeden web, zvolte homepage a pak nejnavštěvovanější zástupce jednotlivých typových stránek. U e-shopu to bude kategorie, detail produktu a pak třeba kontaktní stránka. S výběrem vhodných URL vám pomohou data o návštěvnosti z Google Analytics, alternativně pak data z Google Search Console.
- Můžete si ale také rovnou nechat otestovat více domén, například srovnat se s vaší konkurencí. Další domény ale není nutné zadávat hned při vytváření testu. V nastavení testu si totiž nově můžete přidat k URL ještě domény. Ale to uděláme až v jednom z dalších kroků.

Test máme vytvořený a nyní si jej přidáme do dashboardu, abychom mohli monitorovat stav rychlosti webů a také upravovat nastavení testu.

<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: Přečtěte si více <a href="https://www.pagespeed.cz/blog/mereni-seo-restart">o měření rychlosti webů</a> s použitím testeru PageSpeed.cz, ale i dalších nástrojů.</p></div></div>

Pro vložení testu do aktivního dashboardu prostě jen posuňte kteroukoliv stránku testu dolů, dokud nenajdete tlačítko „Přidat k mým testům“:

![Přidání testu do dashboardu](/uploads/ps-test-add.png 'Přidání testu do dashboardu')

## Krok 3: Sledujte vývoj rychlosti v testu

Už samotný test vám poskytne zajímavé údaje o rychlosti URL, které jste nechali testovat.

V záložce Stránky uvidíte data syntetických testů z PageSpeed Insights API (testy nástrojem Lighthouse, viz číslo 1 na obrázku níže) nebo data od uživatelů z [Chrome UX Reportu](https://www.vzhurudolu.cz/prirucka/chrome-ux-report) (2). Ty dostanete jen pokud má URL dostatečnou návštěvnost:

![Sledujte vývoj rychlosti v testu](/uploads/ps-test-view.png 'Sledujte vývoj rychlosti v testu')

Záložka Domény vám poskytne přehled o vývoji dat z Chrome UX Reportu v dlouhodobější, měsíční perspektivě:

![Vývoj dat v dlouhodobější, měsíční perspektivě](/uploads/ps-test-month.png 'Vývoj dat v dlouhodobější, měsíční perspektivě')

## Krok 4: Změňte si nastavení testu

Další krok je volitelný. Možná nevíte, že přidáním testu do vaší sbírky pro sledování v dashboardu, získáte vy a administrátoři vašeho týmu možnost upravovat jeho nastavení.

Kromě možnost změny názvu testu nebo jeho URL vás upozorníme na část, ve které můžete do testu přidat domény:

![Změna nastavení testu](/uploads/ps-test-edit.png 'Změna nastavení testu')

Některé domény se vám zde už nejspíš přidaly automaticky, z vložených URL stránek. V rámci testu můžete sledovat rychlost až pěti domén.

Vložit si domény do testu se hodí pro tři situace:

1. Web má své subdomény. Google totiž hodnotí rychlost každé subdomény zvlášť.
2. Vlastníte více webů stejného typu, např. jazykových mutací.
3. Kromě tohoto webu chcete sledovat také konkurenci.

Už jsme skoro v cíli. Kroky 2 - 4 můžete opakovat i s dalšími weby, které chcete sledovat a naplnit si tak dashboard, stejně jako jej máme naplněný my [našimi klienty](https://www.pagespeed.cz/reference).

## Krok 5: Sledujte rychlost na dashboardu a v e-mailových reportech

Nyní při každé návštěvě uvidíte aktuální stav metrik Web Vitals (3) pro všechny domény (2) z vašich testů (1):

![Sledování rychlosti na dashboardu a v e-mailových reportech](/uploads/ps-my-dashboard.png 'Sledování rychlosti na dashboardu a v e-mailových reportech')

Je dobré vědět dvě věci:

- Google tyto data dává světu k dispozici kumulativně za posledních 28 dní, takže je možné, že změny zde uvidíte až za několik dní. Nicméně jsou to ta „správná“ data, podle kterých algoritmy Googlu hodnotí rychlost vašich domén v rámci [signálů Page Experience](https://www.vzhurudolu.cz/prirucka/google-page-experience).
- U některých webů se může stát, že data nedostanete. Obvykle je to kvůli nižší návštěvnosti. S tím se bohužel nedá nic dělat, ale Google v takovém případě rychlost webu v hodnocení nezohledňuje.

Jak jsme uváděli na začátku, jednou měsíčně od nás dostanete e-mailový report ke každému týmu (respektive dashboardu), jehož jste členy. Uvidíte v nich, co se za poslední měsíc změnilo a co ne. Tyto e-maily si samozřejmě můžete odhlásit.

Věřím, že vám budou novinky v testeru i v rozesílaných e-mailech sloužit stejně dobře, jako slouží nám. Neváhejte se ale [ozvat](https://www.pagespeed.cz/contacts), pokud máte na srdci nápad na zlepšení.

<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: Pokud vás zajímají novinky kolem rychlosti a nechcete sledovat své weby, nově posíláme i <a href="https://www.pagespeed.cz/#email">samostatný newsletter</a> s aktuálním děním.</p></div></div>


Na letošním WebExpu nemohla chybět výprava PageSpeed.cz, navíc si náš Michal Matuška střihl v angličtině přednášku na téma „Optimising Core Web Vitals With Web Fonts”.

## Jak zoptimalizovat Core Web Vitals pomocí webových fontů?

Michal se ve [své přednášce](https://slideslive.com/38984452) snaží rozebrat zásadní témata okolo webových fontů:

* Proč jsou webové fonty tak důležité?
* Co jsou Core Web Vitals a jak je webové fonty ovlivňují?
* Doporučení a „best practices” okolo webových fontů, např. proč používat raději webové fonty na vlastní doméně, nebo jak optimalizovat subsetting pro jednotlivé jazyky a mnoho dalšího.

<div class="video"><div class="video__holder"><iframe src="https://slideslive.com/embed/presentation/38984452" width="610" height="343" 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 přednášce následovala [diskuze](https://slideslive.com/38984404), kde Michala doprovodil Martin Michálek. Spolu debatovali o současných tématech webové performance, např.:

* Největší problémy, které aktuálně v performance řešíme
* Jak měříme rychlost webu
* Co znamená zkratka INP a jak nás tato metrika v budoucnu ovlivní
* Rozdíl mezi měřením v Lighthouse a daty z CrUX

<div class="video"><div class="video__holder"><iframe src="https://slideslive.com/embed/presentation/38984404" width="610" height="343![](/uploads/webexpo-2022-11-06-2022-lucerna-lucerna-cinema-photo-petr-lebeda-_-66.jpg)![](/uploads/webexpo-2022-11-06-2022-lucerna-lucerna-cinema-photo-petr-lebeda-_-66.jpg)" 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>

![](/uploads/webexpo-2022-11-06-2022-lucerna-lucerna-cinema-photo-petr-lebeda-_-50.jpeg "photo @Petr Lebeda")

Měření rychlosti webu je vcelku ošidná záležitost, která se navíc poměrně dost mění, vezměme třeba nedávné zavedení hodnocení Googlu jménem Page Experience.

Lidé, kteří se oboru „web performance“ nevěnují naplno – jako jsou marketéři, manažeři nebo designéři – se často nachytají kvůli použití nevhodných nástrojů v nevhodných fázích měření.

7\. dubna jsem měl možnost o tomto povídat na konferenci [SEO Restart](https://www.seorestart.cz/). V následujícím textu vám předám hlavní myšlenku – ukázat co nejjednodušší postup získání dat o rychlosti a doporučený způsob jejich předání vývojářům.

Budu tady ukazovat screenshoty z našeho [testeru rychlosti verze 3.0](https://www.pagespeed.cz/blog/pagespeed.cz-tester-verze-3), který jsme nedávno rozšířili o uživatelské účty a možnost sledovat v dashboardu více webů svých klientů, a to i se svými kolegy.

Jako ukázkový web jsem si vzal doménu Mall.cz, který sice mezi naše klienty nepatří, ale je zajímavý svou velikostí a různorodostí typových stránek. Veřejný test rychlosti Mallu můžete na [pagespeed.cz/app/r/73f8e7b84404](https://pagespeed.cz/app/r/73f8e7b84404).

## **Cyklus práce na rychlosti webu**

Musíme začít poněkud zeširoka, obecným procesem práce na rychlosti.

![](/uploads/mereni-seo-restart_16-9-002.jpeg)

Google [definuje proces](https://web.dev/vitals-tools/) ve svých materiálech jako tříkrokový. Nejprve sbíráme data, pak optimalizujeme a nakonec ještě monitorujeme, protože už pár týdnů po optimalizacích se zpravidla zase něco pokazí.

Dovolím si ten proces zjednodušit do dvou kroků:

1. Optimalizace (obvykle řeší vývojáři).
2. Data a monitoring (jinak též sběr dat v čase – mohou řešit vývojáři, ale zpravidla to mívá na starost někdo analytický, kdo projekt vidí více netechnicky a „shora“).

V rámci [služeb týmu PageSpeed.cz](https://www.pagespeed.cz/services) pracujeme na pomezí obou – hlídáme data a zároveň vývojářům dodáváme konkrétní optimalizační příležitosti.

## **Google Page Experience a stránky, skupiny, domény**

Pro neznalé zopakuji, že rychlost webu je hodnocena metrikami [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals) v rámci skupiny signálů hodnocení, které lidé v Googlu pojmenovali [Page Experience](https://www.vzhurudolu.cz/prirucka/google-page-experience).

Jedná se o data z [Chrome UX Reportu](https://www.vzhurudolu.cz/prirucka/chrome-ux-report) (CrUX), tedy od konkrétních uživatelů vašeho webu, nikoliv například o data z testů nástrojem Lighthouse nebo PageSpeed Insights.

<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>Mimochodem – <a href="https://www.vzhurudolu.cz/prirucka/metrika-lps">Lighthouse score</a> by vás zase tak zajímat nemělo. Je to jen orientační číslo, bez vazby na vaše uživatele a z pohledu laiků spíše zavádějící.</p></div></div>

Data od uživatelů, které potřebujete, uvidíte například v Google Search Console:

![Tady je něco špatně. Ukázka ze Search Console u webu, jenž na některých URL adresách Web Vitals nesplňuje.](/uploads/mereni-seo-restart_16-9-003.jpeg 'Tady je něco špatně. Ukázka ze Search Console u webu, jenž na některých URL adresách Web Vitals nesplňuje.')

Pro proces zmíněný v článku je klíčové, abychom věděli, že existují tři stupně hodnocení Web Vitals:

- **Konkrétní URL** – nejnavštěvovanější adresy mají vlastní hodnocení.
- **Skupina stránek** – pokud nemá URL vlastní data Core Web Vitals, Google pro hodnocení použije skupinu. Např. u e-shopu to může být skupina s detailem produktu.
- **Doména** – pokud URL nemá vlastní hodnocení ani nepatří do skupiny, použije Google pro její hodnocení data pro celou doménu.

Ve všech případech Google započítává 75. percentil hodnot metrik Core Web Vitals všech návštěv za posledních 28 dní kumulativně. Jsou to data, která pak vidíte ve všech nástrojích, která využívají CrUX jako zdroj dat, tedy i v našem testeru na [app.pagespeed.cz](https://app.pagespeed.cz/).

![Stránka? Skupina? Doména? Pro různá URL používá Google při hodnocení rychlosti různé zařazení.](/uploads/mereni-seo-restart_16-9-004.jpeg 'Stránka? Skupina? Doména? Pro různá URL používá Google při hodnocení rychlosti různé zařazení.')

Původně jsem si myslel, že skoro každé URL je zařazeno alespoň ve skupině stránek, ale realita bude nejspíš jiná.

U našich klientů vidím, že hodnocení pro URL má vždy maximálně jen několik desítek adres, u méně navštěvovaných webů spíše jednotky. Hodnocení pro skupinu, které je možné vidět jen v Search Console, má u našich klientů zhruba jen polovina URL.

Existují i extrémy, velké weby jako [Livesport.cz](https://www.livesport.cz/), u kterých **může až 90 % URL přebírat hodnocení domény**. Soudím tak podle rozdílu mezi celkovým množstvím URL, které Google zná, a množství URL zařazených do skupin stránek v reportech Web Vitals v rámci Google Search Console.

<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>Co z toho vyplývá? Možná trochu nepříjemná věc – optimalizovat hodnoty Web Vitals byste ideálně měli jak pro celou doménu, tak pro skupiny stránek, ale nakonec i pro jednotlivá navštěvovaná URL.</p></div></div>

## **První krok: měření domény**

Při měření rychlosti začínáme vždy pohledem na data pro celou doménu. Je to nejjednodušší (i když trošku zjednodušené) vyjádření stavu rychlosti webu.

Můžete se samozřejmě podívat do [PageSpeed Insights](https://pagespeed.web.dev/report?url=https%3A%2F%2Fmall.cz%2F) a tam stav Web Vitals pro doménu uvidíte:

![Rychlost mall.cz podle PageSpeed Insights. Core Web Vitals jsou označeny modrou ikonou. Tady to ještě vypadá dobře.](/uploads/mereni-seo-restart_16-9-005.jpeg 'Rychlost mall.cz podle PageSpeed Insights. Core Web Vitals jsou označeny modrou ikonou. Tady to ještě vypadá dobře.')

Už z těchto čísel a grafů vidíme onu metriku, kterou je potřeba optimalizovat nejvíc. U mall.cz se jedná o CLS ([Cumulative Layout Shift](https://www.vzhurudolu.cz/prirucka/metrika-cls)).

PageSpeed Insights ukazují správná data, tedy hodnoty metrik pro uživatele kumulativně za měsíc z Chrome UX Reportu. Ale problém je v tom, že zde nevidíme vývoj oproti předchozímu období a že zde nemůžeme vidět více domén najednou.

Proto jsme v našem testeru přišli [s dashboardem](https://app.pagespeed.cz/dashboard), ve kterém po přihlášení můžete sledovat čísla například všech webů vašich klientů:

![Dashboard na PageSpeed.cz ukazuje nejen sledované domény, ale také pohyb čísel.](/uploads/mereni-seo-restart_16-9-006.jpeg 'Dashboard na PageSpeed.cz ukazuje nejen sledované domény, ale také pohyb čísel.')

Na obrázku výše je vidět, že na mobilu doména mall.cz nejenže CLS nesplňuje (hodnota je 0,13), ale za poslední měsíc se také zhoršila.

Víme tedy, co je špatně a pokud čísla pravidelně sledujeme, dozvíme se také, zda se v nedávné době změnila. Co když se ale k měření rychlosti dostaneme jen jednou za několik měsíců?

Tady se nám pak může hodit další vlastnost našeho testeru – měsíční data z Chrome UX Reportu:

![Vývoj hodnot metrik Web Vitals pro dvě domény pod mall.cz.](/uploads/mereni-seo-restart_16-9-007.jpeg 'Vývoj hodnot metrik Web Vitals pro dvě domény pod mall.cz.')

Google tato čísla dává k dispozici se zpožděním a mají trošku jiné hodnoty než data za posledních 28 dní, podle kterých hodnotí stránky. Ale jsou skvělá v tom, že ukazují vývoj rychlosti a tudíž vliv optimalizací nebo, ehm, neoptimálního vývoje.

V grafu výše je vidět, že mall.cz měl ještě před rokem velmi špatné hodnoty metrik [LCP](https://www.vzhurudolu.cz/prirucka/metrika-lcp) i CLS, ale nyní je stav výrazně lepší. „Zelená“ hodnota CLS v březnu pak potvrzuje, že ještě nedávno byla tato metrika na mobilu pro celou doménu mall.cz v pořádku.

Pravděpodobně se tedy s Cumulative Layout Shift na mobilu něco nehezkého stalo až v posledním měsíci.

S touto znalostí stavu metrik pro doménu bychom se mohli spokojit, ale ještě vám doporučím jeden pohled z nepostradatelné Google Search Console.

![Google Search Console: z nuly na sto za jeden den.](/uploads/mereni-seo-restart_16-9-008.jpeg 'Google Search Console: z nuly na sto za jeden den.')

Search Console v části Page Experience ukazuje graf s počtem URL, které splňují signály hodnocení této oblasti. Tedy kromě rychlosti také použitelnost na mobilu nebo úroveň zabezpečení, což je ono nedávno v SEO komunitě „hajpované“ [HTTPS](https://www.vzhurudolu.cz/prirucka/https).

V případě grafu výše došlo u klienta ke zlepšení díky našim optimalizacím a během jednoho dne tedy hodnoty vyskočily z nuly na sto procent. Museli byste ale mít štěstí, abyste takový graf viděli. Většinou je daleko více „kostrbatější“, hodnoty se v čase dost mění.

Tento graf navíc silně podléhá různým zkreslením – jak z pohledu zpoždění dat, tak z pohledu různých bugů na straně Googlu. Proto si z něj bereme hlavně dlouhodobý vývoj a při kolísání ze dne na den nepodléháme panice.

Zopakujme si, co víme: Doména mall.cz má na mobilu i desktopu špatnou hodnotu metriky CLS. Na mobilu navíc došlo k jejímu výraznému zhoršení v posledním měsíci.

## **Krok druhý: skupiny stránek**

V této fázi měření se prakticky neobejdeme bez Search Console. Google totiž tato data neposkytuje ven v rámci svého API. Doufám, že to platí jen prozatím a brzy s nimi bude možné rozumně pracovat i zvenčí.

Každopádně to, co vám tady teď budu ukazovat, je viditelné v části Web Vitals. Jsou tam k dispozici reporty rozdělené pro mobil a desktop. A všechny se týkají právě skupin stránek, tak jak si je interně rozdělil Google.

V prvním kroku vidíme poněkud matoucí graf se žlutou, oranžovou a zelenou linkou:

![Google Search Console: zvyšuje se žlutá, je čas na paniku?](/uploads/mereni-seo-restart_16-9-009.jpeg 'Google Search Console: zvyšuje se žlutá, je čas na paniku?')

Problém s tímto grafem je, že neukazuje vývoj rychlosti webu, ale pouze počet URL ve skupinách, které splňují všechny metriky (zelené) nebo mají minimálně jednu oranžovou a nebo minimálně jednu červenou.

Vzhledem k tomu, že jde o počet URL, grafy mohou vypadat jako zhoršující se, i když například přibývá adres, které jsou zařazené v některé skupině URL. Ve skutečnosti se ovšem nic nezhoršuje, jen se zvyšuje počet stránek.

**Špatné ale je, pokud zde v nějaký moment ubývá zelené a přibývá oranžové nebo červené.** To už by mohl být důvod pro vaši starost o rychlost.

Opět samozřejmě i u těchto grafů platí, že jsou zde různá zkreslení, zpoždění a kdoví co ještě… Prostě je dobré mít ještě nějaká jiná pravidelná měření, která vám ověří, zda opravdu došlo ke skokové změně.

Když si graf rozkliknete, vidíte už rozpis pro konkrétní zařízení a konkrétní metriky:

![Google Search Console: „Houstone, slyšíte mě? Roste nám oranžová v LCP!“](/uploads/mereni-seo-restart_16-9-010.jpeg 'Google Search Console: „Houstone, slyšíte mě? Roste nám oranžová v LCP!“')

Tenhle graf nám ukáže, které metriky jsou na doméně ve skupinách problematické a jakého množství URL se to dotýká.

V případě tohoto konkrétního grafu je to metrika LCP a oranžové hodnoty (2,5 – 4 s). Pokud bychom měli přístupy do Search Console na Mall.cz, nejspíš bychom zde viděli potíže hlavně s CLS.

I tento report můžete ještě dále rozkliknout, než narazíte na jádro pudla, a to sice seznam skupin URL, které tuto hodnotu metriky mají:

![Google Search Console: seznam skupin URL. Našli jsme viníky.](/uploads/mereni-seo-restart_16-9-011.jpeg 'Google Search Console: seznam skupin URL. Našli jsme viníky.')

V obrázku výše jsem schoval konkrétní URL adresy, ale vy si je tam jistě umíte představit.

Tohle je výborný report, protože nám kromě skupin stránek prozrazuje také jejich četnost a „agregovanou hodnotu metriky“. **Čím více je skupina zastoupená a čím horší má hodnotu metriky, tím důležitější je její optimalizace.**

Google Search Console zde také uvádí mnoho příkladů URL, takže si je můžeme rovnou vzít a zkusit otestovat v prohlížeči nebo nastavit do pravidelného monitoringu, což uděláme hned v dalším kroku.

V druhém kroku jsme tedy zjistili, které skupiny stránek mají největší vliv na špatnou metriku (v případě Mall.cz by to bylo CLS) a tudíž jejich optimalizace je prioritní.

## **Krok třetí: konkrétní URL**

Výběr správných URL, které monitorujete, je klíčový pro úspěch celého měření rychlosti. Mám pro vás pár tipů:

- Najděte typové stránky, které jsou pro vás klíčové a reprezentují důležitý obsah. Např. na e-shopu to může být homepage, detail produktu, kategorie, blogpost a třeba kontaktní stránka.
- Vyberte zástupce z častých skupin adres, které vám nabízí Search Console.
- Zvolte URL, které mají z této skupiny nejvyšší návštěvnost.
- Vyberte ideálně stránky s vlastním hodnocením Web Vitals v CrUX.

Náš tester umožňuje vložit až pět URL, což by mělo stačit i pro větší weby. V případě Mall.cz půjde samozřejmě trochu o střelbu od pasu (nemáme totiž všechna data), ale vybrali jsme tyto stránky:

![Tester na PageSpeed.cz ukazuje problémové stránky.](/uploads/mereni-seo-restart_16-9-012.jpeg 'Tester na PageSpeed.cz ukazuje problémové stránky.')

Na obrázku z testu vidíme, že problematické CLS je zejména v kategorii (/mobilni-telefony) a pak na stránce /akce. Špatnou hodnotu vidíme také na homepage, ale ta je jen jedna, takže na hodnocení domény nebude mít takový vliv. Optimalizovat ji sice musíme, ale nikoliv prioritně.

### **Pravidelný monitoring**

Když už máme v testeru takhle nasázené adresy, budou se pravidelně měřit, v našem případě jednou denně. Je to služba, kterou poskytujeme zdarma, takže jí neváhejte využít.

Graf každodenního monitoringu vypadá nějak takto:

![Rychlost se vám může pokazit kdykoliv. Tester PageSpeed.cz vám ukáže, kdy se to stalo.](/uploads/mereni-seo-restart_16-9-013.jpeg 'Rychlost se vám může pokazit kdykoliv. Tester PageSpeed.cz vám ukáže, kdy se to stalo.')

V grafu je vidět, že se u klienta na jedné ze stránek zhoršila metrika LCP. Stalo se to začátkem února a my se tak můžeme snadněji dopátrat příčině. (V tomto případě zlobí [cookie lišta](https://www.pagespeed.cz/blog/cookie-rychlost-webu).)

Takže kromě dlouhodobého pohledu na domény a skupiny stránek nyní každodenně monitorujeme konkrétní URL. Umíme se tak dopátrat k problematickým metrikám, ale také k datu jejich skokových změn k horšímu, tudíž k pravděpodobné příčině.

## **Výstup z měření webu**

Máme teď naměřenu doménu, skupiny stránek, ale také konkrétní URL. Vývojářům tedy můžete pro optimalizaci dodat tento velmi stručný výstup:

> _Na doméně mall.cz je problematická metrika CLS:_  
> _V CrUX jsou hodnoty pro mobil 0,13, pro desktop 0,26._
>
> _Nejdůležitější skupiny k optimalizaci a příklady v URL jsou tyto:_  
> _…_
>
> _Odkazy na měření:  
> Search Console: …  
> PageSpeed.cz: …  
> PageSpeed Insight: …_

Ano, takhle jednoduché by to mohlo být.

Teď už jen vymyslet, jak to opravit, že…

## **Mají se marketéři pokoušet poskytovat doporučení vývojářům?**

Myslím si, že většina marketérů dobře rozumí datům a jejich interpretaci, ale nemají tak hluboké znalosti fungování prohlížeče nebo různých frontendových technologií.

Existují sice obecné rady, které dává např. Lighthouse nebo také PageSpeed Insights, ale ty mohou dobře fungovat jen u některých webů, obvykle u těch, které nejsou dobře optimalizované.

![Rady Lighthouse: věříte jim? My zase tak moc ne.](/uploads/mereni-seo-restart_16-9-014.jpeg 'Rady Lighthouse: věříte jim? My zase tak moc ne.')

Je nutné si uvědomit, že **Lighthouse nezná lidský a technologický kontext vašeho projektu, takže určité rady mohou střílet úplně vedle**.

Z naší zkušenosti pak také platí, že rady Lighthouse bývají velmi náročné na implementaci. Cílem optimalizace by mělo být hledat „nízko visící jablíčka“, čili úpravy, které za málo peněz přinesou největší efekt.

Takové úpravy by měli umět najít vývojáři, kteří na projektu pracují. Stále častěji se nám však u klientů ukazuje, že i schopnost kvalitního a efektivního vývoje a schopnost optimalizací rychlosti se téměř vylučují.

Samozřejmě můžete mít štěstí a vaši vývojáři se o performance starají úplně sami (známe takové!) nebo můžete mít ještě větší štěstí a tyto znalosti má váš marketér, designér nebo product manager (i takové známe).

V opačném případě se [prostě ozvěte](https://www.pagespeed.cz/contacts), rádi vám s tím pomůžeme. ;)


Pod hlavičkou projektu PageSpeed.cz mám za sebou již desítky [auditů rychlosti](https://pagespeed.cz/audit) a menších analýz pro různě velké weby. Rozhodla jsem se proto všechny analýzy projít a nalézt nejčastější chyby, které se v našich auditech opakují, a které kazí metriky Core Web Vitals.

Na záznam přednášky se můžete podívat na YT kanále Frontendisti. Pokud dáváte přednost psané formě, začtěte se do dnešního článku níže.

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

## Obsah

- [Web Vitals v kostce](#web-vitals-v-kostce)
- [Jak změřit rychlost vašeho webu?](#jak-změřit-rychlost-webu)
- [FID - javascriptová metrika, kterou skoro není potřeba optimalizovat](#fid---first-input-delay)
- [LCP - asi nejdůležitější a moje oblíbená metrika](#lcp---largest-contentful-paint)
- [CLS - metrika plná nedorozumění](#cls---cumulative-layout-shift)

## Web Vitals v kostce

Rychlost webu je stále větší a složitější téma, ve kterém se dá lehce ztratit. No a navíc jsou tady ty Web Vitals. Co to je a proč bychom to měli řešit?

Web Vitals jsou metriky od Google, které se mají stát jedním z hodnotících kritérií pro řazení výsledků vyhledávání. Další podrobnosti ohledně Google Page Experience vydají na samostatný článek, proto vás v případě, že si chcete o tomto updatu něco přečíst, [odkážu na blogpost o Google Page Experience](https://www.vzhurudolu.cz/prirucka/google-page-experience) Martina Michálka.

Nyní rychlý pohled na Web Vitals. Základní metriky jsou tři, First Input Delay (FID), Largest Contentful Paint (LCP) a Cumulative Layout Shift (CLS). Všechny metriky mají doporučené hodnoty, které vidíte na obrázku.

![](/uploads/chyby-kterekaziwebvitals4-002.jpeg ' ')

Ale pořád ještě nevíme, jak si Web Vitals změřit.

## Jak změřit rychlost webu?

Možností je mnoho. Jedním z nástrojů je třeba [Google Data Studio](https://datastudio.google.com/u/0/navigation/reporting), ve kterém si můžete vytvořit přehledy s výsledky jednotlivých metrik. Bohužel práce s Data Studiem bývá často složitá a zdlouhavá.

Web Vitals dokáže zobrazit také [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=cs), ale tam jsou zase hodně omezená a zjednodušená data. V PageSpeed.cz jsme proto s kolegy přišli s [updatem testeru 2.0](https://pagespeed.cz/blog/pagespeed-verze-2), který (nejen) tento problém řeší. Výsledkem je tak po zadání dané adresy kompletní přehled uživatelských dat - jednoduše a přehledně.

![](/uploads/chyby-kterekaziwebvitals5-039.jpeg '  ')

Pokud jste zrovna zadali do testeru adresy vašich webů a výsledky se vám nelíbí, mám pro vás dobrou zprávu. Spousta chyb se opakuje téměř na každém webu, tak se pojďte se mnou podívat, co byste měli hledat.

## FID - First Input Delay

Na začátek si dejme metriku First Input Delay. Jak název vůbec nenapovídá, jedná se o javascriptovou záležitost, která měří čas od první interakce uživatele se stránkou až po zpracování interakce prohlížečem.

FID jsme zatím nemuseli nějak zásadně řešit, jelikož se jeví jako málo přísná metrika. Její limit pro dobré hodnocení je 100 ms, což se webům daří plnit.

Velmi podobná JS metrika je Total Blocking Time (TBT), u které Google poukazuje na souvislost s FID. Z praxe se nám ale nepotvrdilo, že by špatný TBT znamenal špatné skóre FID. Pokud ale **vyladíte TBT, často posunete kupředu také metriku FID**.

Jeden příklad pokažených javascriptových metrik za všechno. Na první polovině screenu níže je výsledek měření stránky, na kterém řádí YouTube video v iframe, známý zabiják metrik TBT a Time to Interactive (TTI). Metriky jsou tak vysoké, protože YouTube stahuje velké CSS a JS soubory.

![](/uploads/chyby-kterekaziwebvitals4-007.jpg ' ')

**Řešení** pro lepší metriky? Pro YT vkládaný přes iframe buďto využijte nativní [lazyloading](https://docs.pagespeed.cz/docs/lazyload#lazyloading-pro-iframe) nebo [Youtube Lite Embed](https://github.com/paulirish/lite-youtube-embed).

## LCP - Largest Contentful Paint

Moje nejoblíbenější metrika, to je Largest Contentful Paint. Nejoblíbenější proto, že je komplexní. Abyste ji zoptimalizovali, je potřeba zmáknout hodně oblastí během načítání. Umí solidně prověřit znalosti kodérů v procesu načítání webu a můžeme díky ní změřit vykreslení největšího prvku na stránce.

Při ladění LCP je nejdůležitější nejprve identifikovat LCP prvky. Pro mobil a desktop bývají často odlišné. Spolehlivě vaše LCP prvky zjistíte za použití [Lighthouse](https://developers.google.com/web/tools/lighthouse), [PageSpeed Insight ](https://developers.google.com/speed/pagespeed/insights/?hl=cs)nebo na [detailu testu](/app/r/af6ccefcabac/opportunities?publicHash=d74f610fa5dd) v našem nástroji PageSpeed.cz.

![](/uploads/snimek-obrazovky-2021-06-07-v-23-30-18.png ' ')

### LCP a lazy loading

Naprostá většina webů škodí své metrice LCP špatně implementovaným lazy loadingem. Je zásadní uvědomit si, že lazy loading změní pořadí stahování obrázků.

Hodně častou chybou je lazy loading nasazený jenom na velké obrázky na stránce. Ano, z logiky věci vyplývá, že odložit načtení největších obrázků nám ušetří nejvíce dat, ale v **případě LCP prvku vám to podkopne nohy**.

Pravidlo je takové, že obrázky bez lazy loadingu se stahují jako první. Obrázky s lazy loadingem až posléze, i když jsou ve viewportu. Pokud máte lazy loading na obrázku, který je zároveň jako LCP element, tak ten se stáhne o dost později, což navyšuje čas LCP.

![](/uploads/chyby-kterekaziwebvitals4-013.jpg ' ')

Na řešení jste již určitě během čtení přišli sami, z LCP prvků na vašem webu odstraňte lazy loading a na všechny ostatní prvky lazy loading naopak přidejte.

### LCP a složitý DOM

Špatná zpráva hned na začátek, toto většinou zabere při optimalizaci hodně času. Na druhou stranu vám poradím hotfix, než se dostanete k větším úpravám v kódu.

Zde problém vzniká většinou už v designu, kde je velký rozdíl mezi desktopovou a mobilní verzí. To musíte samozřejmě vyřešit, často skrýváním prvků na mobilu.

![](/uploads/chyby-kterekaziwebvitals4-018.jpeg 'Analýza LCP prvků odhalila rozdílné oblasti pro mobil a desktop.')

![](/uploads/chyby-kterekaziwebvitals4-019.jpeg 'Mobilní verze je ale dost odlišná.')

![](/uploads/chyby-kterekaziwebvitals4-020.jpeg 'Pro vizualizaci jsme tmavě modrou označila vše, co je na mobilu skryté.')

Tmavě modrá plocha je docela rozsáhlá, že? Tohle vám zatočí s metrikou LCP. Je důležité zmínit, že by to tak nevadilo, pokud bychom se bavili o jednoduchých DOM textových elementech. Tady je ale problém se spoustou obrázků, které se budou stahovat i když nejsou vidět.

Řešení je vícero. Pokud máte čas a prostor, přepište HTML tak, aby reflektoval LCP prvky. Můžete také použít preload na obrázek, který se vyhodnotil jako LCP na mobilu.

    <link rel="preload" as="image" href="image.jpg">

S preloadem ale velmi opatrně, obzvlášť, pokud už nějaké jiné preloady na stránce máte. Využít můžete také loading=”lazy”, protože obrázky ve skrytých elementech s tímto atributem se stahovat nebudou.

### LCP a obrázky z WYSIWYGU

Práce s obrázky v editoru je potřeba kontrolovat. Spousta e-shopů pod svou doménou píše blog, který také může kazit metriky a často se tak skutečně děje. Nechci kopat do vývojářů a kodérů, ale to, co nahraje uživatel přes WYSIWYG, **je také váš problém.** I zde je potřeba vyřešit velikosti, komprimace, vhodné formáty a srcsety.

![](/uploads/chyby-kterekaziwebvitals4-023.jpg ' ')

## CLS - Cumulative Layout Shift

Cumulative Layout Shift je metrika zabývající se posunem a poskakováním layoutu stránky. Kritické nejsou jenom layout shifty během načítání, to vám změří syntetické nástroje, řešit musíte také layout shifty během procházení stránek. To zjistíte pohledem do uživatelských dat Chrome UX reportu.

Jak takový CLS otestovat? Ideálně přes doplněk do Chrome, který se jmenuje [Web Vitals](https://chrome.google.com/webstore/detail/core-web-vitals/adeniimnihmbpgpbljmnohjpoolmgabj), nebo v samotném chrome v záložce rendering je zatržítko „Core Web Vitals”.

### CLS a atributy width a height

Co se týká CLS, na každém webu připomínkujeme chybějící [atributy width a height](https://docs.pagespeed.cz/docs/cls-img-width-height) na obrázkovém tagu. Často je to chyba z nedůslednosti, takže je potřeba vyhledat všechny obrázky na projektu a zkontrolovat chybějící atributy.

    <img src=”image.jpg” alt=”img” width=”150” height=”200”>

Dalším řešením poskakování nejen obrázků, ale i jiných obsahových elementů bude v budoucnu CSS vlastnost [aspect-ratio](https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-ratio). Jedním řádkem kódu vyřešíte prostor, který má element pro svůj obsah rezervovat.

    .box {
    	aspect-ratio: 4/3;
        background: grey;
    }

Pokud potřebujete neprůstřelné řešení hned, doporučujeme [padding-top trik](https://www.vzhurudolu.cz/prirucka/padding-trik).

### CLS a carousely (například)

Cumulative layout shift vám mohou zhoršovat nejenom carousely, ale jakékoliv inicializace obsahu pomocí javascriptu. Často jde o různé kvízy, kalkulačky, widgety atd.

Všeobecně přichází inicializace javascriptu v čase velmi pozdě, a proto CLS stoupá. Není dobré řešit pomocí javascriptu věci, které můžeme ostylovat v CSS. Typicky to bývají šířky jednotlivých položek v carouselu.

![](/uploads/chyby-kterekaziwebvitals4-031.jpg ' ')

Řešte proto šířky a výšky elementů v CSS, testuje si web s vypnutým javascriptem. To vše vám pomůže odhalit, kde jsou na webu slabá místa. Pomoci vám může například doplněk do Chrome [Web Developer](https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm), ve kterém se dají vypnout javascript jednoduše jedním kliknutím.

### CLS a AJAX

![](/uploads/chyby-kterekaziwebvitals4-034.jpeg ' ')

Metrika CLS se nepočítá jenom v okamžiku načtení stránky, ale také během procházení stránky uživatelem. Pokud se uživatel na webu rozhodne například načíst „Dalších 24 produktů”, tak po kliknutí máte interval 0,5 vteřiny na zobrazení obsahu bez dalšího zvýšení CLS.

Instrukce jsou pro takovou situaci následující: Testujte si pomalé sítě a načítejte obsah odloženě v době, kdy se prohlížeč „nudí” pomocí RequestIdleCallback();.

## Pár slov na závěr

Pokud jste v oblasti rychlosti webů krátce a zasypala jsem vás hromadou nových informací, nezoufejte. Nejprve si běžte udělat kávu a pak se zaměřte na sběr dat a testování. Zajímat by vás měla nejen uživatelská data Web Vitals, ale také syntetická měření. Vše ideálně v kontextu několika měsíců.

![](/uploads/chyby-kterekaziwebvitals5-038.jpeg '  ')

Co se týká syntetiky, Lighthouse vyšel [ve verzi 8](https://www.vzhurudolu.cz/blog/199-lighthouse-8), došlo zde například k úpravě výpočtu samotného skóre. Například metriky TBT a LCP dohromady tvoří 55 % váhy v celkovém výpočtu. To samo napovídá, na jaké metriky byste se měli zaměřit.

Nakonec bych chtěla předat všem vývojářům a vývojářkám dost chuti a zvědavosti pochopit, jak prohlížeč [doopravy funguje](https://www.youtube.com/watch?v=TAyp19NBLdA&ab_channel=Frontendisti). Zaměřte se na [DevTools a Performance tab](https://www.vzhurudolu.cz/kurzy/webinar-devtools-rychlost) k optimalizacím, přemýšlejte komplexně a snažte se přijít na to, jak se jednotlivé věci na webu navzájem ovlivňují. Na Vzhůru dolů se také můžete naučit optimalizovat obě problematické metriky – [CLS](https://www.vzhurudolu.cz/kurzy/webinar-cls) i [LCP](https://www.vzhurudolu.cz/kurzy/webinar-lcp).

## **Diskuze**

Po přednášce následovala také moderovaná diskuze, kde jsem spolu s Michalem Matuškou odpovídala na dotazy z publika.

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


Blog

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

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

Rychlost webu: 12 novinek roku 2022

Zpátky v plném výkonu: konference Perf.now() 2022

Monitoring rychlosti webů s PageSpeed.cz (tutoriál)

Stopa PageSpeed.cz na WebExpo 2022

Měření rychlosti webu pro marketéry krok za krokem

Nejčastější chyby, které kazí Web Vitals