Proč je mobilní rychlost dnes tvrdší filtr než desktop
Na mobilu nehraje roli jen samotná rychlost serveru. Uživatelé bývají na pomalejší síti, zařízení mají méně výkonu a Google navíc hodnotí stránku optikou mobile-first indexace. To znamená, že primárně posuzuje mobilní verzi webu, ne tu desktopovou. Pokud se na telefonu načítá pomalu, rozpadá se layout nebo je obsah dostupný až po několika sekundách, ztrácíte jak pozice, tak návštěvnost a často i konverze.
Google dnes u výkonu sleduje hlavně signály z Core Web Vitals. V praxi jde o tři oblasti: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) a CLS (Cumulative Layout Shift). Pro mobily je důležité, že i malý problém se násobí: jeden těžký obrázek, přetížený JavaScript nebo pozdě načtený font může způsobit, že stránka působí „mrtvě“ i na jinak dobrém webu.
Co Google na mobilech trestá nejvíc
Nejde o jediný faktor, ale o kombinaci technických chyb, které zhoršují uživatelský zážitek. Níže jsou nejčastější problémy, které v auditovaných webech vidím opakovaně:
- Pomalý LCP – hlavní obsah se objeví až po 3,5–5 sekundách a více.
- Vysoký INP – web sice „nějak“ načte, ale tlačítka, menu nebo formuláře reagují se zpožděním.
- CLS – poskakující bannery, reklamy, cookie lišty nebo obrázky bez vyhrazené velikosti.
- Těžký JS balík – přemíra skriptů blokuje vykreslení a zhoršuje interaktivitu.
- Nevhodné obrázky – příliš velké soubory, chybějící WebP/AVIF, absence lazy loadingu.
- Mobilní UX chyby – malé klikací plochy, text mimo viewport, překryté prvky.
Typický příklad: e-shop s homepage o velikosti 6 MB, třemi reklamními pixely, chat widgetem a hero obrázkem v původním rozlišení 4000 px. Na desktopu to „nějak projde“, ale na mobilu se LCP dostane nad 4 sekundy a INP se zhorší kvůli skriptům třetích stran. Výsledek? Google stránku nepenalizuje jedním přímým trestem, ale v praxi ji znevýhodní proti rychlejším konkurentům.
Jaké metriky sledovat a jak poznat problém
Nejdůležitější je oddělit laboratorní a reálná data. Laboratorní měření ukáže, co je technicky špatně, ale reálná data z uživatelů prozradí, co se děje na skutečných mobilech s různým výkonem a sítí.
Core Web Vitals doporučené cíle:
- LCP: do 2,5 s
- INP: do 200 ms
- CLS: do 0,1
Pro diagnostiku použijte kombinaci nástrojů:
- Google Search Console – report Core Web Vitals pro reálné URL.
- PageSpeed Insights – rychlý přehled problémů a doporučení.
- Lighthouse v Chrome DevTools – laboratorní audit a seznam blokujících prvků.
- WebPageTest – detailní waterfall, filmstrip a test na různých rychlostech připojení.
- Chrome DevTools Performance – hledání dlouhých úloh, blokujícího JavaScriptu a reflow.
- GA4 – doplnění o dopady na konverze, bounce rate a engagement.
Praktický postup: v Search Console si otevřete skupiny URL s problémem, pak jednu reprezentativní stránku projděte v PageSpeed Insights a následně ve WebPageTest porovnejte mobilní 4G profil. Pokud je LCP způsobené obrázkem, uvidíte to v waterfallu velmi rychle. Pokud je problém v INP, bývá viníkem JavaScript, často třetí strany nebo příliš těžká interakce v šabloně.
Co zrychluje mobilní web nejefektivněji
Největší efekt obvykle nepřináší „kosmetické“ ladění, ale zásah do nejdražších částí stránky. Priorita by měla být následující:
1. Optimalizace obrázků
Obrázky bývají největší položkou na mobilu. Používejte moderní formáty WebP nebo AVIF, správně dimenzované varianty přes srcset a sizes a u obrázků pod ohybem lazy loading. U hero obrázku naopak lazy loading nepoužívejte – ten je často součástí LCP.
Typická úspora: z 800 kB na 120–200 kB u jednoho hlavního vizuálu. U e-shopu s desítkami produktů to znamená zásadní rozdíl v načítání kategorií i detailů.
2. Ořezání JavaScriptu
Každý skript na mobilech něco stojí. Zvažte, zda potřebujete chat widget, heatmapy, všechny reklamní a remarketingové tagy hned po načtení. Mnoho webů má problém v tom, že skripty třetích stran blokují hlavní thread. Pomáhá:
- odložené načítání přes defer nebo async,
- podmíněné načítání jen na relevantních stránkách,
- odstranění nepoužívaných knihoven,
- code splitting v moderních frameworkách jako Next.js.
Pokud máte v DevTools dlouhé úlohy nad 50 ms, INP se obvykle zhoršuje. Na mobilu je cílem rozdělit těžké operace na menší části a minimalizovat práci při prvním vykreslení.
3. Stabilní layout a prevence CLS
Google trestá stránky, které „skáčou“. Nejčastější viníci jsou obrázky bez rozměrů, pozdě načtené reklamy, cookie lišty a dynamické bloky v horní části stránky. Každému prvku vyhraďte prostor ještě před načtením obsahu. U bannerů a embedů nastavujte pevné boxy, u fontů použijte font-display: swap a zvažte preload důležitých řezů písma.
Reálný dopad bývá výrazný: snížení CLS z 0,25 na 0,05 často zlepší nejen UX, ale i míru prokliků na mobilu, protože uživatel neztratí důvěru při klikání.
Mobilní UX, které Google i uživatelé vnímají okamžitě
Rychlost sama o sobě nestačí, pokud je web na mobilu nepoužitelný. Google dlouhodobě preferuje stránky, které jsou čitelné, snadno ovladatelné a bez technických překážek. Sledujte zejména tyto body:
- Text bez zoomování – písmo minimálně 16 px pro běžný obsah.
- Dostatečné rozestupy – klikací plocha alespoň kolem 44 × 44 px.
- Žádné horizontální scrollování – obsah musí sedět do viewportu.
- Viditelné CTA – hlavní akce musí být dostupná bez zbytečného scrollu.
- Formuláře pro mobil – správné typy polí, automatické doplňování, minimum kroků.
V praxi se často stává, že stránka má skvělý PageSpeed score, ale reálně prodává hůř, protože tlačítko „Přidat do košíku“ je pod záhybem nebo se překrývá sticky lištou. Proto je dobré propojovat technická data s behaviorálními metrikami v GA4: míra scrollu, kliky na CTA, dokončení formuláře a konverzní poměr na mobilech.
Jak si nastavit pravidelnou kontrolu, aby mobilní výkon nepadal zpět
Optimalizace výkonu není jednorázový úkol. Každý nový plugin, marketingový skript nebo redesign může situaci zhoršit. Proto doporučuji nastavit jednoduchý proces:
- Měsíčně kontrola Search Console a PageSpeed Insights u klíčových šablon.
- Při každém release test v Lighthouse a ruční kontrola na skutečném telefonu.
- Po nasazení nových nástrojů měření dopadu na INP a LCP.
- U e-shopů sledování kategorií, produktových detailů a checkoutu zvlášť.
U větších webů se vyplatí vytvořit „performance budget“: například homepage do 1,5 MB, JS do 250 kB na první load, LCP pod 2,5 s na 4G profilu. Jakmile tým překročí limit, je jasné, že se musí něco odstranit nebo přepsat. Tím se výkon přestane řešit až ve chvíli, kdy už klesají pozice nebo konverze.
Pro weby na WordPressu bývá největší přínos v omezení pluginů, cache vrstvě, optimalizaci šablony a kvalitním hostingu. U moderních frontendů v Next.js nebo podobných frameworkách zase rozhoduje správné rozdělení bundle, server rendering a práce s third-party skripty. Ať už používáte jakýkoli stack, na mobilech platí stejné pravidlo: co není nutné pro první interakci, nemá se načítat hned.