Jak rychle zjistím, jestli je můj web pomalý? Nástroje a postup krok za krokem

Rychlost webu ověříte za méně než 5 minut s bezplatnými nástroji. Otevřete PageSpeed Insights od Googlu, vložte URL vaší stránky a klikněte na Analyze. Výsledek ukáže skóre 0-100 - skóre pod 50 znamená vážný výkonnostní problém, 90 a více je cíl. Pro každý web testujte zvlášť mobilní i desktopovou verzi, protože Google indexuje primárně mobilní verzi stránky. V tomto článku projdeme přesný postup od prvního testu po konkrétní kroky k opravě nejčastějších problémů.

Pokud jste ještě nečetli, co jsou Core Web Vitals a proč na nich záleží, doporučuji začít tam - najdete tam přesné definice LCP, INP a CLS bez žargonu. Tento článek předpokládá, že víte, co měříte, a zaměřuje se na to, jak to změřit a co s výsledky udělat.

Proč na rychlosti webu záleží i pro SEO, nejen pro zákazníka

Google hodnotí rychlost webu jako přímý rankingový signál od roku 2021 prostřednictvím Core Web Vitals - pomalý web proto nejenže odrazuje návštěvníky, ale přímo klesá v organickém vyhledávání.

V roce 2024 Google nahradil metriku FID (First Input Delay) metrikou INP (Interaction to Next Paint), čímž ještě více posílil důraz na interaktivitu stránky. To znamená, že starší audit z roku 2022 nebo 2023 nemusí odrážet dnešní stav vašeho webu - INP se měří jinak a starý web s dobrým FID může dnes na INP selhávat.

Kromě SEO má rychlost přímý vliv na konverzi. Mobilní sítě na Slovensku jsou relativně rychlé, ale procesory mobilních zařízení jsou slabší než na desktopu - web musí zvládnout i středně výkonný Android telefon, nejen MacBook připojený na Wi-Fi. Web, který se načte za 6 sekund na mobilu, je v praxi nepoužitelný pro většinu návštěvníků.

Krok 1: PageSpeed Insights - první a nejrychlejší test rychlosti webu

PageSpeed Insights je bezplatný nástroj od Googlu a správný začátek každé analýzy rychlosti - poskytuje lab data i reálná field data od návštěvníků vašeho webu.

Dostupný na pagespeed.web.dev. Kombinuje dvě vrstvy dat:

• Lab data (Lighthouse) - syntetický test spuštěný v kontrolovaném prostředí; vždy dostupný, ideální pro porovnání před a po optimalizaci
• Field data (CrUX) - reálné metriky od skutečných návštěvníků vašeho webu z prohlížeče Chrome za posledních 28 dní; dostupné jen pokud web dostává dostatek návštěvnosti

Pokud váš web dostává málo návštěvnosti, CrUX data nebudou k dispozici - v tom případě se spoléhejte výhradně na lab data.

Postup:

1. Otevřete pagespeed.web.dev
2. Vložte URL vaší hlavní landing page (ne nutně homepage - testujte stránku, která prodává)
3. Klikněte na Analyze
4. Prohlédněte si výsledky zvlášť pro Mobile a zvlášť pro Desktop - vždy oba

Skóre	Stav	Praktický dopad
90-100	Zelená - dobrý výkon	Web je rychlý, CWV pravděpodobně v normě
50-89	Oranžová - potřebuje zlepšení	Viditelná pomalá místa, ale ne katastrofa
0-49	Červená - špatný výkon	Kritický stav, přímý negativní vliv na SEO i konverzi

Většina SK prezentačních webů postavených na komerčních šablonách s několika page-builder pluginy padá při mobilním testování do oranžového nebo červeného pásma.

Krok 2: Čtení výsledků PageSpeed Insights - co sledovat jako první

Z výsledků PageSpeed Insights sledujte především hodnoty Core Web Vitals a sekci Diagnostics - tam najdete konkrétní problémy seřazené podle vlivu na výkon.

Prahové hodnoty Core Web Vitals podle web.dev/vitals (oficiální dokumentace Google):

• LCP (Largest Contentful Paint) - kdy se načte hlavní vizuální prvek stránky. Dobré: méně než 2,5 sekundy. Špatné: více než 4 sekundy.
• INP (Interaction to Next Paint) - jak rychle stránka reaguje na kliknutí nebo stisk klávesy. Dobré: méně než 200 milisekund. Špatné: více než 500 milisekund.
• CLS (Cumulative Layout Shift) - míra nechtěného posouvání prvků při načítání. Dobré: méně než 0,1. Špatné: více než 0,25.

V sekci Diagnostics hledejte především:

• Render-blocking resources - soubory JavaScriptu nebo CSS, které blokují zobrazení stránky před dokončením načítání
• Unused JavaScript / Unused CSS - kód, který se stáhne, ale nepoužije; typické pro weby s page-buildery
• Images not properly sized - obrázky větší, než je web ve skutečnosti zobrazuje; zbytečně zaberou bandwidth
• Large network payloads - celková velikost stránky; orientačně pod 2 MB je zdravé

