Core Web Vitals

 Co jsou Core Web Vitals?

Core Web Vitals definují metriky, které mají přímý vliv na uživatelský zážitek bez ohledu na typ webové stránky, cílovou skupinu či její účel.

V roce 2020 Google definoval tři konkrétní metriky, na kterých nejvíce záleží a zároveň reprezentují nejdůležitější situace, na kterých stojí uživatelská zkušenost – načítání, interaktivita a vizuální stabilita.

 Podívejme se na to zblízka

LCP (Largest Contentful Paint) – metrika, která se zaměřuje na rychlost načítání a definuje bod, ve kterém je načten a vykreslen hlavní obsah webu. Z praxe víme, že nejčastější příčinou špatných výsledků této metriky jsou velké obrázky, slider či automaticky spouštěná videa.

FID (First Input Delay) – tato metrika se zaměřuje na měření odezvy uživatele a zatížení webu. Kvantifikuje zkušenosti uživatelů, kteří při pokusu o interakci s webovou stránkou nedostávají žádnou zpětnou vazbu. V praxi to vypadá tak, že už se vám sice načítal obsah, ale při kliknutí na nějaké tlačítko nebo scrollování níže webová stránka nereaguje.

Tato metrika většinou nebývá problémem, ale když se už vyskytne, nejběžnější příčinou je slabý výkon serveru (nebo jeho umístění geograficky daleko), příliš mnoho použitých JavaScriptových kódů nebo zahlcený server requesty z pluginů třetích stran (tento problém se vyskytuje nejčastěji u webů postavených na open source systémech jako například WordPress).  

CLS (Cumulative Layout Shift) – metrika CLS zastupuje v uživatelské zkušenosti vizuální stabilitu a v jednoduchosti tedy stav, kdy po načtení prvních elementů webové stránky dochází ke změně jejich polohy.

Toto začali uživatelé vnímat zejména po příchodu cookie lišt, které někteří majitelé webových stránek umísťují v horní části stránky, ale načítají se až po zobrazení hlavního obsahu webu. To způsobí, že stránka se posune o výšku této cookie lišty směrem dolů a s ní i všechny elementy jako tlačítka, obrázky či text.

 Jaké jsou hraniční hodnoty Core Web Vitals?

Při stanovení těchto tří klíčových parametrů uživatelské zkušenosti z pohledu rychlosti načítání webových stránek bylo třeba definovat také přesné hraniční hodnoty.

To znamená, do jakého momentu považujeme danou metriku se splněnou a uživatelskou zkušenost uspokojenou, do jakého momentu je to akceptovatelné, ale existuje prostor pro zlepšení a od jakého momentu je metrika nesplněná a trpí uživatelská zkušenost. Tyto hraniční hodnoty nejlépe vyjadřuje obrázek přímo z nápovědy Google pro developery.

 

 Jak změřit Core Web Vitals?

Google věří, že Core Web Vitals mají významný vliv na uživatelskou zkušenost, a proto je zapracoval do všech hlavních analytických nástrojů pro vývojáře:

1. PageSpeed Insights
2. Google Serach Console (část Core Web Vitals report)
3. Google Lighthouse
4. Chrome User Experience Report

Pozor! Každý nástroj vám vygeneruje různé hodnoty, a dokonce jeden nástroj vám může vrátit mírně rozdílné výsledky i v několika po sobě jdoucích měřeních. To je způsobeno odlišnými způsoby měření těchto dat a zároveň je třeba mít na paměti neustále se měnící okolnosti jako zátěž na server, lokalitu serveru, který měření provádí nebo uložení některých dat do paměti cache.

To, na co byste se při optimalizaci těchto metrik měli zaměřit více než na finální hodnocení, je seznam doporučených řešení, jak zlepšit výsledky Core Web Vitals. Ty jsou napříč všemi nástroji velmi podobné, pokud ne totožné.

Výstup z měření rychlosti načítání webové stránky byt-in.sk prostřednictvím PageSpeed Insigts

