Google dnes rychlost neřeší jen jako technický parametr

Vyhledávač sice nikdy neřekl, že pomalý web automaticky „potrestá“ jedním jasným filtrem, praxe ale ukazuje něco důležitějšího: rychlost je součástí hodnocení kvality stránky i uživatelské zkušenosti. Google pracuje s metrikami Core Web Vitals, sleduje odezvu webu na mobilu a vyhodnocuje, zda stránka působí stabilně, rychle a použitelně. Pokud ne, dopad se obvykle projeví nepřímo — horším engagementem, nižší konverzí a slabším výkonem v organiku.

Podle různých měření opouští významná část návštěvníků stránku, pokud se nenačte v prvních několika sekundách. U e-commerce se navíc každá prodleva počítá dvojnásob: zpomalení o jednu sekundu může snížit konverzní poměr o jednotky až desítky procent podle typu webu a kvality provozu. To je důvod, proč rychlost není jen „nice to have“, ale přímý obchodní faktor.

Největší brzda bývá v obrázcích a médiích

V praxi weby nejčastěji brzdí neoptimalizované obrázky. Jde o klasický problém: na stránce je několik fotografií v plné velikosti, často nahraných přímo z mobilu nebo z grafického editoru bez komprese. Jeden banner o velikosti 3–5 MB dokáže prodloužit načítání víc než desítky drobných technických úprav.

Co je potřeba hlídat:

  • Formát souboru – pro fotografie většinou WebP nebo AVIF, pro grafiku podle potřeby PNG/SVG.
  • Rozlišení – nahrávat přesně tak velké obrázky, jaké web skutečně zobrazuje, ne 4000 px široké fotografie do náhledu o šířce 800 px.
  • Komprese – ideálně automatická při uploadu, u WordPressu například přes pluginy typu ShortPixel, Imagify nebo Smush.
  • Lazy loading – načítat až obrázky pod přehybem stránky, ale ne hlavní hero prvek, který ovlivňuje LCP.

Typický problém je také video na pozadí nebo neřízené vložené prvky z externích služeb. Jedno autoplay video bez zpracování může přidat stovky kilobajtů až jednotky megabajtů a výrazně zhoršit LCP. U webů s vyšším podílem mobilní návštěvnosti je to často nejdražší chyba vůbec.

Příliš mnoho skriptů a pluginů zpomaluje víc, než se zdá

Druhá velká brzda je JavaScript, CSS a vše, co se načítá navíc. Čím více nástrojů na web přidáte, tím větší je riziko, že se budou navzájem blokovat nebo prodlužovat vykreslení stránky. To platí u WordPressu, ale stejně tak u custom webů, které postupně nabobtnaly o analytiku, chat, remarketing, heatmapy, cookie lišty, A/B testy a desítky dalších integrací.

Nejčastější viníci v praxi:

  • příliš mnoho pluginů na WordPressu, i když „každý dělá jen jednu malou věc“;
  • externí skripty z reklamních a marketingových platforem;
  • neoptimalizované fonty načítané z více řezů a bez preloadu;
  • blokující CSS, které brání vykreslení nad přehybem;
  • těžký tag manager, kde je v jedné nádobě naskládaných 20 měřicích a marketingových kódů.

Praktický příklad: web má na první pohled jednoduchou homepage, ale v pozadí načítá 12 externích skriptů. Každý z nich sám o sobě přidá třeba jen 50–150 ms, jenže dohromady z toho jsou sekundy. Navíc některé skripty blokují hlavní thread prohlížeče, což zhoršuje INP — tedy dobu odezvy na interakci. To je problém zejména na mobilech.

Užitečné je projít web přes Chrome DevTools, Lighthouse, PageSpeed Insights nebo WebPageTest a podívat se, co skutečně blokuje render. Nejde jen o počet požadavků, ale hlavně o to, co dělají v kritické fázi načítání.

Špatně nastavený hosting, TTFB a databáze udělají z webu brzdu

Mnoho majitelů webů řeší obrázky a přitom přehlíží serverovou část. Pokud je pomalá odpověď serveru, nepomůže ani perfektně zkomprimovaný web. TTFB, tedy doba do první odezvy serveru, bývá u pomalých webů zásadní slabina. Když je server přetížený, špatně nakonfigurovaný nebo běží na levném sdíleném hostingu, stránka začne „viset“ ještě před tím, než se vůbec začne vykreslovat.