První dva problémy - render-blocking a unused JavaScript - jsou typicky největší problém u webů postavených na Elementoru, Divi nebo WPBakery. O tom, proč a jak z takového řešení vystoupit, jsme psali v článku Migrace z Elementoru: jak přejít na čistou WordPress šablonu.

Krok 3: GTmetrix pro hlubší diagnostiku - kde se ztrácí čas

GTmetrix nabízí podrobnější pohled než PageSpeed Insights, včetně waterfall grafu a testu z evropských serverů - což dává reálnější obraz pro slovenské návštěvníky.

Bezplatný účet na gtmetrix.com umožní testovat z různých geografických lokalit. To je důležité: PageSpeed Insights testuje ze serverů v USA. Web hostovaný na SK nebo CZ serveru bude mít jiné výsledky při testování z Evropy oproti Americe. GTmetrix s evropským serverem (Londýn nebo Vancouver - vyberte Londýn pro SK relevanci) dává reálnější obraz.

Klíčový pohled je Waterfall tab - vizuální zobrazení toho, v jakém pořadí a jak dlouho trvá načtení každého souboru. Pokud vidíte jeden dlouhý pruh (JS bundle, masivní CSS nebo velký obrázek), tam je bottleneck.

GTmetrix také ukáže:

• Celkový čas načtení stránky (Fully Loaded Time)
• Celkový objem přenesených dat v MB
• Celkový počet HTTP requestů

Orientační benchmarky pro dobře optimalizovaný web na SK/CZ hostingu: čas načtení pod 2 sekundy z evropského test serveru, celková velikost stránky pod 2 MB, počet requestů pod 80. Tyto hodnoty jsou jen rámcové - závisí na složitosti stránky a obsahu.

Krok 4: Google Search Console - data z reálných návštěvníků vašeho webu

Google Search Console obsahuje sekci Core Web Vitals s reálnými daty od vašich návštěvníků - to je autoritativnější zdroj než syntetické testy, protože Google hodnotí právě field data.

Pokud máte Google Search Console nastavený (a měli byste), najděte sekci Core Web Vitals v levém menu. Report rozděluje URL do tří skupin:

• Dobré URL - všechny tři metriky v zeleném
• URL, které potřebují zlepšení - některá metrika v oranžovém
• Špatné URL - některá metrika v červeném

Search Console CWV report je důležitější než Lighthouse skóre, protože Google při rankingu hodnotí právě field data, ne lab data. Pokud váš web dostává alespoň několik stovek měsíčních návštěv, Search Console je nejautoritativnější zdroj pro hodnocení výkonu.

Search Console také spojuje výkonnostní problémy s konkrétními URL - můžete vidět, jestli je pomalá celá doména nebo jen konkrétní stránky (např. kategorie blogu vs. homepage). To výrazně usnadňuje prioritizaci oprav.

Porovnání nástrojů pro testování rychlosti webu

Každý nástroj má jiný úhel pohledu - pro komplexní obraz je ideální kombinovat alespoň PageSpeed Insights se Search Console.

Nástroj	Cena	Typ dat	Nejlepší pro
PageSpeed Insights	Zdarma	Lab + Field (CrUX)	První test, CWV metriky, okamžitý výsledek
GTmetrix	Zdarma / placený	Lab (syntetické)	Waterfall, test z evropského serveru, porovnání v čase
Google Search Console	Zdarma (vyžaduje ověření)	Field (reální uživatelé)	Produkční data, SEO kontext, identifikace problémových URL
Chrome Lighthouse (DevTools)	Zdarma	Lab	Vývojářská diagnostika, testování změn před deployem
WebPageTest	Zdarma	Lab (pokročilý)	Pokročilá analýza, film strip, snímkování po snímcích

Typické problémy SK webů a jak je opravit

Při analýzách slovenských prezentačních webů narážíme opakovaně na pět stejných problémů - většina z nich je řešitelná bez kompletního předělání webu.

1. Neoptimalizované obrázky
Fotografie v původní velikosti, JPEG bez komprese, PNG tam, kde stačí WebP. Obrázek 4-5 MB na homepage je při mobilním připojení kritický problém.
Řešení: Konvertovat na formát WebP nebo AVIF, nastavit lazy loading pro obrázky pod "fold", doplnit atributy width/height pro zabránění CLS.

2. Závislost na page-builderu
Weby na Elementoru, Divi nebo WPBakery načítají desítky souborů JS a CSS na každé stránce. Mnoho z nich je render-blocking a nelze je snadno odstranit bez změny architektury.
Řešení: Migrace na čistou WordPress šablonu bez page-builderu je radikální, ale efektivní. Pokud se u vás objevuje 5 a více signálů, že web zaostává, přečtěte si 5 signálů, že je čas na redesign webu.

