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.

Máme rádi WebExpo a&nbsp;máme rádi performance. A navíc máme rádi Harryho Robertse, protože jeho přednášky a&nbsp;články jdou vždy do hloubky.

Harry na letošním ročníku WebExpa [přednášel](https://www.webexpo.net/prague2021/talk/get-your-head-straight), jak pouhé pořadí prvků v&nbsp;&lt;head&gt; dokáže pohnout s&nbsp;rychlostí webu.

## Otestujte si správně pořadí prvků v &lt;head&gt;

V přednášce byl uveden příklad, kdy jedna taková drobnost připravovala jeho klienty potenciálně o&nbsp;miliony dolarů. Takový dopad na vaše weby nečekejte, Harryho příklad považujeme za jehlu v&nbsp;kupce sena. Výhru v optimalizační loterii.

Nicméně – pokud si myslíte, že velké věci v&nbsp;oblasti rychlosti už máte vyřešené, nebo prostě jen chcete otestovat, zda je všechno správně, využijte jeho nástroj [CT.CSS](https://csswizardry.com/ct/).

Jde o kousek CSS, který vás upozorní na případné chyby v&nbsp;pořadí prvků v&nbsp;oblasti &lt;head&gt;:

* Přidejte si to CSS přímo do stránky.
* Použijte bookmarklet.
* Uložte si to do Snippets v rámci Chrome DevTools.

Je to na vás. Jste nedočkaví? Mrkněte se na [demo](https://csswizardry.com/ct/test/).

My jsme to udělali u několika webů. Příklady:

_![ ](/uploads/image-11.png " ")_

Na obrázku vidíte jeden velmi navštěvovaný český web. Poznáte jej? :-)

Pokud byste viděli červeně rámované upozornění, berte to vážně. Může se stát, že zrovna ten váš bude jedním z&nbsp;webů, u&nbsp;kterých může mít oprava i&nbsp;zásadnější vliv.

Možná ale také zjistíte, že zde zakopaný pes rychlosti vašeho webu neleží.

## Jaké je správné pořadí prvků v &lt;head&gt;?

Podívejme se, jak by to mělo být správně, alespoň podle Harryho:

    <meta charset | http-equiv | viewport>
    <title>
    
    
    <link rel="preconnect">
    
    
    <script src="" async></script>
    
    
    <link rel="stylesheet" href="…">
    
    
    <script src="…"></script>
    
    
    <link rel="stylesheet" href="…">
    
    
    <link rel="preload">
    
    
    <script src="" defer></script>
    
    
    <link rel="prefetch">
    <link rel="prerender">
    
    

Zajímá vás více? Mrkněte se na [slajdy k Harryho přednášce](https://speakerdeck.com/csswizardry/get-your-head-straight).

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>

Když jsme loni v PageSpeed.cz začali s vývojem testeru, měli jsme dva cíle. Vytvořit nástroj, který by pasoval do našich pracovních postupů pro měření rychlosti webu, a zároveň jeho prostřednictvím pomoci zlepšit povědomí o rychlosti samotné.

S právě spuštěnou druhou verzí jsme zase o kus dál při plnění těchto cílů. Z našeho testeru teď snáze vyčtete stav a vývoj metrik [Core Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals) pro doménu vašeho webu, což vám umožní lépe plnit doporučení chystaného [update Page Experience](https://developers.google.com/search/blog/2020/11/timing-for-page-experience) od Googlu.

Novinek je v nástroji mnoho, vyberme ty nejdůležitější:

* [Jak se vyvíjí rychlost u uživatelů? Data z Chrome UX Reportu](https://docs.google.com/document/d/1MHVgJh2L-brp0yLmjWIlT_GzNCwdq2FBfucfbr35fVU/edit?pli=1#heading=h.buql87ecdysz)
* [Shrnutí stavu webu a změny metrik](https://docs.google.com/document/d/1MHVgJh2L-brp0yLmjWIlT_GzNCwdq2FBfucfbr35fVU/edit?pli=1#heading=h.827utwdgrfe8)
* [Období v grafech a přepínání podle metrik](https://docs.google.com/document/d/1MHVgJh2L-brp0yLmjWIlT_GzNCwdq2FBfucfbr35fVU/edit?pli=1#heading=h.dlpg0p7j7j95)

Změny uvidíte i ve vašich starších testech, případně si na [pagespeed.cz](https://pagespeed.cz/) vytvořte nový. Teď už se ale pojďme podívat na ty slíbené novinky.

## **Jak se vyvíjí rychlost u uživatelů? Data z Chrome UX Reportu**

Jak možná víte, Google se v rámci svého Page Experience update chystá klást větší důraz na rychlost a uživatelský zážitek z webu.

Hodnocení všech stránek domény nebo konkrétní stránky si pak Google vezme z dat od uživatelů Chrome, která jsou veřejně dostupná jako [Chrome UX Report (CrUX)](https://www.vzhurudolu.cz/prirucka/chrome-ux-report).

Je zde řada možností, jak tato data o můžete získat i vy: programátorským dotazem do databází Google, vytvořením dashboardu pro Data Studio… nicméně žádná z nich není tak pohodlná, jak bychom si přáli nebo nezohledňuje lokální specifika.

V testeru na PageSpeed.cz teď ta data získáte pouhým zadáním adresy vašeho webu do testu.

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

V reportu „Domény“ uvidíte vývoj měsíčních dat pro všechny domény zadané v testu a metriky [Web Vitals](https://www.vzhurudolu.cz/prirucka/web-vitals) ([LCP](https://www.vzhurudolu.cz/prirucka/metrika-lcp), [FID](https://www.vzhurudolu.cz/prirucka/metrika-fid), [CLS](https://www.vzhurudolu.cz/prirucka/metrika-cls)).

Data můžete přepínat podle typu zařízení (Mobil, Tablet, Desktop) nebo podle typu zobrazení – můžete vidět buď rozložení nebo 75. percentil:

![](/uploads/pagespeed_16-9_verze2_0-003.png " ")

Podívejme se na rozdíly mezi těmito typy zobrazení:

* Graf „Rozložení“ ukazuje, jaká část vašich uživatelů má danou metriku splněnou (zelená), jaká vyžaduje vylepšení (oranžová) a u jaké části Google považuje uživatelský prožitek za pomalý.
* Graf „75. percentil“ je ještě zajímavější – ukáže vám hodnotu na 75. percentilu, což je hodnota na tmavě vyznačené čáře u grafu „Rozložení“. Zároveň je to číslo, které zajímá Google. Například na obrázku vidíte, že hodnota LCP je na doméně mironet.cz v březnu 2021 (vpravo) 2,0 vteřiny. Maximum pro splnění metriky je podle Google 2,5 vteřiny, takže vše je v pořádku, což je vyznačené zelenou barvou.

Poznámka: V reportu „Domény“ stahujeme data z Chrome UX Reportu pro české a slovenské uživatele webu, takže pokud provozujete službu pro zahraniční návštěvníky, nemusíte tam data vidět.

### **K čemu je srovnání domén dobré?**

Pokud řešíte rychlost, je nutné se jí zabývat dlouhodobě a vědět, jak si stojíte u reálných uživatelů, jak je na tom konkurence a jak web hodnotí Google. Toto všechno zjistíte z našeho přehledu „Domény“.

Tyto grafy ukazujeme našim klientům při dlouhodobé práci na optimalizaci rychlosti a jsou zásadní pro vyhodnocování, zda se práce daří.

Podívejme se, co je možné vyčíst z tohoto grafu pro jeden z klientských webů:

![](/uploads/pagespeed_16-9_verze2_0-004.png " ")

Zelené sloupečky v březnových číslech roku 2021 (vpravo) u metrik LCP a FID nám říkají, že pro celou doménu splňujeme dvě ze tří metrik Web Vitals. Z grafu navíc vidíme, že stav metrik je poměrně stabilní. To je ta lepší část zprávy.

Horší část zprávy je „splašená“ metrika CLS, která nám v březnu 2021 vyskočila pro celou doménu z doporučeného maxima 0,1. Takže se něco děje a my bychom měli pracovat. Jen pozor, jde o data od uživatelů. Nemusí to znamenat jen to, že se na webu něco změnilo k horšímu, ale klidně to, že se něco změnilo u uživatelů nebo třeba i to, že se změnil výpočet metriky.

V tomto případě máme štěstí, i když nevím, zda je to ten správný výraz – roli zde mají všechny tři faktory. Kromě úprav webu také uživatelé aktualizovali na novou verzi Chrome, která trochu jinak počítá Cumulative Layout Shift.

Takže vidím stav a vidím vývoj. To je přesně to, co pro dlouhodobou práci na projektu potřebuji.

Asi jste si všimli, že zde navíc stahujeme data pro [rychlost backendu (TTFB)](https://www.vzhurudolu.cz/prirucka/ttfb), metriku, která nepatří do Core Web Vitals. To proto, abyste snadno dokázali vyhodnotit, zda je pomalé LCP je způsobené spíše frontendovými nebo backendovými problémy.

Věříme, že nová data v reportech pomohou i vám.

## **Záložka „Shrnutí“ a změny metrik**

V nové záložce „Shrnutí“ zobrazujeme stav rychlosti hlavní měřené stránky v daný den. Přidali jsme také informaci o změnách v metrikách v krátkodobém a dlouhodobém horizontu.

Už dříve jste zde mohli vidět stav rychlosti měřené stránky. Pokud máme data od uživatelů z Chrome UX Reportu, zobrazujeme čtyři „budíky“, v opačném případě jen jeden, z měření [nástrojem Lighthouse](https://www.vzhurudolu.cz/prirucka/lighthouse):

![](/uploads/ps-tester-2-budiky-1.png " ")

Všimněte si, že zde nově vyznačujeme vývoj metrik v čase. Změny v hodnotách metrik vyšší než 15 % při srovnání se stavem před týdnem vám tady hlásíme.

Rychlost domény je v této sekci nová. Pokud je v Chrome UX Reportu dostatek dat od uživatelů, tady uvidíte tři „budíky“ pro Core Web Vitals a opět vývoj v čase. Tentokrát srovnáváme aktuální stav ke dnešku se stavem před měsícem, protože zde považujeme za vhodnější sledovat dlouhodobý vývoj:![](/uploads/ps-tester-2-budiky-2.png " ")

Data v záložce „Shrnutí“ pocházejí z PageSpeed Insights API a uživatelská čísla z CrUX zde představují kumulativní průměr za posledních 28 dní. Proto se data v záložce „Shrnutí“, stejně jako „Měření“ mohou lišit od dat v záložce „Domény“, kde jsou po měsících.

## **Období v grafech a přepínání podle metrik**

Tato změna je z těch, o které jste si často psali. V grafech jsme historicky nepoužívali žádné filtrace, zpočátku nebyly potřeba. Jenže u některých domén sledujeme metriky rychlosti každý den už téměř rok a často bychom se rádi podívali na vývoj v posledním měsíci nebo třech měsících:

![](/uploads/pagespeed_16-9_verze2_0-007.png " ")

Nově je také možné u některých grafů přepínat metriky, které vidíme. Koho by například nezajímal vývoj LCP naměřené Lighthousem?

První tip: Všimli jste si, že v grafech je možné vypnout zobrazení měřených URL, abyste dostali krásný čistý graf pro jednu z nich?

Druhý tip: Klikněte na puntík v grafu a dostanete kompletní Lighthouse report pro danou URL a daný test.

## **Menší úpravy**

Do verze 2 jsme ale dostali řadu jiných změn, tady je seznam těch nejdůležitějších:

* Upravili jsme vzhled „budíků“ ve shrnutí testu tak, aby více odpovídaly stavu metriky.
* Rozdělili jsme obsah testu do záložek, přidali vysvětlení, co v nich najdete a udělali další řadu úprav pro přehlednější rozhraní.
* Opravili jsme funkčnost při použití tlačítka Zpět v prohlížeči.
* Možné chyby, které vrací PageSpeed Insights teď více vysvětlujeme.

## **Jak novinky v testeru PageSpeed.cz používat?**

Pro naše klienty si vytváříme vždy dva testy:

1. Test pro doménu klienta a jeho konkurenty. Zde pak v záložce „Domény“ uvidíte, jak si v rychlosti vede doména klienta a jak je na tom trh, ve kterém se snaží uspět.
2. Test pro vstupní stránky webu. Kromě homepage dáváme např. u obsahových webů také detail článku nebo kategorii článků. Při výběru vhodných URL pomůže report Web Vitals z Google Search Console.

Pokud klient používá více domén nebo subdomén, vytváříme ještě jeden test jen pro tyto domény. Data z CrUX se mohou lišit pro domény _example.cz_ a _subdomena.example.cz_.

Líbí se vám novinky v testeru? Nebo vám v něm něco chybí? Napište nám na [info@pagespeed.cz](mailto:info@pagespeed.cz). Každou zpětnou vazbu nebo nápad vítáme.

Live chat používá dvacet procent provozovatelů českých e-shopů. Jak ale tyto komponenty ovlivní rychlost webu? Podívali jsme se podrobně na deset nejpopulárnějších live chatů a dozvěděli jsme se přitom leccos zajímavého.

Shrnutí našich zjištění jste mohli vidět v našem streamovaném pořadu Na rychlosti záleží. Podrobně studii prezentujeme v následujícím textu.

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

Nejlépe nám z pohledu rychlosti vyšly widgety od LimeTalk, Daktela nebo LiveAgent. Chybu ale z pohledu načítacího výkonu neuděláte ani výběrem nejpopulárnějšího SmartSuppu.

Naopak si dejte pozor na Manychat, Zopim, ale i velmi známý Facebook Chat Plugin (zvaný též Messenger). Rozdíly vlivu rychlosti jsou mezi chaty opravdu velké. Mimochodem, jeden z nich vám sníží hodnocení rychlosti v nástroji Lighthouse o celých 35 bodů ze 100.

### **Jaké jsou nejpopulárnější služby pro live chat ČR?**

Z letošní [studie Reshoper](https://www.reshoper.cz/datablog/185-ceskych-e-shopu-pouziva-live-chat-jake-jsou-trendy-video/) vyšlo, že nějaký chatovací widget používá zhruba pětina českých e-shopů. Live chaty tedy mají z pohledu využívanosti vliv na uživatelský prožitek nemalé části Čechů nakupujících online.

Díky [Filipovi Podstavci](https://www.podstavec.cz/) z [Marketing Mineru](https://www.marketingminer.com/cs) jsme v listopadu 2020 získali aktualizovaná data o nejpoužívanějších webových chatech v rámci Česka. Jednoznačně mezi nimi dominuje Smartsupp, ale celé pořadí v první desítce je následující:

 1. [SmartSupp](https://www.smartsupp.com/)
 2. [Facebook Chat Plugin](https://developers.facebook.com/docs/messenger-platform/discovery/facebook-chat-plugin/)
 3. [Tawk](https://www.tawk.to/)
 4. [Zendesk/Zopim](https://www.zendesk.com/chat/)
 5. [FoxyDesk](https://www.foxydesk.cz)
 6. [Livechatoo](https://www.livechatoo.com/)
 7. [LimeTalk](https://www.limetalk.com/)
 8. [Daktela](https://www.daktela.com/)
 9. [LiveAgent](https://www.liveagent.com/)
10. [Manychat](https://manychat.com/)

## **Jak jsme měřili?**

Naše metodika vypadala následovně:

* Každý live chat jsme vložili podle základních instrukcí od výrobce do úplně prázdné stránky, a pak také do složitější stránky – pro tyto potřeby jsme zvolili šablonu [Landkit](https://landkit.goodthemes.co/).
* Každou vzniklou testovací stránku jsme několik dní měřili syntetickými testy [nástroje SpeedCurve](https://speedcurve.com/) na emulaci pomalého mobilního zařízení Samsung Galaxy S4. [Výsledný dashboard](https://speedcurve.com/vzhru-dolu/favorite/?cs=lg&d=30&db=124487&dc=2&de=1&df=%7B%7D&ds=1&share=6jsa57zzpkgbl2r470uw3f4eqlm9dn). [Tabulka s výsledky](https://docs.google.com/spreadsheets/d/17gtGEXU0D1nB0cV2dZiCxOJdD3DcyOVAKL4oJXpMI4k/edit#gid=1303921103).
* Nejpopulárnější služby ještě kolega Michal Matuška podrobil ručním testům v prohlížeči. Zaměřil se přitom na validaci výstupů syntetických testů a snažil se najít i možnosti k vylepšení, jak pro majitele webu, tak pro autory widgetů.

## **Co jsme naměřili?**

Abychom mohli získané výsledky porovnávat, samozřejmě, že jsme neváhali sáhnout hned po několika dostupných metrikách rychlosti webu.

Začněme technickými ukazateli. V celkovém obraze hrají méně podstatnou roli, ale hned uvidíte, proč jsme se jimi zabývali.

### **Přenesená data**

Datový objem, který widgety stahují, mohou z dnešního pohledu vypadat jako méně podstatná metrika.

Nicméně — asi byste jako provozovatelé webů nechtěli, aby vaši uživatelé stahovali jen pro chatovací službu celý megabajt dat navíc. Že se tohle stát nemůže? Pak nám prosím ještě chvíli věnujte pozornost.

Pokud se navíc data live chatu přenáší v nevhodný čas, prohlížeč to může zpomalit ve stahování daleko důležitějších prvků vašeho webu.

Jak to dopadlo?

* Exceloval zde **Limetalk**, s pouhými 8 přenesenými kilobajty (!).
* Naopak díky vývojářům z Facebooku se vám s Messengerem do webu stáhne přes jeden megabajt dat. U Manychatu se ukazatel dokonce zastavil až na 1,1 MB.

### **Počet stahovaných souborů**

Množství souborů v době moderních protokolů HTTP/2 a HTTP/3 zase tak velkou roli nehraje, pokud jsou ovšem soubory datově malé.

Ale opět – je slušností každé služby množství stahovaných souborů držet zkrátka, protože se s nimi musí dělit ještě soubory vašeho webu.

* Krásné výsledky zde má **LimeTalk** a **Daktela** (oba 5 souborů) nebo **LiveAgent** (7 souborů).
* Facebook stáhne 42, Manychat dokonce 49 souborů. Z takového množství už bychom mohli poskládat slušně velký web.

Je však potřeba říci, že zde hraje roli vykreslovací strategie, kterou autoři chatu zvolili. Některé služby stahují hned zpočátku velké množství dat, ale „bublina“ jejich chatu je vcelku brzy k dispozici. U jiných, datově šetrnějších služeb, zase nějakou dobu trvá první zobrazení.

Pojďme na další ukazatel. Tady už půjde do tuhého, protože jej považujeme za důležitý indikátor vlivu na rychlost.

### **Lighthouse Performance Score (LPS)**

„Lighthouse skóre“ jsme nemohli vynechat. Skládá se ze šesti podstatných metrik, takže dává plastický obrázek o celkové možné rychlosti webu. Více [o LPS je na Vzhůru dolů](https://www.vzhurudolu.cz/prirucka/metrika-lps).

Jaký vliv mají chaty na metriku LPS na prázdné stránce?

* Vynikající jsou **LimeTalk**, **Daktela** a **LiveAgent** – Lighthouse skóre (měřené přes SpeedCurve) zůstává na 100 bodech. Oceňme ale také skvělé výsledky **Livechatoo** (99 bodů ze sta) a **SmartSupp** (95 bodů)
* Pohled na chvost pelotonu je u této metriky velmi smutný. Zopim sníží Lighthouse skóre prázdné stránky ze sta na 67 bodů, Manychat dokonce na 65 bodů ze 100. To je opravdu zlé.

Tady bychom si už mohli říci, že vítěze a poražené známe. Ale není to tak jednoduché. Chtěli bychom vás upozornit ještě na další podstatné faktory.

Začneme metrikou, která je sice součástí Lighthouse Performance Score, ale v případě komponent třetích stran ji vnímáme jako jednu z nejpodstatnějších.

### **Total Blocking Time (TBT)**

„Celkový čas blokování“ udává interval, který prohlížeč potřebuje pro zpracování složitých úloh v JavaScriptu, a po který tedy uživatel nebude moci s již vykreslenou stránkou interagovat. [Více o TBT](https://www.vzhurudolu.cz/prirucka/metrika-tbt) je opět na Vzhůru dolů.

Mrkněme se na výherce a poražené i u tohoto ukazatele:

* U **LimeTalk** a **LiveAgent** naměřilo SpeedCurve ve všech testech nulový blokující čas, což je skvělé. Výborné výsledky má také **Livechatoo** (10 ms), **FoxyDesk** (28 ms), **Daktela** (46 ms), ale špatné nejsou ani výsledky populárního Smartsuppu (270 ms).
* Za hranou únosných hodnot je z našeho pohledu Zopim (1 079 ms) a na hraně se pohybuje Manychat (438 ms).

Pro kontext – měřili jsme na emulaci mobilu, kde například běžně nastavené Google Analytics spotřebují kolem 100 ms TBT.

V ideálním světě by bylo nejlepší, kdyby komponenty při zpracování JavaScriptu žádné intervaly blokující stránku delší než 50 ms, které právě TBT měří, neměly. Ale jako vývojářům je nám jasné, že to je těžko dostupná meta.

Kromě výše uvedeného Zopimu bychom zde mohli konstatovat, že měřené live chaty mají na interaktivitu uživatele méně negativní vliv než jsme čekali.

### **Rychlost zobrazení chatu**

Jak jste možná viděli na videu, Michal Matuška se při detailní pitvě nejpopulárnějších widgetů v prohlížeči zaměřil také na rychlost zobrazení. Vyšlo to takto:

| Chat | Rychlost zobrazení |
| --- | --- |
| SmartSupp | 5 s |
| Facebook | 7 s |
| Tawk | 2,7 s |

Nejrychleji se zobrazí Tawk, ale je pravda, že jeho autoři zvolili strategii rychlého zobrazení úvodní „bubliny“, takže inicializace komunikačního okénka u Tawku ještě nějakou chvíli trvá.

Vsadili bychom se, že v zájmu většiny provozovatelů webů je nejprve zobrazit svůj podstatný obsah, komunikační nástroje pak vykreslit uživateli až v druhém nebo třetím sledu.

Tato strategie nemusí být vlastní všem, ale pokud se jí budeme držet, nemusí pozdější zobrazení SmartSuppu nebo Facebooku vadit. Naopak může být záhodno rychle se stahujícímu a vykreslujícímu Tawku snížit prioritu nebo jej jinak zpomalit.

A teď se dostáváme do finále, určitě vás totiž zajímá konečný verdikt.

## **Celkové zhodnocení**

Nejprve si do tabulky pojďme přenést všechny výsledky.

<span class="u-text-right">

|  | LPS | Stažených kB | Soubory | TBT v ms |
| --- | --- | --- | --- | --- |
| SmartSupp | 95 | 247 | 12 | 270 |
| Facebook | 78 | <span class="u-color-slow">1 052</span> | <span class="u-color-slow">42</span> | 319 |
| Tawk | 93 | 177 | 16 | 135 |
| Zopim | <span class="u-color-slow">67</span> | 554 | 15 | <span class="u-color-slow">1 079</span> |
| FoxyDesk | 87 | 517 | 30 | 28 |
| Livechatoo | 99 | 49 | 16 | 10 |
| LimeTalk | <span class="u-color-fast">100</span> | <span class="u-color-fast">8</span> | <span class="u-color-fast">5</span> | <span class="u-color-fast">0</span> |
| Daktela | <span class="u-color-fast">100</span> | 36 | <span class="u-color-fast">5</span> | 46 |
| LiveAgent | <span class="u-color-fast">100</span> | 27 | <span class="u-color-fast">7</span> | <span class="u-color-fast">0</span> |
| Manychat | <span class="u-color-slow">65</span> | <span class="u-color-slow">1 127</span> | <span class="u-color-slow">49</span> | <span class="u-color-slow">438</span> |

</span>

_Tabulka s výsledky testů: LPS představuje Lighthouse Performance Score, dále je zde počet stažených kilobajtů, počet souborů a Total Blocking Time v ms. Vysvětlení metrik a hlubší rozbor hledejte v textu výše._

U každého hodnoceného kritéria jsme hledali dva až tři nejlepší (vyznačené zeleně) a nejhorší live chaty (vyznačené červeně).

Čím více zelených čísel tedy chatovací widget obdržel, tím lépe. Naopak na komunikační nástroje s více než jednou červenou barvou byste si měli dát opravdu pozor.

Shrňme si výsledky do několika doporučení založených čistě jen na testech rychlosti:

* Vřele vám doporučujeme vybrat jakýkoliv chat z trojice **LimeTalk**, **Daktela** nebo **LiveAgent**. Zejména první uvedený dosahuje opravdu skvělých hodnocení. Chybu ale z pohledu načítacího výkonu neuděláte ani výběrem SmartSuppu, Tawku nebo Livechatoo. Ty sice neexcelovaly, ale jejich výsledky nejsou vůbec špatné.
* Naopak v naší studii dobře nevyšel Manychat, následovaný Zopimem a Facebookem.

Raděj ještě jednou akcentujeme, že jiné parametry než rychlost jsme zde v potaz nebrali, ale předpokládáme, že vy to při výběru vhodné komponenty uděláte.

## **Pitva tří nejdůležitějších v prohlížeči**

Kromě Martinových měření ze SpeedCurve udělal ještě Michal detailní analýzu stahování a vykreslování tří nejoblíbenějších chatovacích nástrojů přímo pomocí vývojářských nástrojů v prohlížeči Chrome.

Měření jsme prováděli přes Lighthouse v Chrome (Version 86.0.4240.183 (Official Build) (x86_64)) a v anonymním okně, při mobilním pohledu.

### **SmartSupp**

Chat se zobrazí cca kolem páté vteřiny. Zlepšit by se mohl vodopád stahování jednotlivých souborů nutných ke spuštění. Díky tomu by se chat zobrazil rychleji. Řetězení považujeme za zbytečné. Každý odstraněný článek zde znamená výrazný posun.

![](/uploads/ahoj-001.jpeg "Obrázek: Řetězení souborů při stahování SmartSuppu.")

Samotný javascriptový runtime má v prohlížeči kolem 380 ms, což považujeme za dobrý výsledek.

### **Facebook Chat Plugin**

Chat se zobrazí cca kolem šesté vteřiny. Námět na zlepšení do Facebooku je určitě už dříve uváděná datová velikost. Je zde spousta přenesených dat ve velkých souborech, JavaScript, který se musí stáhnout a vykonat. Odsouvá se tím to zobrazení. Přenesená data zpomalí i přenášení ostatních zdrojů na kterých je web závislý.

Vzhledem k datovému objemu byste při implementaci Facebook Chatu nejvíce pomohli metodou líného načtení, kterou zmiňujeme v textu dále.

### **Tawk**

Chat se zobrazí cca kolem třetí vteřiny. Vodopád stahování vypadá téměř ukázkově:

![](/uploads/ahoj1-001.jpeg "Vodopád stahování souborů widgetu Tawk vypadá opravdu jako vodopád. Zdroj: Chrome DevTools.")

Tady asi nemáme co dodat. Překvapily nás jen tři reference na font z Google. Navíc se zdá, že jde o odkaz na stejný soubor:

![](/uploads/ahoj3-001.jpeg "Vícenásobné dotazy na stejné soubory jinak výborný dojem z Tawk trošku kazí. Ale to je drobnost, která se v běžném provozu díky HTTP cachování neprojeví.")

Samotný runtime se zpracovává kolem 300 ms, což je opět velmi dobré.

## **Pár poznámek k SmartSupp a LiveAgent**

Potěšily nás velmi dobré výsledky dvou místních produktů – českého [SmartSuppu](https://www.smartsupp.com/cs/) a slovenského [LiveAgent](https://www.liveagent.com/).

Smartsupp ještě donedávna nepatřil v záležitost rychlosti webu mezi šampiony, ale přechodem na novou verzi widgetu se nám u mnoha klientů nemálo zlepšila čísla.

![](/uploads/smartsupp.png "Nasazení nové verze widgetu od  SmartSupp u jednoho našeho klienta, středně velkého e-shopu. ")

Byli jsme v kontaktu s oběma firmami a musíme říct, že rychlost rozhodně neberou na lehkou váhu.

Chtěli bychom tím motivovat i vás. V případě, že z nějakých důvodů používáte jeden z pomalejších chatů, neváhejte se spojit s autory. Ale to už míříme obecným doporučením, která jsme si nechali na závěr.

Další český software – [FoxyDesk](https://foxydesk.cz/) – také dosáhl slušných výsledků, ale byli bychom raději, kdyby widget stahoval méně souborů a dat.

## **Obecná doporučení pro vývojáře, marketéry a majitele webu**

Na úplný závěr vám dáme obecná doporučení, bez ohledu na to, jaký nástroj pro live chat využíváte.

### **Vybírejte live chat i podle rychlosti**

Do parametrů pro výběr live chatu si určitě přidejte rychlost. Jak je z naší studie vidět, řada z nich vám rychlost webu ovlivní poměrně razantně.

### **Měřte vliv komponent třetích stran**

Měřte vliv komponent třetích stran. My používáme third-party analýzu ve SpeedCurve, ale nemálo vám může pomoci i rozbor třetích stran z obyčejného Lighthouse. Více [o analýze komponent třetích stran](https://www.vzhurudolu.cz/prirucka/third-party) najdete na Vzhůru dolů.

### **Komunikujte s autory widgetů**

Vidíte nepříjemný dopad widgetu na rychlost úvodního vykreslení stránky? V prvé řadě pište autorům, je možné, že to prostě zatím jen nezačali řešit.

### **Zvažte lazy loading widgetu**

Zkuste případně metodu [odloženého načtení](https://www.vzhurudolu.cz/prirucka/third-party#optimalizace-lazyloading) chatu.

![](/uploads/smarty.png "Optimalizovaný widget na Smarty.cz. Zdroj: Vzhůru dolů.")

Metoda odloženého načtení (lazy loading) spočívá v náhradě živého chatu pomocí zástupného symbolu (placeholderu), nejčastěji obrázku.

Skutečný chatovací widget se pak načte později. První možnost je vyvolání na akci uživatele, což může být kliknutí na placeholder, nebo přiblížení kurzoru. Druhou možností je stažení po určitém čase tak, aby soubory widgetu nezpomalovaly stahování a provádění důležitějších prvků stránky.

Pokud chcete s optimalizací live chatu nebo rychlosti webu pomoci, neváhejte obrátit na PageSpeed.cz.

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>

Blog

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

Srovnejte si to v <head>

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

PageSpeed.cz verze 2: Data od uživatelů z Chrome UX Reportu a další změny

Checklist rychlosti webu 2021

Studie PageSpeed.cz: Vliv chatovacích widgetů na rychlost webů

Rozhovor s Filipem Podstavcem z Marketing Mineru