Jak zrychlit web: proč na tom záleží a co reálně funguje

Web zrychlíte ve třech krocích: změříte, kde návštěvník čeká (server, obrázky, nebo JavaScript), opravíte největší brzdu a výsledek ověříte stejným měřením. Nejvíc času obvykle ušetří správně zmenšené obrázky, méně skriptů třetích stran a zapnutá cache. Pomalé načtení a opožděná reakce formuláře jsou přitom dva různé problémy, proto každý řeším jinak.

Proč na rychlosti záleží

Pomalý web zdržuje zákazníka ve chvíli, kdy se rozhoduje. Kliká na službu, hledá cenu nebo odesílá poptávku, a každé čekání mu dává důvod odejít ke konkurenci. Kolik vás to stojí právě u vás, zjistíte v analytice: porovnejte konverze na mobilu a desktopu a na rychlých a pomalých stránkách.

Core Web Vitals hodnotí načítání (LCP), odezvu interakcí (INP) a vizuální stabilitu (CLS). Google je měří na 75. percentilu skutečných návštěv, odděleně pro mobil a desktop (definice a metodika):

Rychlost a pozice v Googlu. Podle Googlu Core Web Vitals používají jeho systémy hodnocení, relevantní obsah ale vyhraje i se slabší rychlostí. Rychlost tedy nevynahradí dobrý obsah, ale u vyrovnané konkurence pomáhá a hlavně zlepšuje to, co se stane po kliknutí.

Odezva pomáhá dokončit úkol. Zkoušejte vyhledávání, otevření nabídky a odeslání formuláře. Samotné skóre rychlosti neříká, jestli se zákazník k poptávce opravdu dostane.

Jak rychlost změřit (zdarma, za minutu)

Na hledání příčiny pak sáhněte po dalších nástrojích:

Proč mám v PageSpeed dobré skóre, a web je přesto pomalý?

Protože skóre je laboratorní test jedné návštěvy. PageSpeed Insights podle dokumentace Googlu simuluje mobil jako jedno zařízení na mobilní síti, kdežto data skutečných návštěv (Chrome UX Report) shrnují posledních 28 dní z různých telefonů a připojení. Pomalý telefon zákazníka, přihlášený účet, plný košík nebo reklamní skripty spuštěné až po souhlasu s cookies laboratoř nezachytí. Rozhoduje proto sekce s daty návštěvníků a Search Console; skóre 90+ je dobrý začátek, ne cíl.

Co web nejčastěji brzdí (a jak to spravit)

1. Obrázky: velikost souboru a okamžik načtení

Obrázky jsou nejčastější a nejlevnější oprava. Fotka z telefonu má běžně několik megabajtů a tisíce pixelů, na webu se přitom zobrazí v šířce stovek pixelů. Postup, který používám:

• Zmenšit na zobrazenou velikost a přes srcset posílat mobilu menší variantu než desktopu.
• Převést do WebP nebo AVIF a výsledek porovnat na stejné fotce (ukázka níže ušetřila přes 330 kB).
• Lazy loading jen pod úvodní obrazovkou. Hlavní obrázek (LCP) naopak načtěte co nejdřív, s fetchpriority="high".
• Uvést šířku a výšku, aby obrázek při načtení neposouval text (CLS).

2. Přebujelý JavaScript a pluginy

V síťovém panelu a profileru zjistěte, které skripty se stahují a které blokují hlavní vlákno. Počet pluginů není měření jejich náročnosti: některé běží jen na serveru nebo v administraci. Odstraňte nevyužitou funkci a ověřte, že zůstalo funkční měření, formuláře i souhlasy. Jeden tag manager také může spouštět mnoho dalších skriptů.

3. Odezva serveru a sítě

