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

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

## 1) Nastavení: aliasy pro URL adresy

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

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

## 2) Nastavení: typ domény

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Drobnosti a&nbsp;opravy chyb

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

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

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

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


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

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

Známe dva hlavní způsoby komprese:

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

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

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

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

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

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

## Odhalení tajemství úrovní komprese

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`DeflateCompressionLevel 9`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Vybrané optimalizace rychlosti

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### Goldea: Optimalizace CLS

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 11) Back/Forward Cache v Chrome

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

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

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

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

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

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

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

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

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


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://app.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/kontakty), 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>


Best practice v době [HTTP/2](https://www.vzhurudolu.cz/prirucka/http-2) velí, abychom CSS dělili do menších souborů, podle komponent a stránek. Nebude ale cena za mnoho requestů příliš vysoká?

## Proč to řešit?

Pokud optimalizujeme web podle metrik Core Web Vitals, snažíme se největší prvek na stránce ([LCP prvek](https://www.vzhurudolu.cz/prirucka/metrika-lcp)) načíst co nejrychleji. Jde tedy o to, aby vše, co se stahuje před tímto prvkem, bylo také načteno a zpracováno co nejdříve. Zejména jde o soubory se styly a javascriptem.

Odpovědět si otázku jsme se rozhodli při jedné z optimalizací u jednoho z našich největších klientů, [Livesportu](https://www.livesport.cz/).

Na webu Livesportu, konkrétně na stránce [Fortuna liga](https://www.livesport.cz/fotbal/cesko/fortuna-liga/), bylo v době testů 55 malých CSS souborů s celkovou velikostí 789 kB. S využitím komprese gzip během přenosu je pak do prohlížeče přeneseno 156 kB.

V této situaci se LCP prvek načetl za 3 700 ms. (Testoval jsme na Fast 3G připojení.)

Všechny soubory jsem pak spojil do jednoho a zminifikoval. Výsledný soubor jsem nalinkoval do `<head>` stránky a ostatní linky na CSS soubory odstranil.

![Takto vypadají CSS soubory, které se na Livesportu stahují.](/uploads/livesport-css.jpg "Takto vypadají CSS soubory, které se na Livesportu stahují.")

Minifikací se snížil objem dat na 655 kB, po použití Gzip komprese jsme se dostali na 96kB přenesených dat. Ušetřili jsme 54 requestů při stahování CSS souborů a zhruba ⅓ datového objemu, který je přenášen.

Po optimalizaci CSS se LCP načetl za 3 500 ms.

LCP (Largest content paint) se po náhradě 55 malých souborů za jeden velký CSS načetl **na 3G připojení o 200 ms dříve**.

V procentech šlo **pouze o 5 % zrychlení** renderingu LCP prvku.

|  | Počet souborů | Datový objem kB | LCP v ms |
| --- | --- | --- | --- |
| Před úpravou | 55 | 789 | 3 700 |
| Po úpravě | 1 | 655 | 3 500 |

Toto relativně malé zrychlení načtení LCP prvku je zde mimojiné způsobeno velkým množstvím dalších přenášených souborů, jako jsou javascripty. Do výsledného času také promlouvá jejich náročné zpracování, zejména na straně klientského prohlížeče.

## Vyplatí se spojovat CSS do jednoho souboru?

Tento test ukázal, že v jednom souboru toho z pohledu rychlosti moc neušetříme. **Jeden velký CSS soubor není pro LCP výrazně rychlejší než mnoho malých.**

Jsou zde navíc i další faktory. Zohledňujeme zde jen zkušenost uživatele s prázdnou prohlížečovou cache. V reálném provozu ale hraje mezipaměť výraznou roli a bude výhodnější hodně malých souborů. Pokud je tedy jako vývojáři umíte invalidovat po jednom, nikoliv všechny najednou.

## Na závěr ještě obecné rady k CSS. Na co si dát pozor?

1. Pohlídejte si u všech CSS, aby ve výstupu byly co nejmenší. Vždy důsledně minifikujte.
2. Zajistěte, aby nedocházelo k duplicitám v kódu: různé ikonky, barvičky případně celé komponenty. Často to u klientů vídáme.
3. Promazávejte – pokud jsou CSS soubory velké zvažte refaktoring, rozdělení na komponenty, odstranění nepoužívaných (mrtvých) komponent.
4. Zajistěte správné [cachování souborů](https://web.dev/http-cache/) pomocí direktivy `max-age`.
5. Dohlédněte, aby byla na serveru zapnuta komprese Gzip nebo Brotli.
6. Snažte se, aby na stránce nebyly styly, které nejsou využité v HTML, na úvodní stránce nepotřebujeme styly pro nákupní proces
7. Styly mimo první viewport můžete načíst líně, např. pomocí JS.

Více o optimalizaci CSS psal také [Martin Michálek na Vzhůru dolů](https://www.vzhurudolu.cz/prirucka/css-optimalizace) nebo [Harry Roberts](https://csswizardry.com/2018/11/css-and-network-performance/).

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 [app.pagespeed.cz/r/73f8e7b84404](https://app.pagespeed.cz/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/sluzby) 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/kontakty), rádi vám s tím pomůžeme. ;)

Jak už jste si asi někteří všimli, web PageSpeed.cz převlékl kabát a kromě toho postupně spouštíme třetí verzi našeho [testeru rychlosti webů](https://app.pagespeed.cz/).

Jaké hlavní změny přicházejí v nové verzi?

1. Možnost **registrace a přihlášení**, která odemyká nové možnosti jako například úpravu nastavení testu.
2. Přidali jsme také **týmy**, takže můžete rychlost vašich webů sledovat s kolegy a kolegyněmi.
3. **Dashboard**, ve kterém můžete sledovat rychlost libovolného počtu domén.
4. Data o rychlosti nyní sbíráme a zobrazujeme jak pro mobil, tak **nově i pro desktop**.

Třetí verze je nyní ve fázi bety a testování a přestěhovala se na URL: [https://app.pagespeed.cz/](https://app.pagespeed.cz/ "https://app.pagespeed.cz/")

Pojďme se teď společně podívat podrobněji na novinky, které jsme do testeru přidali.

## **Uživatelské účty a týmy**

Práce na měření a zlepšování rychlosti je týmová práce a tak jsme do nástroje přidali možnost přihlášení pod vlastním účtem. Z toho vyplynula možnost tvorby týmu a přidávání kolegů, kteří pak uvidí stejná data o rychlosti jako vy.

![ ](/uploads/pagespeed___app-screenshot-003.png)

Přihlášeným uživatelům také odemykáme nové možnosti jako změnu nastavení testu, včetně žádané změny URL, nebo nastavení odesílání měsíčních reportů e-mailem.

![ ](/uploads/pagespeed___app-screenshot-004.png)

Chcete to hned zkusit? [Zaregistrujte se](https://app.pagespeed.cz/register).

## **Dashboard s rychlosti sledovaných domén**

Víme, že většina z vás nemá na starosti hlídání rychlosti jen u jednoho webu, ale pro celou sadu domén. Dashboard vám umožní sledovat nejen stav rychlosti, ale také hlásí změny oproti předcházejícímu období:

![ ](/uploads/pagespeed___app-screenshot-005.png)

Jak si přidat weby do dashboardu?

1. [Zaregistrujte se](https://app.pagespeed.cz/register) nebo přihlaste.
2. Vytvořte si [nový test](https://app.pagespeed.cz/) nebo použijte URL testů, které máte uložené z dřívějška.
3. Po přihlášení uvidíte dole v testu možnost „Přidat k mým testům“.
4. Po přidání testu vytvoříme jeho kopii, kterou pak budete moci sledovat v dashboardu:

![ ](/uploads/pasted-image-0.png)  
Je dobré vědět, že původní URL testu zůstává na svém místě. Zkopírujeme vám test do nové adresy proto, abyste mohli upravovat tuto svou kopii.

## **Data pro desktop i mobil**

Vaším častým přáním bylo v testech vidět data o rychlosti nejen pro mobilní zařízení, ale také pro desktop.

Tomu rádi vycházíme vstříc, protože nově Google v rámci [signálů Page Experience](https://www.vzhurudolu.cz/prirucka/google-page-experience) hodnotí právě [také desktop](https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop). Zároveň z práce pro klienty víme, že ne každý web má rychlostní metriky v pořádku, zejména pokud se jedná o [Cumulative Layout Shift (CLS)](https://www.vzhurudolu.cz/prirucka/metrika-cls).

Nově se tedy stačí jen přepnout. Toto je k dispozici jak nepřihlášeným, tak přihlášeným uživatelům.

![ ](/uploads/pagespeed___app-screenshot-006.png)

## **Nový design**

Identita PageSpeed.cz, spolu s webem i testerem rychlosti prošla redesignem, který má výraznější typografii a lépe komunikuje data v testeru.

![ ](/uploads/pagespeed___app-screenshot-002.png)  
S novým designem nám pomohl [Petr Ondrusz](https://www.littlebrand.cz/), děkujeme! Dále na testeru třetí verze pracovali Zuzana Šumlanská, Martin Brychta, Michal Matuška, Tomáš Hejč ze [SUPERKODERS](https://superkoders.com/) a Martin Michálek.

## **Tester rychlosti dále zůstává zdarma**

I přes všechna vylepšení ponecháváme tester rychlosti zdarma k dispozici všem, kteří, stejně jako my, vědí, že na rychlosti záleží. Budeme samozřejmě dále pracovat na dalších vylepšeních.

## **Máte zpětnou vazbu? Sem s ní!**

Verzi 3.0 zatím spouštíme v betaverzi a ladíme v ní detaily. Pokud máte jakoukoliv zpětnou vazbu, budeme za ni moc rádi: [info@pagespeed.cz](mailto:info@pagespeed.cz).

Cookie lišty nasazené bez optimalizací rychlosti představují docela závažné ohrožení rychlosti a tedy i [metrik Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals). V tomhle článku se s vámi podělíme o zkušenosti, které jsme získali při práci pro naše klienty.

Asi víte, že cookie lišty (nebo také „CMP lišty“) budou díky změně legislativy na většině webů povinné. Nebudeme se zabývat legislativou (to udělala [Petra Dolejšová](https://www.pavelungr.cz/jak-na-cookie-listu-v-roce-2022-prace-s-cookies-v-roce-2022-saga-pokracuje-petra-dolejsova/)) nebo designem (rozebral [Ondřej Ilinčev](https://www.ilincev.com/cookies-2022)), zaměříme se jen na to, jak si nasazením nepokazit rychlost.

Nejprve vám ukážeme šampiona. Nejhorší možnou cookie lištu, která vám zaručeně metriky zlikviduje.

![ ](/uploads/cookie1.png " ")

To je on, ničení rychlosti webu šampión! Pět vteřin se nic neděje. Pak vám velmi pomalu lišta začne posouvat obsah. Pak ještě více, protože se do ní vykreslí opravdu velký obrázek.

Proč je to z pohledu rychlosti hodně špatně? Přemýšlejte chvíli, určitě na to přijdete.

Máte?

Tohle jsou nejdůležitější problémy, které tato lišta způsobí:

1. Načte se pozdě, když už uživatele může konzumovat obsah stránky.
2. Posunem zhorší [metriku CLS](https://www.vzhurudolu.cz/prirucka/metrika-cls) a to v tomto případě velmi razantně. Metrika by jen u cookie lišty vyskočila na více než pětinásobek maximální možné hodnoty.
3. V posledním kroku se v cookie liště vykreslí obrázek. Ideálně o trochu později než samotná lišta, špatně optimalizovaný a nejlépe větší než jakýkoliv jiný prvek ve stránce. Máme zde tedy ideální podmínky na zničení [metriky LCP](https://www.vzhurudolu.cz/prirucka/metrika-lcp).

Těchto šampionů likvidace rychlosti je na webu k nalezení celá řada. A jak jste si správně odvodili, nemusí jít zrovna o cookie lišty…

Pojďme se teď podívat na konkrétní bolístky, které cookie lišty mohou způsobovat metrikám.

## **Metrika LCP: Vykresli co nejdříve**

Mezi vývojáři se rozšířil mýtus, že vykreslení obsahu typu cookie lišty se musí odložit co nejvíce to jde. Nejde přece o hlavní obsah stránky.

Jde o jednu z velkých chyb, které můžete při implementaci lišt udělat. Coookie lišta je z pohledu uživatele ten hlavní a nejdůležitější obsah. V ideálním případě by si ji měl nejprve přečíst, odkliknout a pak teprve pokračovat na váš web.

A navíc – pokud se vám povedlo lištu navrhnout tak, že obsahuje velké prvky (dlouhé texty nebo obrázky), může se z ní stát „LCP element“, podle jehož vykreslení se počítá metrika Largest Contentful Paint.

Takže odložením lišty můžete odložit také metriku LCP.

Podívejte se na obrázek níže, jsou tam dva weby. Oba velké a technicky komplexní. Pro jejich vývojáře je problematické cookie lištu vykreslit dostatečně včas, i když pro to leccos udělali. Jak to vypadá z pohledu uživatele na pomalejším připojení?

![](/uploads/cookie2.png " ")  
V obou případech se metrika LCP počítá z obsahu lišty. V prvním případě se lišta zobrazí později než layout webu a pak se ještě bohužel čeká na stažení obrázku.

Druhá varianta je mírně lepší. Než se stáhne lišta, je na pomalých připojeních vidět skeleton, který drží prostor pro vykreslení obsahu lišty.

## **Metrika CLS: Neposouvej, neanimuj**

Už asi víte, že metriku Cumulative Layout Shift kazí nechtěné posuny obsahu. Na úvodním příkladu opravdu špatné lišty jsme viděli největší problémy, které můžete metrice CLS (a uživatelům) způsobit špatným designem nebo implementací.

V kontextu CLS si ale dejte pozor i na konkrétní řešení. U jednoho našeho klienta například implementace řešení [Google Funding Choices](https://fundingchoices.google.com/) zhoršila tuto metriku trojnásobně:

![](/uploads/cookie3.png " ")

Máme ověřeno, že na uživatelských datech (Web Vitals z Chrome UX Reportu) to tak velký dopad nemělo. Přesto je to rozhodně varování před slepou implementací cizích řešení.

Testujte. A měřte, měřte a měřte. Třeba v našem [testeru rychlosti webu](https://pagespeed.cz/).

U CLS si dejte pozor také na animace. Asi víte, že je potřeba animovat správně, tedy pomocí CSS vlastností jako transform. Jenže – když v některých řešeních necháte zapnuté jejich animace, jsou udělány špatně a zhorší vám CLS. Tady bychom jako špatný příklad mohli uvést řešení [OneTrust (dříve Optanon)](https://www.onetrust.com/).

## **FID/TBT: Měřte dopad na výkon prohlížeče**

„JavaScriptová“ [metrika First Input Delay](https://www.vzhurudolu.cz/prirucka/metrika-fid) (nebo [Total Blocking Time](https://www.vzhurudolu.cz/prirucka/metrika-tbt) při syntetickém měření) cookie lištami zhoršená nebývá. Ale i zde najdeme výjimky.

![](/uploads/cookie4.png " ")  
Dejte si v tomto směru pozor na řešení [Didomi](https://www.didomi.io/), které na pomalejším mobilu dokáže zablokovat hlavní jádro prohlížeče na čtyřnásobek hodnoty Google Analytics. U běžných webů je to jen trochu otrava, ale např. u webů, kde je vytížení renderingu pomocí cizích JS už větší (obsahové weby s reklamou), může toto znamenat zhoršení FID u uživatelů.

## **Poznámka k měření**

Setkáváme se často s názorem, že komponenty třetí strany by se neměly do měření rychlosti zahrnovat, protože za ně vývojáři nezodpovídají.

Jenže uživatel web bez [third-party komponent](https://www.vzhurudolu.cz/prirucka/third-party) nevidí. Nezbývá než se s cookie lištou i dalšími třetími stranami smířit a prostě měřit reálný stav.

U cookie lišty však nastává speciální situace: Část uživatelů web vidí s ní a část bez ní. Proto doporučujeme testovat obě varianty.

![](/uploads/cookie5.png " ")  
Na obrázku je vidět nastavení SpeedCurve pro Livesport, kde s cookie-lištou testujeme jen homepage. Zde se to technicky řeší pomocí [skriptování WebpageTestu](https://docs.webpagetest.org/scripting/). Vy si podobné řešení můžete udělat např. pomocí [Lighthouse User Flows](https://www.vzhurudolu.cz/blog/206-lighthouse-9).

## **Doporučení pro vaši implementaci**

Pojďme si to shrnout:

1. Načtěte cookie lištu co nejdříve.
2. Pokud je to možné, vyhněte se v ní velkým prvkům, které mohou být LCP elementy.
3. Dávejte si pozor na animace a vyjíždění lišty shora.
4. Testujte dopad rychlosti vybraných řešení.
5. Měřte dopad na rychlost s cookie-lištou nebo i bez ní.

## Video na závěr

Pokud preferujete mluvené slovo, je k dispozici můj záznam z webináře Pavla Ungra o cookie lištách.

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

S implementací a optimalizací vám samozřejmě dokážeme v rámci několika hodin konzultací pomoci, ozvěte se případně na: [martin.michalek@pagespeed.cz](mailto:martin.michalek@pagespeed.cz).

Přejeme vám rychlé weby! I s cookie lištou.

Blog

Tester rychlosti PageSpeed.cz: novinky ve verzi 3.1

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

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

Rychlost webu: 12 novinek roku 2022

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

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

Test: je lepší hodně malých CSS souborů nebo jeden velký?

Stopa PageSpeed.cz na WebExpo 2022

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

PageSpeed.cz tester: co je nového ve verzi 3.0

Cookie lišty a rychlost webu