Dosáhnout výborného hodnocení v těchto měřeních může být však poměrně náročné bez pomoci zkušeného programátora. Problém zároveň nastává, pokud nemáte možnost upravovat kód vaší webové stránky např. z důvodu, že využíváte nějaké „krabicové řešení“ jako například Wix, Squarespace či Atomer.

Jak optimalizovat Core Web Vitals?

Když už víme, co to Core Web Vitals jsou, známe hraniční hodnoty a dokážeme je změřit, je na místě otázka, co s tím můžeme udělat a jak dosáhnout lepších výsledků. 

V zásadě rozdělujeme optimalizaci Core Web Vitals do 3 částí:

• Optimalizaci obrázků 
• Optimalizaci zdrojového kódu
• Zvýšení výkonu serveru

Optimalizace obrázků

Výhodou této části je, že ji zvládne úplně každý, a to dokonce i ti, jejichž weby fungují na uzavřených systémech (krabicová řešení popsaná výše). V tomto případě můžete udělat 3 efektivní kroky:

• Nahrávání obrázků v přiměřeném rozměru

Když na web nahráváte obrázky a rozměr místa, ve kterém se mají zobrazit je například 300 x 300 pixelů, je dobré obrázek upravit právě na tento rozměr. Pokud tam totiž nahrajete obrázek o rozměru například 3000 x 3000 pixelů, dojde k tomu, že obrázek má větší datový objem a zároveň se při zobrazení stránky prohlížeč bude muset vypořádat se změnou rozměrů obrázku, v tomto případě s jeho zmenšením.

• Komprimace obrázků

Ve zkratce jde o minimalizaci datové velikosti obrázku při ztrátě jeho kvality do míry, která je akceptovatelná – to znamená, že si jí lidské oko nedokáže všimnout. Obecně se nejlépe komprimují JPEG obrázky. Komprimaci obrázku můžete provést buď přímo v některém z grafických nástrojů jako Adobe Photoshop nebo GIMP, případně dodatečně přes službu třetí strany jako například TinyPNG.

Existují rovněž nástroje a programy pro hromadnou kompresi více obrázků najednou, případně rozšíření do open source systémů jako WordPress, které spustí kompresi obrázku automaticky po jeho nahrání na server.

Já osobně v případě WordPressu doporučuji plugin Imagify, ale dobrých výsledků jsem dosahoval i s pluginy TinyPNG API nebo Smash.it. Pozor! Mnoho nástrojů nepodporuje komprimaci obrázku, který přesahuje velikost 5 MB.

• Zobrazování obrázků v novější generaci jako například WebP nebo AVIF.

Při aktuálním stavu zastoupení používaných prohlížečů spíše doporučuji formát WebP, který má širší podporu. Problém, kterému budete v tomto případě čelit je, že pokud nahrajete na web pouze obrázky ve formátu WebP a uživatel, který se na web připojil z webového prohlížeče, který nepodporuje tento formát obrázků, žádné obrázky neuvidí.

To lze technologicky řešit tak, že na webu máte oba formáty obrázků (WebP i PNG/JPEG/Gif atd.) a systém automaticky rozpozná, z jakého prohlížeče se uživatel připojuje, porovná jeho verzi prohlížeče s databází podporovaných prohlížečů a podle toho mu zobrazí obrázky v novější nebo starší generací formátů. V případě WordPress stránek tuto technologii můžete pokrýt právě zmiňovaným pluginem Imagify.

Optimalizace zdrojového kódu

V tomto případě je možností mnohem více v závislosti na technologiích a systémech, na kterých váš web funguje. Obecně při optimalizaci zdrojového kódu mluvíme zejména o optimalizaci JavaScriptových kódů, HTML, CSS a databází (např. MySQL).

Ověřenými a technicky nejjednodušeji implementovatelnými metodami jsou:

