Klienti mi občas pošlou screenshot z PageSpeed Insights: na mobilu červená čtyřicítka a k tomu otázka, jestli je to katastrofa a kolik bude stát dostat se na stovku. Ten moment znám. Skoro vždycky odpovídám, že nejdřív si musíme říct, co to číslo vlastně znamená.
PageSpeed Insights je nástroj, kterým rychlost načítání webu měřím u každého auditu. Zadarmo, od Googlu, a přesto se jeho výsledky čtou nejčastěji špatně. Projdu s vámi, jak report číst, kterým číslům věřit, a hlavně co web malé firmy zrychlí doopravdy (a kde už jde jen o honbu za body).
Co je PageSpeed Insights
PageSpeed Insights (PSI) je bezplatný nástroj od Googlu, který změří rychlost načítání webové stránky a vypíše, co ji brzdí. Najdete ho na adrese pagespeed.web.dev: zadáte adresu, chvíli počkáte a dostanete skóre 0 až 100 zvlášť pro mobil a počítač, hodnoty Core Web Vitals a seznam doporučení.
Jedna věc se u něj přehlíží: PSI měří jednu konkrétní stránku, ne celý web. Úvodní stránka bývá vyladěná, problém se schovává na produktech nebo na blogu. Otestujte proto vždycky aspoň tři různé typy stránek, ne jen homepage.
Nejdůležitější věc v reportu: laboratoř vs. realita
PSI ukazuje dva druhy dat a ta spolu nemusí souhlasit. Kdo tenhle rozdíl nezná, čte celý report špatně.
Data z reálného provozu (field data). Sbírají se od uživatelů Chromu za posledních 28 dní (databáze se jmenuje Chrome UX Report, zkráceně CrUX). Popisují, jak se web opravdu chová na telefonech a připojeních vašich skutečných návštěvníků. V reportu jsou hned nahoře, nad laboratorním skóre. A právě podle nich Google posuzuje Core Web Vitals.
Laboratorní data (lab data). Simulace: nástroj Lighthouse načte stránku v datacentru Googlu na emulovaném telefonu střední třídy se záměrně zpomaleným mobilním připojením. Odtud pochází to velké barevné skóre. Simulace je schválně přísná, proto bývá mobilní skóre o tolik horší než desktopové. Její smysl je diagnostika: ukáže, co stránku brzdí, i když web zatím skoro nikdo nenavštěvuje.
Menší weby field data často nemají vůbec, protože Google potřebuje dostatečný vzorek návštěv. PSI pak ukáže aspoň souhrn za celý web, a když nestačí ani ten, zbývá jen laboratoř. Není to chyba vašeho webu, jen málo dat.
Praktické pravidlo z mých auditů: rozhodujte se podle reálného provozu, opravujte podle laboratoře. Když field data říkají „v pořádku" a laboratorní skóre je žluté, máte web, který skutečným návštěvníkům funguje. Panika není na místě.
Core Web Vitals: tři čísla, na kterých záleží
Core Web Vitals jsou tři metriky, kterými Google popisuje zkušenost uživatele se stránkou. Podrobně je rozebírám v článku Core Web Vitals, tady stručně:
Hodnoty se posuzují na 75. percentilu. Přeloženo: limit musí splnit i pomalejší část vašich návštěv, průměr vás nezachrání.
Pozor na starší návody: do března 2024 byla místo INP metrika FID. Když článek nebo audit ještě mluví o FID, je zastaralý — INP je přísnější, protože měří odezvu všech interakcí na stránce, ne jen té první.
A jak je to s pozicemi? Google říká, že jeho systémy odměňují dobrou zkušenost se stránkou, a rychlost je jedna z jejích součástí (vedle HTTPS nebo použitelnosti na mobilu). Z praxe: extrémně pomalý web si ublíží, ale rychlost sama o sobě nikoho na první místo nevytáhne. O pořadí rozhoduje hlavně obsah. Rychlost řešte proto, že návštěvník s pomalým webem ztrácí trpělivost dřív, než cokoliv koupí.
Víte jistě, co je na vašem webu špatně? Já to zjistím za vás. Projdu ho ručně, žádný automat — a do 48 hodin máte seznam věcí, které vás v Googlu brzdí, seřazený podle důležitosti. Zdarma.
Proč skóre 100 není cíl
Na honbě za zeleným kolečkem se dá utratit hodně peněz s minimálním výsledkem, takže po pořádku:
- Skóre je laboratorní simulace, ne realita vašich návštěvníků. Zelené je od 90 výš a Google sám píše, že dobré laboratorní skóre ještě neznamená spokojené uživatele.
- Skóre mezi měřeními kolísá. Stejná stránka dá dopoledne 78 a odpoledne 84, aniž jste cokoliv změnili. Rozdíl pár bodů nic neznamená.
- Cíl jsou zelené Core Web Vitals v reálném provozu. Web se skóre 85 a zelenými vitals je v pořádku. Posun z 95 na 100 stojí typicky desítky hodin vývoje a návštěvník ho nepozná.
Ještě jedna změna, ať vás nezmate: od podzimu 2025 Google přeskupil doporučení v reportu do takzvaných „insights" (sloučil a přejmenoval dřívější audity). Starší návody s názvy jako „Eliminate render-blocking resources" už tedy přesně nesedí na to, co v reportu uvidíte. Podstata rad se ale nezměnila, a proto jdu v dalším bodu po problémech, ne po názvech položek.
Co web malé firmy zrychlí doopravdy
Za 14 let praxe se mi seznam skutečných brzd ustálil na čtyřech položkách. Řadím je podle toho, kolik zrychlení dostanete za kolik práce:
1. Obrázky. Zdaleka nejčastější nález. Fotka z telefonu má klidně 5 MB a na webu se zobrazuje v okénku o šířce 400 pixelů; největším prvkem stránky (tím, který měří LCP) navíc bývá právě obrázek. Zmenšit na skutečné rozměry, převést do WebP, líně načítat všechno mimo první obrazovku. Hodina práce, často nejviditelnější zrychlení ze všech. Podrobný postup mám v článku optimalizace obrázků pro SEO.
2. Hosting a cache. Když server dlouho přemýšlí, než vůbec začne odpovídat, žádná optimalizace na stránce to nedožene. Nejlevnější sdílené hostingy tímhle trpí běžně. Řešení jsou dvě a doplňují se: cache (stránka se poskládá jednou a návštěvníkům se servíruje hotová — na WordPressu to zařídí cachovací plugin) a přechod na pořádný hosting, což je pár stovek měsíčně, ne tisíce.
3. Skripty třetích stran a pluginy. Chat okénko, měření, mapy, přehrávače, reklamní pixely. Každý z nich je JavaScript navíc a dohromady umí zabít odezvu stránky (INP). Jednou za čas si projděte, co web opravdu načítá, a vyhoďte, co nepoužíváte. U WordPressu totéž s pluginy: každý deaktivovaný je zrychlení zadarmo.
4. Fonty. Šest řezů písma z externí služby znamená, že návštěvník kouká na prázdné místo, než se stáhnou. Stačí dva řezy, načítané tak, aby se text zobrazil okamžitě v náhradním písmu a to správné se vyměnilo, až se stáhne (CSS vlastnost font-display: swap). Nuda, ale funguje.
A kde končí rozumná práce a začíná mikrooptimalizace? Zhruba tam, kde řešíte minifikaci posledních kilobajtů, předpřipojování k doménám a posun skóre z 92 na 97. Ten čas dá vašemu byznysu víc skoro kdekoliv jinde — třeba v obsahu, který na tom rychlém webu chybí.
Časté otázky
Jaká je dobrá rychlost načítání webu?
Držte se limitů Core Web Vitals: hlavní obsah do 2,5 sekundy (LCP), odezva na kliknutí do 200 milisekund (INP), rozvržení bez poskakování (CLS do 0,1). Platí to pro reálné návštěvy na mobilu, ne pro test na kancelářské wifi.
Proč mám na počítači 95, ale na mobilu 40?
Protože mobilní test simuluje slabší telefon na zpomaleném připojení, zatímco desktopový běží na rychlé lince. Není to rozbité, je to schválně přísné. Řiďte se mobilním výsledkem: Google indexuje mobilní verzi webu a na webech, které vídám v auditech, návštěvy z telefonů většinou převažují.
Co když mi v reportu chybí data z reálného provozu?
Znamená to jen, že web má málo návštěv na to, aby Google sestavil statistiku. Řiďte se laboratorními výsledky a limity Core Web Vitals; jakmile návštěvnost vzroste, field data se objeví sama.
Zrychlí mi lepší skóre pozice ve vyhledávání?
Přímo skóre ne, to je jen laboratorní číslo. Google odměňuje celkově dobrou zkušenost se stránkou, jejíž součástí rychlost je. Reálný přínos zrychlení bývá jinde: méně lidí to vzdá při načítání a víc jich dokončí objednávku.
Stránka obecných rad je fajn. Konkrétní seznam pro váš web je lepší. Audit máte zdarma.
Když vám svítí červená
Postup, který doporučuju: nejdřív se podívejte, jestli máte field data a jak vypadají Core Web Vitals. Pak otestujte tři typy stránek, ne jen úvodní. A začněte u obrázků, tam se skoro vždycky vydělá nejvíc.
Jestli z reportu nejste moudří, je to přesně situace pro můj SEO audit. Rychlost v něm kontroluju vždycky, jenže v souvislostech: poznáte, jestli za pomalé načítání můžou obrázky, hosting, nebo úplně něco jiného, co s pozicemi souvisí víc. Audit dostanete zdarma a výsledek během dvou dnů, i s pořadím oprav.
Zdroje k faktům v článku:
- Dokumentace PageSpeed Insights: lab vs. field data, CrUX za 28 dní, simulované zařízení a síť (ověřeno 15. 7. 2026): developers.google.com/speed/docs/insights/v5/about
- Limity Core Web Vitals a 75. percentil (ověřeno 15. 7. 2026): web.dev/articles/vitals
- INP nahradilo FID 12. 3. 2024: web.dev/blog/inp-cwv-march-12
- Zkušenost se stránkou a hodnocení ve vyhledávání (ověřeno 15. 7. 2026): developers.google.com/search/docs/appearance/page-experience
- Přechod Lighthouse na insight audity (Lighthouse 13, říjen 2025): developer.chrome.com/blog/moving-lighthouse-to-insights