TTFB (doba do prvního bajtu) zahrnuje výpočet na serveru, síť, přesměrování i navázání spojení. Za dobrou hodnotu považuje Google zhruba do 0,8 s (metodika TTFB). Když je TTFB vysoké, porovnejte cachovaný a necachovaný požadavek: rychlá odpověď z cache a pomalá bez ní ukazuje na výpočet stránky (databáze, pluginy), pomalá v obou případech na hosting nebo síť. U hostingu se vyplatí ověřit aktuální verzi PHP (u WordPressu), HTTP/2 nebo HTTP/3 a kompresi Brotli nebo gzip. Zbytečná přesměrování (http → https → www) zdrží každou návštěvu, tak je zkraťte na jedno.

4. Webové fonty a externí skripty

Každý font a každý skript třetí strany (mapy, videa, chat, widgety) je další čekání. U fontů pomáhá:

• Formát WOFF2 a jen řezy, které opravdu používáte (1-2 rodiny, případně jeden variabilní font).
• font-display: swap, aby se text zobrazil hned systémovým písmem a nečekal na font (doporučení web.dev).
• Vlastní hosting fontu místo načítání z cizího serveru, pokud web běží na CDN.

Mapy a videa vkládejte jako náhled, který skutečný přehrávač načte až po kliknutí. Chatovací widget stačí spustit po interakci nebo s odstupem po načtení.

5. Chybějící cache a CDN

Cache ukládá hotové stránky a soubory, aby se nemusely pokaždé počítat a stahovat znovu. Statické soubory (obrázky, CSS, JavaScript s otiskem verze v názvu) můžou mít v prohlížeči dlouhou platnost, HTML stránky kratší s ověřením změny. CDN pak obslouží obsah ze serveru blíž návštěvníkovi. Pozor jen na přihlášené účty, košík a osobní data: ty do veřejné cache nepatří.

6. Pomalá reakce po kliknutí (INP)

Stránka se načte, ale po kliknutí na menu, filtr nebo tlačítko chvíli nic nedělá. Příčinou bývají dlouhé úlohy JavaScriptu, které blokují hlavní vlákno prohlížeče. Podle návodu web.dev k INP pomáhá:

• rozdělit dlouhou práci po kliknutí na menší části a nejdřív zobrazit odezvu (třeba otevřené menu), teprve potom zbytek;
• odložit skripty, které nejsou potřeba hned (analytika, chat, A/B testy, reklamní pixely);
• zmenšit DOM: tisíce prvků na stránce zpomalí každé překreslení;
• v panelu Performance najít, který skript při kliknutí běží nejdéle.

INP je typický problém e-shopů s mnoha marketingovými skripty a webů postavených na těžkých page builderech.

Jak zrychlit web na WordPressu

WordPress zpomalují nejčastěji tři věci: žádná cache stránek, neoptimalizované obrázky a nahromaděné pluginy nebo těžký page builder. Bez programátora zvládnete:

1. Zapnout cache stránek, buď na hostingu, nebo jedním cachovacím pluginem (ne dvěma najednou).
2. Optimalizovat obrázky pluginem, který při nahrání zmenší rozměry a vytvoří WebP.
3. Projít pluginy: vypnout nepoužívané a u zbytku v Lighthouse ověřit, kolik JavaScriptu a CSS přidávají na každou stránku.
4. Aktualizovat PHP na verzi, kterou hosting a WordPress podporují. Verze po skončení podpory už nedostávají bezpečnostní opravy (přehled podporovaných verzí PHP) a novější verze bývají i rychlejší.
5. Omezit externí fonty a vložená videa podle bodu 4 výše.

Pokud ani potom web na mobilu nezrychlí a většinu času spotřebuje šablona nebo page builder, další ladění bývá dražší než výměna šablony.

Kontrolní seznam: 10 bodů rychlého webu

