Příručka marketéra: Jak řešit rychlost webu?

V předchozím článku jsme sumarizovali argumenty, proč se vůbec rychlostí zabývat. Víte tedy, že rychlost má vliv na KPI webů a díky Googlu i na jejich návštěvnost. Teď už tedy jen dostat návod na vylepšení rychlosti, že ano?

Dnes si tak dáme stručný přehled pro marketéry, majitele webů a podobné profese.

První tři kroky k řešení rychlosti: měřit, měřit a měřit

To už asi víte. U rychlosti obvykle nemusíte jít s měřením příliš do hloubky.

V první fázi vám úplně stačí Google PageSpeed Insights. To je něco jako „validátor“ rychlosti. Prostě si do něj občas dejte adresy důležitých stránek webu a poproste vývojáře, aby se podívali na výsledná doporučení. O plné skóre (100/100) usilovat nemusíte. Je to zbytečné a skoro vždy i nereálné. 80/100 na jedničku stačí.

A co Google Analytics? Údaje o rychlosti tam dostupné vám naopak nic moc neřeknou. Ukazují jen časy serveru a celkového načtení stránky. Tyto metriky bohužel nemají co dělat s uživatelskou spokojeností. Jsou to abstraktní, technická data. Prima na druhou stranu je, že v Analytics vidíte různé kontexty: jak pomalé jsou jednotlivé stránky nebo různé prohlížeče či zařízení. To už zajímavá informace je.

Lepší údaje vám poskytne Lighthouse – moderní nástroj pro technickou analýzu webů. Mimochodem od Googlu, což byste asi nečekali, že ano?

Ukázka výsledků nástroje Lighthouse

Ve výsledcích Lighthouse vás zajímá hlavně „Performance“. Zde je pak vidět způsob, jakým se váš web za daných podmínek vykresloval, což je důležitější než všechny metriky. A taky oči-otevírající. Jde o timeline, časovou osu vykreslování, ve které je zaznamenáno, jak se web uživateli postupně zobrazoval.

  • First Meaningful Paint
    Čas, kdy uživatel na stránce viděl obsah. Nižší je lepší. Ideál: do tří vteřin.
  • First Interactive
    Kdy je stránka připravená na uživatelské vstupy. Nižší je lepší. Ideál: nízké jednotky vteřin.
  • Perceptual Speed Index
    Asi neužitečnější číslo. Jak rychle došlo k plnému vykreslení stránky ve viditelné výseči obrazovky. Nižší je lepší. Ideál do 2 000 nebo s přimhouřením očí do 5 000 na výchozí rychlosti, což je pomalé 3G.

Mimochodem, o metrikách rychlosti načítání mám více informací na svém blogu.

Lighthouse vám ovšem, podobně jako PageSpeed Insights, dá doporučení, která můžete konzultovat s vývojáři.

Je ale dobré vědět, že ne všechna doporučení jsou snadno proveditelná. S vývojáři svých klientů se snažím hledat ta, která mají nejlepší poměr vlivu na vkreslování versus náklady.

Jak být v rychlosti lepší než konkurence?

Dovolím si vám dát čtyři rady:

1. Myslete na rychlost už v začátku projektu

V knize si stěžuji, jak nemám rád slovo slovo „optimalizace“, používané často ve spojení s webovými projekty. Abyste totiž museli „optimalizovat“, musíte to nejdříve pořádně pokazit. Stejné je to s „optimalizací rychlosti“.

Myslete na rychlost, už když projekt nebo změny v projektu plánujete. Stejně jako myslíte na marketing, přístupnosti, cílové skupiny a stejně jako když stanovujete KPI. Prostě rychlost plánujte.

2. Nastavte si rychlostní limity

Rychlostní limity (také „Speed Budget“ nebo „Performance Budget“) jsou maximální hodnoty metrik, kterých chcete u svého projektu dosahovat.

Předpokládám, že děláte nějakou analýzu konkurence. Změřte si také jejich rychlostní metriky. Tady je příklad:


Web First Byte Speed Index Page Load
mujweb.cz 1,205 s 10 542 12,5 s
konkurent1.cz 0,355 s 4 535 8,5 s
konkurent2.cz 1,105 s 8 500 9,5

Hledáte konkurenta, který má ve vašem oboru nejlepší rychlostní metriky.

Je prokázáno, že lidé jsou schopní rozeznat dvacetiprocentní a vyšší rozdíl v rychlosti načítání. Nejlepší čísla v ukázce vykazuje web „konkurent1.cz“.

Proto si pro vlastní web nastavte právě takto vylepšené cíle:


First Byte Speed Index Page Load
Cíl pro mujweb.cz 0,26 s 3 600 6,8 s

Více je v článku „How To Make A Performance Budget“ od Dana Malla.

3. Klíč pro zavedení kultury rychlosti je ve spolupráci s vývojáři

Říkám to pořád a tady to znovu rád zopakuji: zvěte vývojáře už na úvodní schůzky, kde přemýšlíte o řešení. Ukazujte jim wireframy, rozpracovanou grafiku. Ptejte se, jaké budou mít návrhy dopad i na rychlost načítání. Mimochodem, výhodu včasného zapojení vývojářů by vám potvrdil UX expert Jan Kvasnička, se kterým jsme to probírali v rámci podcastu.

Ne vždy vám náročnost řešení vývojáři dokáží říct hned. Vyhraďte si nějaký čas na prototypování řešení zaměřené na potenciálně rizikové části návrhů.

Nejčastější trable, které weby s rychlosti mívají

V rámci konzultací rychlosti jsem prošel docela dost českých a slovenských webů. Podívejme se teď spolu jejich nejčastějším chybám na zoubek. Poněkud zkažený zoubek.

1. Soubory s Javascripty blokují vykreslení stránky

Skripty externě vložené přes <script> bez parametru async nebo defer musí prohlížeč postupně stáhnout a spustit. Je to pak taková štafeta hlemýžďů. Poproste vývojáře, aby jich co nejvíce posílali s těmito dvěma parametry. Ty zajistí, že prohlížeč na ně s vykreslením stránky nemusí čekat.

2. Neoptimalizují obrázky

Datovou velikost JPEG obrázků neoptimalizujte běžně dostupnými řešeními. Doporučuji alespoň MozJPEG nebo výtečnou cloudovou sloužbu Kraken.io. Zvažte odložené načtení („lazy loading“) méně důležitých obrázků.

Nebo také použití formátu WebP. Když jej u klienta VašeČočky.cz nasadili pro podporující prohlížeče namísto JPEG, ušetřili 30 % datového objemu úvodní stránky (1250 kB → 950 kB) a o pětinu snížili čas pro Page Load (19,8 s → 16,8 s).

3. Neběží na HTTP/2

HTTP/2 je nová, rychlejší verze protokolu. Je zpětně kompatibilní, takže s ní nemají problémy ani starší prohlížeče. A všechny moderní prohlížeče ji už umí.

4. Měřící a A/B testovací služby: pokud je zrovna nepoužíváte, vypínejte je

Marketéři a majitelé webů – tady mám na vás velkou prosbu. Velmi zvažujte, které skripty do stránky dáváte. Každý HotJar, každé Optimizely, každá další služba stahuje nemalý objem dat a velmi často na čas zcela zastaví vykreslování stránky. Ano, vím, měřit je potřeba, ale navrhuji minimálně dvě věci:

  • Poproste vývojáře o analýzu možností optimalizace vkládání těchto skriptů.
  • Pokud skripty nepotřebujete, odstraňujte je. Vsadím se, že nepotřebujete měřit a testovat pořád a všechny.

A jsme v závěru. Jak tedy zatočit s pomalými weby? Začněte analýzou přes PageSpeed Insights, pak přejděte na Lighthouse. Změřte si konkurenci a buďte alespoň o pětinu rychlejší než oni. Opravné kroky si nechte doporučit od analytických nástrojů. A do rozhodovacícho procesu zapojte vývojáře. Děkuji vám za pozornost a přeji rychlé weby.

Diskuze k článku