Na co se zaměřit:

  • kvalita hostingu – levný sdílený hosting často nestačí pro návštěvnost, WooCommerce ani větší obsahové weby;
  • PHP verze – staré verze jsou pomalejší a bezpečnostně slabší;
  • cache – bez serverové cache se generuje každá stránka zbytečně znovu;
  • databáze – přetížené tabulky, revize, transients a zbytky pluginů zpomalují dotazy;
  • CDN – u mezinárodních nebo mediálně bohatých webů výrazně snižuje latenci.

U WordPressu je častý scénář jednoduchý: web má mnoho článků, několik let starý hosting a desítky pluginů. Výsledek? Domovská stránka se načítá relativně rychle, ale detail článku nebo produktová stránka je pomalá, protože server musí provádět mnoho dotazů do databáze. V takovém případě pomůže kombinace cache pluginu, optimalizace databáze, aktualizace PHP a přesun na kvalitnější hosting.

U e-shopů je navíc potřeba hlídat i výkon při filtrování a vyhledávání. Každý produktový filtr, který generuje náročný SQL dotaz, může zpomalit nejen konkrétní uživatele, ale i crawling ze strany robotů.

Neviditelný problém: web může být rychlý na desktopu, ale pomalý na mobilu

Google dnes hodnotí web hlavně z pohledu mobilního uživatele. To znamená, že „na mém notebooku to běží dobře“ nestačí. Mobilní zařízení mají slabší CPU, horší připojení a menší toleranci k těžkým stránkám. Právě tady se ukazuje rozdíl mezi průměrným a skutečně optimalizovaným webem.

Typické chyby mobilní verze:

  • stejný objem dat jako na desktopu, jen menší obrazovka;
  • příliš velké hero sekce a slider hned nahoře;
  • fonty a skripty bez prioritizace;
  • obsah pod přehybem, který je sice na stránce, ale načítá se až později;
  • rozsáhlé animace a efekty, které zbytečně zatěžují procesor.

Pro rychlé ověření je vhodné měřit v PageSpeed Insights a sledovat hlavně LCP, INP a CLS. Pokud je LCP nad 2,5 sekundy, web už je z pohledu Core Web Vitals problémový. U INP by měla být odezva co nejnižší, ideálně v řádu desítek až nízkých stovek milisekund. CLS by měl být co nejblíže nule, protože poskakující obsah ničí UX i důvěru.

Dobrá praxe je testovat web na reálném telefonu přes pomalejší síť, ne jen v kancelářském gigabitovém připojení. Mnoho problémů se objeví až v terénu: obrázky se dočítají pozdě, cookie lišta posouvá obsah nebo se tlačítko „Koupit“ odsunuje pod fold v okamžiku, kdy uživatel chce kliknout.

Co udělat jako první, když chcete web zrychlit

Pokud je web pomalý, nezačínejte slepě instalovat další pluginy. Nejprve zjistěte, kde přesně vzniká zdržení. Praktický postup vypadá takto:

  • změřte stav v PageSpeed Insights, Lighthouse a WebPageTest;
  • porovnejte mobil a desktop, protože slabina bývá často jen na mobilu;
  • zjistěte TTFB a zda problém vzniká na serveru nebo v prohlížeči;
  • projděte mediální obsah a zmenšete největší soubory;
  • omezte externí skripty na ty, které mají jasný obchodní přínos;
  • zjednodušte pluginovou výbavu a odstraňte duplicity;
  • zaveďte cache a CDN, pokud web dorůstá návštěvnosti nebo objemu obsahu.

Nejrychlejší návratnost obvykle přináší optimalizace obrázků, odstranění zbytečných skriptů a kvalitnější hosting. U větších webů pak výrazně pomůže i technická revize šablony, databáze a načítání fontů. V praxi se často ukáže, že 20 % zásahů odstraní 80 % zpomalení.

Google pomalé weby netrestá jedním tlačítkem, ale v součtu signálů, které z nich dělají horší výsledek pro vyhledávání i pro byznys. Kdo rychlost podcení, platí za to nižší návštěvností, slabší konverzí a horší konkurenceschopností. Kdo ji řeší systematicky, získá výhodu, kterou konkurence často podceňuje právě proto, že není na první pohled vidět.