Když web propadne v Core Web Vitals, první podezřelý je skoro vždycky hosting. Někdy oprávněně, mnohem častěji ne. Server totiž rozhoduje o tom, jak rychle dorazí první byte — a na to navazuje spousta dalších věcí, které už server neovlivní ani omylem.
Projdeme si, co se za jednotlivými metrikami skrývá, kterou část z nich reálně drží v ruce poskytovatel hostingu a kterou tvoje šablona. A hlavně: jak poznat rozdíl dřív, než zaplatíš za dražší tarif, který ti nepomůže.
Tři metriky, tři různí viníci
Core Web Vitals jsou dnes tři a měří tři úplně jiné věci:
- LCP (Largest Contentful Paint) — jak rychle se vykreslí největší prvek viditelné části stránky. Typicky hlavní obrázek nebo nadpis. Dobrá hodnota je do 2,5 sekundy.
- INP (Interaction to Next Paint) — jak dlouho trvá, než stránka viditelně zareaguje na kliknutí nebo ťuknutí. Dobrá hodnota je do 200 milisekund. INP nahradilo dřívější metriku FID a stabilní součástí Core Web Vitals se stalo v roce 2024.
- CLS (Cumulative Layout Shift) — jak moc obsah při načítání „poskakuje". Dobrá hodnota je do 0,1.
Hodnotí se 75. percentil načtení stránky, zvlášť pro mobil a pro desktop (zdroj: web.dev — Web Vitals). To je důležité: nestačí, aby to bylo rychlé u tebe na optice. Tři čtvrtiny všech reálných návštěv se musí vejít pod práh.
Google k tomu dodává, že Core Web Vitals jsou součástí signálů o dojmu ze stránky a že to „spolu s dalšími aspekty odpovídá tomu, co se snaží odměňovat jeho hlavní hodnoticí systémy" (zdroj: Google Search Central — Core Web Vitals). Není to hlavní faktor pozic, ale je to faktor, který si můžeš změřit.
| Metrika | Dobrá hodnota | Kdo ji hlavně drží v ruce |
|---|---|---|
| LCP | do 2,5 s | Zčásti server (TTFB), zčásti frontend (obrázky, fonty) |
| INP | do 200 ms | Skoro výhradně frontend (JavaScript v prohlížeči) |
| CLS | do 0,1 | Výhradně frontend (šablona, rozměry obrázků, reklamy) |
| TTFB (pomocná) | do 0,8 s | Server, PHP, databáze, cache |
Co hosting ovlivňuje přímo: TTFB, CPU, PHP a databáze
Server má v celém řetězci jednu konkrétní úlohu — dodat první byte odpovědi. Metrika, která to měří, se jmenuje TTFB (Time To First Byte) a web.dev za dobrou hodnotu považuje 0,8 sekundy a méně; 0,8 až 1,8 s je „vyžaduje zlepšení" a nad 1,8 s je špatně (zdroj: web.dev — TTFB).
TTFB samo o sobě mezi Core Web Vitals nepatří, ale předchází jim. Platí jednoduchá aritmetika: pokud server odpovídá za 1,5 sekundy, na celé vykreslení LCP ti do prahu 2,5 s zbývá jedna sekunda. To je málo i pro dobře postavený frontend.
Do TTFB se propisují tyhle věci na straně hostingu:
- rychlost PHP a jeho verze — novější větve jsou měřitelně rychlejší a mají lepší JIT/OPcache
- výkon a zatížení sdíleného serveru — na sdíleném hostingu soutěžíš o CPU s desítkami dalších webů
- databáze — pomalé dotazy, chybějící indexy, ale i to, jestli poskytovatel jede na SSD/NVMe
- serverová cache — LiteSpeed cache, Varnish, Redis nebo Memcached pro object cache
- fyzická vzdálenost serveru od návštěvníka a kvalita konektivity
- limity tarifu — když narazíš na strop CPU nebo I/O, odpovědi se začnou frontit
Poslední bod je zákeřný, protože se neprojevuje pořád. Web je ve dvě odpoledne v pohodě a večer ve špičce má TTFB tři sekundy. Co se skrývá za limity sdílených tarifů, rozebírám v článku o tom, co reálně znamená „neomezený" hosting.
Co hosting nevyřeší: JavaScript, obrázky a šablona
Tady přichází nepříjemná část. INP a CLS server neovlivní prakticky vůbec.
INP měří, jak dlouho blokuje hlavní vlákno prohlížeče tvůj JavaScript. Když má stránka 900 kB skriptů, čtyři analytické nástroje, chat widget a page builder, který si dopočítává rozměry, bude INP špatné na jakémkoliv serveru. Rychlejší hosting ten JavaScript doručí dřív — a prohlížeč se s ním pak bude prát přesně stejně dlouho.
CLS je na tom stejně. Poskakující obsah vzniká z obrázků bez uvedených rozměrů, z fontů, které se dotahují a překreslují text, z reklam a cookie lišt vkládaných nad obsah. To všechno je práce šablony, ne serveru.
I u LCP je vliv rozdělený. Server dodá HTML, ale pokud je LCP prvkem 2MB neoptimalizovaný hero obrázek ve formátu PNG, který se navíc dotahuje až po JavaScriptu, žádná změna hostingu tě nezachrání. Typické frontendové příčiny:
- Velké a nekomprimované obrázky — chybí WebP/AVIF, chybí
srcset, chybí rozměry - Render-blocking CSS a JS v hlavičce
- Lazy loading nasazený na LCP obrázek — velmi častá chyba, obrázek se pak načte pozdě schválně
- Fonty bez
font-display: swapa bez preloadu - Předimenzovaná šablona — page builder, který na jednoduchou stránku naloží deset knihoven
Jak měřit: terénní data versus laboratoř
Rozdíl mezi dvěma typy měření je zdroj devadesáti procent zmatku v celém tématu.
Terénní data (field data) pocházejí od reálných návštěvníků a agreguje je Chrome UX Report. CrUX je popisovaný přímo jako „dataset programu Web Vitals" a sbírá se ze skutečných prohlížečů po celém světě (zdroj: Chrome UX Report). Tohle jsou čísla, která uvidíš v přehledu Core Web Vitals v Search Console a která odpovídají na otázku „jak to má web doopravdy".
Laboratorní data (lab data) vznikají v simulovaném testu — Lighthouse, PageSpeed Insights, WebPageTest. Jsou k nezaplacení při hledání příčiny, protože ti přesně ukážou, který zdroj brzdí. Nejsou to ale hodnoty, podle kterých se web hodnotí. Lighthouse navíc INP ani neměří, protože v laboratoři nikdo neklikat nebude.
Praktický postup: v Search Console zjistíš, jestli problém existuje a na kterých šablonách stránek. V PageSpeed Insights nebo v prohlížečových DevTools zjistíš proč. A pokud chceš vědět, jestli je vinen server, dívej se v laboratorním testu na položku „Initial server response time" — to je tvoje TTFB.
Jak poznat, že vinu má opravdu hosting
Než začneš stěhovat web, projdi si tenhle krátký test. Čím víc bodů sedí, tím pravděpodobněji je problém na serveru:
- TTFB přesahuje 0,8 s i u odlehčené stránky, například u prostého textového příspěvku bez obrázků
- TTFB kolísá podle denní doby — ve špičce několikanásobně horší než v noci
- Statický soubor se stáhne rychle, ale HTML dlouho — to ukazuje na PHP a databázi, ne na linku
- LCP je špatné, ale INP a CLS jsou v pořádku — server ovlivňuje první, ne zbylé dvě
- V logu se objevují chyby 508 nebo 503 ve špičkách
- Zapnutí cache pomohlo jen částečně a necachované stránky (košík, vyhledávání, administrace) zůstávají pomalé
A naopak: pokud máš TTFB pod 0,5 sekundy a přesto propadáš v INP a CLS, hosting je nevinný. Peníze utracené za silnější tarif ti v tomhle případě nevrátí ani korunu výkonu.
Kdy má smysl řešit hosting a kdy jen cache
Nejlevnější zásah je skoro vždycky cache. Statická cache stránek udělá z dynamického PHP webu prakticky statické HTML a TTFB spadne řádově. Object cache (Redis, Memcached) pomůže tam, kde je úzkým hrdlem databáze. Než sáhneš po dražším tarifu, zkus tohle — a k tomu zkontroluj, jestli běžíš na aktuální verzi PHP.
Změna hostingu dává smysl ve třech situacích: když poskytovatel nenabízí serverovou cache ani novější PHP, když pravidelně narážíš na limity CPU nebo I/O a upgrade v rámci téhož poskytovatele problém jen odkládá, a když server stojí geograficky jinde, než máš návštěvníky, a nechceš to řešit CDN.
U WordPressu se při výběru dívej hlavně na tři parametry: verzi PHP, dostupnost object cache a to, jestli hosting umí serverovou cache stránek. Poskytovatele podle těchhle parametrů si můžeš profiltrovat v kategorii WordPress hosting; u běžných webů a aplikací se stejná logika hodí i v kategorii webhosting.
FAQ
Ovlivní hosting SEO přes Core Web Vitals?
Nepřímo ano. Core Web Vitals jsou součástí signálů o dojmu ze stránky, které podle Googlu odpovídají tomu, co odměňují jeho hodnoticí systémy. Hosting z nich ovlivňuje hlavně LCP přes rychlost odpovědi serveru. Relevantní obsah ale přeskočí rychlý web s obsahem slabým — pořadí důležitosti se tímhle neobrací.
Jaké TTFB mám mít?
Do 0,8 sekundy je podle web.dev dobré. Nad 1,8 sekundy je to špatné a bez zásahu se do dobrého LCP nedostaneš, protože ti na vykreslení zbyde příliš málo času.
Zlepší CDN Core Web Vitals?
Pomůže hlavně tam, kde máš návštěvníky daleko od serveru, a u statických souborů — obrázků, CSS, JS. Pokud je pomalé samotné generování HTML, CDN to nevyřeší, dokud nezapneš i cachování HTML na její straně.
Proč mi PageSpeed Insights ukazuje jiná čísla než Search Console?
Protože měří jinak. Search Console pracuje s terénními daty od reálných návštěvníků za delší období, PageSpeed Insights ti kromě nich ukazuje i jednorázový laboratorní test. Rozhodující jsou terénní data.
Můžu mít dobré LCP na sdíleném hostingu?
Bez problémů. Sdílený hosting se zapnutou cache a aktuálním PHP se běžně dostane pod 0,5 s TTFB. Sdílený tarif není automaticky pomalý — pomalý je přetížený server bez cache.
Co když mám špatné jen INP?
Pak je to čistě práce s frontendem: omezit zbytečné skripty, rozbít dlouhé úlohy na hlavním vlákně, odložit načítání widgetů třetích stran. Server s tím neuděláš nic.
Závěr
Core Web Vitals nejsou jedna metrika, ale tři různé odpovědnosti. Hosting drží v ruce TTFB, a tím část LCP. INP a CLS jsou práce frontendu, ať platíš za server cokoliv. Než začneš stěhovat web, změř si TTFB na odlehčené stránce a podívej se, jestli kolísá podle denní doby — to je nejlevnější způsob, jak zjistit, na které straně problém opravdu je.
A jestli test ukáže na server, porovnej si parametry poskytovatelů podle verze PHP, cache a garantovaných zdrojů v kategorii webhosting. Před samotným přesunem se hodí projít checklist migrace bez výpadku.
