Jak zrychlit web podle skutečných dat

Krátká odpověď: nejdřív měřit, potom opravovat

Pomalý web má vždycky konkrétní příčinu – těžký úvodní obrázek, skript, který blokuje vykreslení, pomalou odpověď serveru. Obecný seznam „deseti rad na zrychlení“ tu konkrétní příčinu většinou mine. Správný postup je změřit, přečíst výsledek a opravit to, co měření skutečně ukázalo. Tento článek Vás tím provede.

Pomalý web, nebo pomalé připojení?

Než začnete cokoli řešit: načítá se web pomalu víc lidem, nebo jen Vám? Pomalá Wi-Fi, slabý telefon nebo přetížený prohlížeč umí zpomalit každou stránku. Otevřete web na jiném zařízení nebo přes mobilní data – a když je pomalý i tam, čtěte dál.

Dva druhy měření – a který má přednost

Rychlost webu se měří dvěma zásadně odlišnými způsoby:

• Data skutečných návštěvníků (Google je sbírá anonymně z prohlížeče Chrome) říkají, jak rychle se web opravdu načítá lidem, kteří na něj chodí. Pokud existují, jsou to nejcennější čísla, která o webu máte.
• Laboratorní měření (Lighthouse, tedy i PageSpeed Insights) načte stránku jednou, v simulaci pomalého telefonu a pomalého připojení. Skvěle hledá příčiny – ale jeho čísla nejsou zkušenost Vašich návštěvníků.

Právě proto se laboratorní výsledek často zdá hrozivější než realita: simulace schválně škrtí připojení, takže obrázkově bohatá stránka v ní vychází pomaleji, než ji kdokoli skutečně vidí. Rozpor mezi oběma čísly není chyba měření – jen dvě různé otázky. My v auditu proto soudíme podle dat skutečných návštěvníků, kdykoli existují, a laboratorní běh používáme na diagnostiku.

Tři čísla, o která jde

Google shrnuje zkušenost návštěvníka do tří metrik zvaných Core Web Vitals – a u každé publikuje hranici, kterou považuje za dobrou:

• Zobrazení hlavního obsahu (LCP) – za jak dlouho se ukáže to podstatné. Dobré je do 2,5 sekundy.
• Odezva na interakci (INP) – jak rychle stránka reaguje na klik či ťuknutí. Dobré je do 200 milisekund.
• Stabilita rozvržení (CLS) – jestli obsah při načítání neposkakuje. Dobrá hodnota je do 0,1.

Hodnoty se posuzují na 75. percentilu návštěv – tedy tak, aby dobrou zkušenost měla velká většina lidí, ne jen ti s nejrychlejším telefonem. Zdroj: web.dev/vitals.

Náprava podle nálezu, ne podle checklistu

• Hlavní obsah se zobrazuje pozdě: podívejte se, co ten hlavní prvek je. Nejčastěji je to velká fotka nebo video – pak pomůže menší a modernější formát souboru a to, aby se klíčový obraz nenačítal až na konec. Když je pomalý už první příchod odpovědi, je řada na serveru a cache.
• Stránka reaguje líně: viníkem bývá náročný skript – často měřicí nebo widgetový kód třetí strany. Zjistěte, čemu soubor slouží, a teprve pak ho odkládejte nebo nahrazujte. Kód, který vypadá „nevyužitě“, nemažte naslepo – obsluhuje třeba menu nebo formulář, který měření zrovna nespustilo.
• Obsah poskakuje: obrázky, reklamy a vkládané prvky bez vyhrazeného místa. Náprava je obvykle levná – vyhradit prvkům rozměry předem.

Přesně tohle je práce, kterou za Vás udělá měření: náš audit pojmenuje konkrétní prvek hlavního obsahu, nejtěžší soubory i zdroje, které vykreslení blokují – takže opravujete adresně, ne odhadem.

Co když reálná data chybějí

Menší weby často nemají dost návštěv na to, aby o nich Google reálná data publikoval. To samo o sobě neznamená nic dobrého ani špatného – jen se musí soudit opatrněji. Poctivý postup je použít laboratorní běh jako diagnostiku, přiznat jeho podmínky a nevydávat simulaci za zkušenost lidí. Přesně tak to dělá i náš audit: když reálná data existují, mají přednost; když ne, řekne to.

Co rychlost znamená pro vyhledávání

Core Web Vitals patří mezi signály, ke kterým Google při řazení výsledků přihlíží – ale je jich mnohem víc a dobrá čísla přední pozici negarantují. Smysl zrychlování je především v návštěvnících: web, který se načte a reaguje svižně, méně lidí opustí dřív, než vůbec uvidí nabídku. Lepší pozice je případný bonus, ne slib.

Časté dotazy