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>


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. ;)

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

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

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

## Obsah

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

## Web Vitals v kostce

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

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

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

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

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

## Jak změřit rychlost webu?

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

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

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

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

## FID - First Input Delay

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

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

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

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

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

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

## LCP - Largest Contentful Paint

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

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

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

### LCP a lazy loading

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

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

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

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

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

### LCP a složitý DOM

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

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

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

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

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

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

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

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

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

### LCP a obrázky z WYSIWYGU

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

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

## CLS - Cumulative Layout Shift

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

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

### CLS a atributy width a height

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

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

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

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

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

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

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

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

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

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

### CLS a AJAX

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

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

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

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

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

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

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

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

## **Diskuze**

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

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

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

Co se řešilo?

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

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

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

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

## Next.js conf

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

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

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

## HTTP/3

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

## BlurHash

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Lighthouse Score for All

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

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

## Glyphhanger - nástroj pro optimalizaci fontů

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

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

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

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

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

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

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

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

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

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

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

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

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

Tým PageSpeed.cz

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

Blog

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

Stopa PageSpeed.cz na WebExpo 2022

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

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

Checklist rychlosti webu 2021

Rozhovor s Filipem Podstavcem z Marketing Mineru

Tipy a novinky ze světa rychlosti vol. 2

Tipy a novinky ze světa rychlosti vol. 1

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