1. Hlavní obrázek se načítá hned, ostatní líně.
2. Fotky jsou zmenšené na zobrazenou velikost a ve WebP nebo AVIF.
3. Obrázky a vložené prvky mají rozměry, nic neposkakuje.
4. Server odpovídá do 0,8 s, stránky jdou z cache.
5. Jen jedno přesměrování (nebo žádné) na cestě k URL.
6. Komprese Brotli nebo gzip a HTTP/2 či HTTP/3.
7. Nejvýš 1-2 rodiny fontů ve WOFF2 s font-display: swap.
8. Skripty třetích stran jsou odložené a pravidelně procházené.
9. Mapy, videa a chat se načítají až po kliknutí.
10. Core Web Vitals hlídáte v Search Console a po každé větší změně je přeměříte.

Kdy nestačí ladit a je čas na přestavbu

Mobilní skóre pod 40 nebo LCP přes 4 sekundy po úpravě obrázků ještě samo neznamená nový web. Nejprve profilujte problematickou URL: server, požadavky, hlavní vlákno, načtení největšího prvku a skripty třetích stran. Když brzdí základ (šablona, page builder, systém), porovnejte cenu dalšího ladění s přestavbou včetně migrace a testování. Volbu technologie vysvětluji v článku proč Next.js pro firemní web; rychlý web stojí hlavně na tom, jak je postavený, ne na názvu frameworku.

Optimalizace rychlosti webu: jak ji dělám u klientů

Když optimalizaci rychlosti webu dělám já, postupuju vždy ve stejném pořadí, aby se práce nerozpadla na náhodné úpravy:

Jednorázovou optimalizaci počítám hodinovou sazbou 1 500 Kč/h a rozpočet potvrdím předem podle výchozího měření. Průběžně ji řeším v rámci správy webu: tarif Růst za 9 990 Kč měsíčně má optimalizaci Core Web Vitals přímo v rozsahu. Ceny všech paušálů rozebírám v článku kolik stojí správa webu.

Časté otázky

Jaká rychlost webu je dobrá?

Cílem jsou dobré Core Web Vitals u skutečných návštěvníků: největší prvek do 2,5 s (LCP), reakce na klik do 200 ms (INP) a stabilita do 0,1 (CLS), a to na mobilu, kde je web obvykle nejpomalejší. Skóre v PageSpeed Insights je pomůcka pro ladění, ne cíl.

Ovlivňuje rychlost webu pozice v Googlu?

Ano, ale omezeně. Google uvádí, že Core Web Vitals jeho systémy hodnocení používají, relevantní obsah ale ukáže i na pomalejší stránce. Větší dopad má rychlost na to, kolik návštěvníků po kliknutí opravdu dokončí nákup nebo poptávku.

Jaký vliv má hosting na rychlost webu?

Hosting určuje hlavně dobu odpovědi serveru (TTFB). Přetížený sdílený hosting nebo vzdálený server se projeví na každé stránce. Když je ale TTFB v pořádku a web je pomalý, výměna hostingu nepomůže; brzdí obrázky, skripty nebo šablona.

Jak zrychlit web bez technických znalostí?

Zmenšete a převeďte obrázky (na WordPressu pluginem), zapněte cache stránek, odstraňte nepoužívané pluginy a vložená videa nahraďte náhledem. Tyto kroky zvládnete z administrace a bývají největší částí zrychlení.

Kolik stojí optimalizace rychlosti webu?

U mě jednorázově 1 500 Kč/h s rozpočtem potvrzeným předem; menší web s běžnými problémy (obrázky, cache, skripty) bývá otázkou několika hodin. Průběžné hlídání a optimalizace jsou v tarifu Růst správy webu.

Shrnutí

Začněte měřením konkrétních stránek v PageSpeed Insights a odlište laboratorní běh od dat návštěvníků. Pořadí oprav určete podle příčiny: obrázky, skripty, server, fonty nebo cache. Obrázky mimo úvod načítejte líně, hlavní obrázek co nejdřív. Po zásahu měření zopakujte ve srovnatelných podmínkách; o přestavbě rozhoduje to, co web brzdí, a cena opravy, ne jediné skóre.

Nechcete to řešit sami? Rychlost hlídám jako součást správy webu, měření, optimalizace i pravidelná údržba. A když web hoří a potřebujete pomoc hned, je tu expresní pomoc.