Rychlost webu a Core Web Vitals 2026: jak vteřiny ovlivňují prodeje

Proč je rychlost o penězích, ne o estetice

Zákonitost potvrzená výzkumy velkých platforem: čím déle se stránka načítá, tím nižší je pravděpodobnost nákupu. Posun doby načítání z 1 na 3 vteřiny znatelně zvyšuje podíl těch, kdo zavřou záložku; na mobilu je efekt ještě prudší. Logika je prostá: pomalý web unavuje, vyvolává nedůvěru („když to tu všechno vázne, dojde vůbec moje objednávka?") a tlačí k tomu konkurentovi, který je na jeden klik vedle.

Další důvod je vyhledávání. Google oficiálně započítává Core Web Vitals jako jeden ze signálů řazení. Za jinak stejných podmínek stojí rychlejší web výš. A jak jsme psali v článku o GEO optimalizaci, pomalé stránky se hůř dostávají i do odpovědí AI vyhledávání.

Tři metriky Core Web Vitals jednoduše

Core Web Vitals je sada ukazatelů od Googlu, které popisují reálný pocit ze stránky. V roce 2026 jsou tři:

• LCP (Largest Contentful Paint) — rychlost zobrazení hlavního. Čas, za který se zobrazí největší prvek obrazovky (obvykle hlavní obrázek nebo nadpis). Dobré je do 2,5 vteřiny. Je to odpověď na otázku „kdy uživatel vidí, že se stránka načetla".
• INP (Interaction to Next Paint) — rychlost reakce. Jak rychle web reaguje na akce: stiskli jste tlačítko — za jak dlouho se něco stalo. Dobré je do 200 milisekund. V roce 2024 INP oficiálně nahradil starou metriku FID a měří odezvu přesněji.
• CLS (Cumulative Layout Shift) — stabilita rozvržení. Nakolik prvky „skáčou" během načítání. Všichni znají to podráždění: míříte na tlačítko a tam skočil banner. Dobré je do 0,1.

Své hodnoty si můžete zkontrolovat zdarma v PageSpeed Insights nebo ve zprávě Core Web Vitals v Google Search Console — tam vidíte reálná data živých uživatelů, ne jen laboratorní test.

Checklist zrychlení: co má největší efekt

• Obrázky. Nejčastější příčina pomalého LCP. Moderní formáty (WebP/AVIF), správná velikost pro obrazovku, líné načítání toho, co je pod ohybem, a width/height, aby neskákalo rozvržení.
• Fonty. Vlastní hosting fontů místo externího, font-display: swap a preload klíčového řezu — text se objeví hned, bez „blikání".
• Skripty. Méně těžkého JavaScriptu, odložené načítání analytiky a widgetů, odstranění toho, co nikdo nevyužívá. Právě přetížený JS nejčastěji kazí INP.
• Cachování a komprese. Gzip/Brotli, cache statiky v prohlížeči, podle potřeby CDN. Opakované návštěvy se stávají okamžitými.
• Hosting. Pomalá odezva serveru táhne dolů všechno ostatní. Někdy je nejrychlejší způsob, jak web zrychlit, stěhování: o výběru jsme psali v článku VPS, nebo běžný hosting.
• Čistý kód místo „kombajnů". Web na těžké šabloně z konstruktoru s deseti pluginy téměř vždy prohrává úhledné vlastní kódování. Proto děláme weby na klíč s rychlostí 90+ jako standardem.

Častá chyba: „zrychlíme to potom"

Rychlost je nejlevnější zakládat hned na startu, do architektury. Když je web už postavený na těžké šabloně s deseti rozšířeními, každá optimalizace se mění v boj s následky a stojí dráž než samotný vývoj. Pokud je váš web už pomalý — není to ortel: většinou se dá citelně zrychlit v rámci správy, bez přepisování od nuly. Nový projekt je ale poctivější rovnou stavět rychlý.

Závěr

Core Web Vitals není vrtoch Googlu, ale pokus změřit to, co klient cítí i tak: rychle, vstřícně, bez skákání. Držte LCP do 2,5 s, INP do 200 ms, CLS do 0,1 — a získáte víc poptávek ze stejného provozu. Chcete vědět, kde jsou vaše úzká místa? Uděláme bezplatný audit rychlosti a ukážeme, co přinese největší přírůstek.