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 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](https://app.pagespeed.cz/report/10936682?hash=47231d379788) 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://www.vzhurudolu.cz/prirucka/img-pomer-stran) 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://www.vzhurudolu.cz/prirucka/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>

Host našeho rozhovoru [Filip Podstavec](https://twitter.com/filippodstavec) je ve světě marketingu a SEO poměrně známá osoba. Zabývá se především technickým SEO, data miningem a je také provozovatel [Marketing Mineru](https://www.marketingminer.com/cs).

Co se řešilo?

* co je Marketing Miner, jaké má využití a jestli řeší také rychlost načítání webů
* vztah markeťáků a rychlosti
* jak velký má rychlost webu vliv na pozice v Google

Celý rozhovor s Filipem si můžete pustit níže:

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

Tentokrát nahlédneme do světa Next.js a zhodnotíme si HTTP/3. Ve Woltu vymysleli plugin s názvem BlurHash, tak si rozebereme, k čemu je to dobré a do diářů si na příští rok vyznačíme červeně měsíc květen.

## Next.js conf

Na Next.js konferenci byla představena nová 10 verze tohoto populáního React frameworku, který přináší několik zajímavých novinek. První z nich jsou [vlastní performance metriky](https://nextjs.org/analytics), souhrnně nazývané jako RES - real experience score.

![](/uploads/yourtruelighthouse-001.jpeg "    ")

Druhou zásadní novinkou je [Image komponenta](https://nextjs.org/docs/basic-features/image-optimization), která má řešit všechny běžné neduhy s obrázky spojené. Na druhou stranu je vývojáři kritizována, že jde o “black box” bez kontroly. Podrobněji vše rozebíráme ve videu níže.

## HTTP/3

Google implementoval již [třetí verzi protokolu](https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html) pohánějící naše weby. Zlepšit by se měla datová propustnost a latence. Naopak se upustilo od [prioritizace zdrojů](https://http3-explained.haxx.se/en/h3/h3-h2).

## BlurHash

Pokud vás stejně jako designéry z Woltu nebaví nudné šedé načítací plochy, můžete zkusit jejich nejnovější [plugin BlurHash](https://blurha.sh/). Na druhou stranu pozor na celkovou dobu času dekódování, kterou BlurHash spotřebuje.

## Core Web Vitals jako parametr pro výsledky vyhledávání

Květen 2021 bychom si měli pečlivě poznamenat do diářů. Google oznámil, že od tohoto data začne zahrnovat Core Web Vitals jako [parametr pro řazení výsledků vyhledávání](https://webmasters.googleblog.com/2020/11/timing-for-page-experience.html). Vývojářům tedy zbývá poslední půlrok rychlost webů vyladit.

Všechna témata jsme podrobně rozebrali na našem livestreamu Na rychlosti záleží, ze kterého přinášíme sestříhaný záznam.

<div class="video"><div class="video__holder"><iframe width="560" height="315" src="https://www.youtube.com/embed/Rlif-ARLy_o" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>![](/uploads/novinky-cover-2.jpg)</div></div>

Rozhovory, případové studie, živé ukázky nástrojů, detailní tipy, ale také novinky. A právě o novinkách, které jsme si ukázali v prvním díle je tento článek.

Cílem je dostat téma rychlosti webů mezi širší odbornou veřejnost a hlavně pomoci našim sledujícím dělat své weby rychlejší.

## První článek na našem blogu - proč mít rychlý web?

Přečtěte si [nejnovější článek ](https://pagespeed.cz/blog/proc-mit-rychly-web)od Martina Michálka, který shrnuje, proč je důležité mít rychlý web. Od psychologie, vlivu na konverze až po velmi často zmiňovaný Google.

![](/uploads/pagespeed_16-9-001.jpeg " ")

## PageSpeed.cz - aktualizace nástroje pro testování

Do našeho nástroje [pro testování webů](https://pagespeed.cz/) jsme přidali několik nových vlastností.

Výsledky syntetických testů jsou nyní podrobnější. Kromě Lighthouse performance score (LPS) se můžete nově podívat i na hodnoty jednotlivých metrik, se kterých se LPS počítá.

**![ ](/uploads/pagespeed_16-9-002.jpeg " ")**

Také výsledky z Chrome UX reportu se dočkaly aktualizace. Nově je možné sledovat **metriky v čase.** K tomu slouží nové grafy.

**![ ](/uploads/pagespeed_16-9-003.jpeg " ")**

[Změřte si svůj web](https://pagespeed.cz/) a omrkněte tyto novinky.

Detailně si vše brzy představíme v některém z dalších článků, kde odhalíme i možnost, jak si zobrazit detailní report z Lighthouse pro kterýkoliv den.

## Lighthouse Score for All

Pokud znáte [LPS](https://www.vzhurudolu.cz/prirucka/metrika-lps) jako jedno číslo, pak pro vás bude zajímavé [tohle video](https://www.youtube.com/watch?v=TT-2rQsHyqQ) z Jamstack Conf. Henri Helvetica ve své přednášce ukazuje, z čeho se LPS skládá a jak se počítá.

Na závěr pak přidává několik velmi zajímavých statistik.

## Glyphhanger - nástroj pro optimalizaci fontů

Blížíme se do finále. Dalším tipem je „utilitka“ [Glyphanger](https://github.com/filamentgroup/glyphhanger). Díky tomuto nástroji můžete rychle optimalizovat fonty ve vašem projektu. I se základním nastavením můžete dosáhnout uspokojivých výsledků.

A pokud jste fajnšmekři, můžete se pustit i do detailního nastavení a vymačkat optimalizaci na maximum. Pokud vás zajímá jak na to, navštivte webinář Michala Matušky [o variabilních fontech](https://www.vzhurudolu.cz/kurzy/webinar-variabilni-fonty).

## Označování rychlosti webu v mobilním Chrome

Pomyslná třešnička na dortu. Mobilní Chrome od verze 85 přidává badge s hodnocením rychlosti navštěvovaného webu. [V článku](https://speedcurve.com/blog/fast-badging-for-better-ux/), který o této novince píše, jsou pak zmíněné další koncepty, jak s tímto označením pracovat.

Líbí se vám tento nápad? My jsme se o tom společně chvíli bavili, udělali anketu mezi diváky a zjistili jsme, že je to věc, která minimálně teď vyvolává spoustu zajímavých otázek, názorů a rozporů.

<iframe src="https://www.facebook.com/plugins/video.php?href=https%3A%2F%2Fwww.facebook.com%2FPageSpeed.cz%2Fvideos%2F696614464290152%2F&t=510" width="100%" height="500" scrolling="no" frameBorder="0" allowTransparency allowFullScreen></iframe>

Budeme se snažit zde tvořit zajímavý obsah pro všechny lidi od webařského fochu – techniky, ale i netechniky.

## **O čem budeme psát?**

Můžete se těšit na následující typy obsahu:

1. Případové studie a zkušenosti z práce pro naše milé klienty.
2. Konkrétní optimalizační techniky a tipy, rozebrané do detailu.
3. Novinky z oblasti rychlosti webů, ale i vývoj kolem našeho [testovacího nástroje](https://pagespeed.cz/).

Na tvorbu obsahu jsme v týmu čtyři – Zuzana Šumlanská, Michal Matuška a Tomáš Hejč ze [SUPERKODERS](https://superkoders.com/) a Martin Michálek ze [Vzhůru dolů](https://www.vzhurudolu.cz/martin).

Začínáme zostra, článkem [Proč se zabývat rychlostí](https://pagespeed.cz/blog/proc-mit-rychly-web), který je přesně tak dlouhý, jak si tohle téma zaslouží.

Těšíme se, co nového společně s vámi objevíme a jaké weby spolu zrychlíme!

Tým PageSpeed.cz

PS: Zůstaňme v pravidelném kontaktu. Odebírejte nás na [Twitteru](https://twitter.com/pagespeedcz), [Facebooku](https://www.facebook.com/PageSpeed.cz) nebo [LinkedIn](https://www.linkedin.com/company/42805034/).

Blog

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

Checklist rychlosti webu 2021

Rozhovor s Filipem Podstavcem z Marketing Mineru

Tipy a novinky ze světa rychlosti vol. 2

Tipy a novinky ze světa rychlosti vol. 1

Začínáme s blogem. Na co se tady můžete těšit?