• Minifikace zdrojových kódů
• Odstranění nepoužívaných jazyků
• Oddálení načítání mimo obrazovku (tzv. Lazy Loading)
• Odstranění zdrojů blokujících vykreslení
• Promazání zbytečných údajů z databáze (např. průběžné ukládání, komentáře ve spamu nebo koši apod.)
• Přechod na HTTPS/2

Pokud vaše stránka běží na CMS systému WordPress, doporučuji využít placený plugin WP-Rocket, který používáme i na naší agenturní stránce Glidy.sk, ale i webových stránkách našich klientů. Tento plugin je sice zpoplatněn ročním poplatkem 44 € ročně (doporučuji nakupovat během BlackFriday) ale jeho implementace je velmi jednoduchá, rychlá a opravdu účinná.

Výsledek PageSpeed Insights webu glidy.sk pro mobilní i desktopové prohlížení

V případě, že chcete ušetřit, k dispozici jsou i bezplatné pluginy pro WordPress, jako například Hummingbird, Autoptimize nebo W3 total cashe. 

Zvýšení výkonu serveru

Zvýšení výkonu serveru z pohledu Core Web Vitals je asi nejnáročnější krok, jelikož vybrat dobrý server není jednoduché. Zpravidla je dobré umístit svůj web na dedikovaný server (sdílený server bývá cenově dostupnější, ale méně výkonný) a zároveň poblíž geolokace, ze které očekáváte návštěvníky.

Pokud máte web, na který chodí lidé z celého světa, tak doporučuji implementovat i řešení CDN (Content Delivery Network), což v jednoduchosti znamená, že vaše stránka není umístěna jen na jednom serveru, ale na více serverech různě po světě, přičemž uživatel stahuje webovou stránku právě ze serveru, který je k němu nejblíže.

Takové řešení nabízejí například hostingy od AWS (Amazon Web Services) nebo i různé třetí strany, které můžete napojit na váš stávající hosting, jako například RocketCND (služba od stejných vývojářů jako WP-Rocket nebo Imagify).

Další možností, jak zrychlit načítání stránky, je také změna DNS providera jako například využitím služby Cloudflare.

Core Web Vitals z pohledu SEO

Oznámení Core Web Vitals v roce 2020 udělalo velký rozruch i v kruzích SEO specialistů, a to zejména poté, co se v roce 2021 objevila v Google Search Console položka věnovaná právě Core Web Vitals.

Sám John Mueller z Google Search Central během pravidelného online setkání SEO specialistů z celého světa zvaného „Google SEO office-hours“ řekl, že Core Web Vitals mají přímý vliv na řazení výsledků ve vyhledávání Google. Zároveň však dodal: „Pokud je stránka A rychlejší než stránka B, avšak zároveň stránka B nabízí uživateli relevantnější výsledek, stále stránka B bude na vyšší pozici než stránka A“.

Z toho vychází, že kvalitní a relevantní obsah je stále důležitější metrikou než rychlost načítání. Ve více konkurenčním prostředí však stále platí, že u SEO nestavíme jen na jednu kartu a metriku. Proto musíme SEO budovat napříč všemi úrovněmi jako je obsah, linkbuilding, ale i právě zmíněné naplnění uživatelských očekávání od webu a tedy, že se uživateli stránka načte rychle a korektně.

Pár rychlých slov na závěr

Core Web Vitals jsou součástí komplexnějšího systému Web Vitals, do něhož kromě tří výše jmenovaných metrik (CLS, LCP, FID) spadají i další, jako například HTTPS nebo mobile friendly. Rychlost načítání webové stránky a její korektní ovládání vždy bylo a rovněž bude velmi důležitou součástí webových stránek.

Google však má obrovský vliv na to, jak dnešní internet vypadá a dokáže některá témata vytáhnout do popředí jen tím, že z nich udělá hodnotící SEO faktory. Optimalizovat rychlost načítání byste však stále měli dělat v první řadě pro uživatele, a nikoli z důvodu SEO.