3. Pomalý hosting (vysoký TTFB)
Time to First Byte (TTFB) nad 600 ms je problém hostingu nebo serverové konfigurace, ne front-endu. Žádná front-endová optimalizace pomalý server nevymaže.
Řešení: Přejít na hosting s SSD disky, PHP 8.2+ a dostupným LiteSpeed nebo Nginx. Pro WordPress: LiteSpeed Cache nebo WP Rocket v kombinaci s CDN výrazně pomáhají.

4. Nenakonfigurovaná cache
Každá návštěva znovu stáhne stejné CSS, JS a obrázky. Správná konfigurace cache ušetří výrazné procento přenosů pro vracející se návštěvníky.
Řešení: Aktivovat server-side caching (LiteSpeed, Nginx FastCGI), nastavit hlavičky browser cache a zvážit CDN pro statické assety.

5. Nekontrolované skripty třetích stran
Google Analytics, Hotjar, Facebook Pixel, chat widget, newsletterový formulář - každý skript přidává latenci a může být render-blocking. Na některých webech vidíme 8-12 skriptů třetích stran, aniž by majitel věděl, proč tam jsou.
Řešení: Zauditovat všechny skripty, ponechat jen nezbytné, zbytečné odstranit. Zbývající načítat asynchronně nebo s atributem defer.

V praxi: jak navázat na výsledky testu

Samotný test nestačí - výsledky je třeba přetavit do konkrétního seznamu kroků seřazených podle dopadu na Core Web Vitals.

V praxi při analýzách SK webů narážíme na stejný vzorec: majitel si nechal udělat web před 4-5 lety, tehdy fungoval dobře. Dnes Google hodnotí INP (nová metrika od roku 2024), mobilní indexování je priorita a stránka se načítá 6-8 sekund na běžném Android telefonu. Výsledek: vyšší míra okamžitého opuštění, žádné organické leady.

Dobrá zpráva: většina problémů je řešitelná bez kompletního předělání webu. Prioritizujte podle toho, která oprava má největší vliv na CWV:

1. LCP problém = obvykle obrázek nebo server response time - řešte jako první
2. CLS problém = chybějící rozměry obrázků nebo webfonty bez size-adjust - rychle opravitelné
3. INP problém = příliš mnoho JS na hlavním vlákně - komplexnější, vyžaduje JS audit

Pokud výsledky ukazují červené nebo oranžové metriky a nevíte, kde začít, pomáhá komplexní SEO a výkonnostní audit, který problémy identifikuje a přiřadí jim prioritu. Weby, které stavíme od základu bez klikacích šablon, startují s výrazně lepším výkonem - zbytečný kód do nich jednoduše nevstupuje.

V kontextu Google AI Mode a citací v LLM (psali jsme o tom v článku Google AI Mode a SEO 2026) je výkon stránky ještě důležitější - pomalé stránky mají nižší šanci být citovány v AI odpovědích jako zdroje, protože je Google hodnotí níže i podle signálů Page Experience.

Závěr

Otestování rychlosti webu zabere 5 minut a nástroje jsou zdarma. PageSpeed Insights a GTmetrix dají jasný obraz o stavu, Google Search Console pak ukáže, jak to vidí skuteční návštěvníci. Pokud výsledky ukážou červená čísla a nevíte, co s nimi, podívejte se, co pokrývá naše SEO a výkonnostní optimalizace nebo - pokud problém leží hlouběji v architektuře webu - redesign webu.

Přemýšlíte o výkonnostním auditu vašeho webu? Nezávazná konzultace - odpovíme do 24 hodin.

FAQ

Časté otázky.

Co je dobré skóre v PageSpeed Insights?

Skóre 90 a více je zelené - web je rychlý a Core Web Vitals jsou pravděpodobně v normě. Skóre 50-89 je oranžové a signalizuje viditelné výkonnostní problémy. Pod 50 je červené - web má vážný problém, který přímo ovlivňuje SEO i konverzi.

Proč má můj web jiné skóre na mobilu a na desktopu?

Google hodnotí mobil a desktop zvlášť, protože mobilní zařízení mají slabší procesor a pomalejší sítě. Mobilní skóre je obvykle nižší a je důležitější - Google primárně indexuje mobilní verzi stránky (mobile-first indexing).

Záleží na tom, z jakého místa web testuji?

Ano. PageSpeed Insights testuje ze serverů v USA - pro SK web na evropském hostingu dává GTmetrix s evropským serverem (např. Londýn) reálnější obraz. Doporučujeme testovat oběma nástroji.

Pomáhá zrychlení webu i SEO?

Ano - Google používá Core Web Vitals jako přímý rankingový signál od roku 2021. Pomalý web dostává nižší pozice než obsahově srovnatelný rychlý web. Více o metrikách v článku o Core Web Vitals.

Co je TTFB a proč je důležitý?

Time to First Byte (TTFB) je čas od prvního requestu po první byte odpovědi ze serveru. TTFB nad 600 ms naznačuje problém hostingu nebo serveru. Žádná front-endová optimalizace to neopraví - je třeba řešit hosting, konfiguraci serveru nebo CDN.