Grew Studio

    Ako zrýchliť web: Core Web Vitals krok za krokom

    Ako zrýchliť web a opraviť LCP, INP a CLS: prahy od Googlu, bezplatné meranie, opravy podľa vplyvu a 30-minútový zoznam úloh pre majiteľov webov.

    Adam Oliver Kollár14. októbra 202613 min

    „Web je pomalý" je pocit. Google ho meria tromi číslami, ktoré sa volajú Core Web Vitals. Ich hranice sú verejné, zmerať ich môžete zadarmo a väčšina opráv sa dá zoradiť podľa toho, koľko prinesú. Tento článok je kompletný postup: čo čísla znamenajú, ako zistiť, kde je váš web, čo opraviť ako prvé a kedy sa oplatí zavolať vývojára.

    Rýchla odpoveď

    • Sledujte tri metriky: LCP (načítanie hlavného obsahu) do 2,5 s, INP (odozva na kliknutie) do 200 ms a CLS (posúvanie obsahu) do 0,1.
    • Web vyhovuje, ak tieto hranice spĺňa 75 % návštev, osobitne na mobile a na počítači.
    • Rozhodujú reálne dáta od návštevníkov (Search Console, sekcia „reálni používatelia" v PageSpeed Insights), nie skóre 0 až 100 z laboratórneho testu.
    • Najväčší vplyv zvyčajne majú: hlavný obrázok (veľkosť, formát, priorita), rozmery obrázkov a vložených prvkov, menej JavaScriptu a skriptov tretích strán a rýchla odozva servera.
    • Google dobré hodnoty odporúča, ale relevantný obsah má prednosť. Rýchlosť berte ako základ, nie ako skratku na prvé miesto.

    Tri metriky, ktoré Google sleduje

    Core Web Vitals sú tri merania zo skúsenosti skutočných návštevníkov. Hodnotia sa pre každú stránku osobitne, osobitne pre mobil a pre počítač, a to na 75. percentile návštev. Znamená to, že tri zo štyroch návštev musia dosiahnuť cieľovú hodnotu. Google takto zámerne nenecháva rozhodovať pár extrémnych prípadov, ale zároveň sa nespolieha na priemer, ktorý by skryl pomalé návštevy (web.dev, „Defining the Core Web Vitals thresholds").

    MetrikaČo meriaDobréPotrebuje zlepšenieSlabéTypické príčiny
    LCP (Largest Contentful Paint)Za aký čas sa zobrazí najväčší prvok v úvodnej obrazovke (obrázok, video alebo blok textu)do 2,5 s2,5 až 4 snad 4 spomalý server, veľký alebo neskoro načítaný hlavný obrázok, blokujúci JavaScript a CSS
    INP (Interaction to Next Paint)Ako rýchlo sa po kliku, ťuknutí alebo stlačení klávesu zobrazí viditeľná odozvado 200 ms200 až 500 msnad 500 msťažký JavaScript, dlhé úlohy v prehliadači, skripty tretích strán, veľké DOM
    CLS (Cumulative Layout Shift)Ako veľmi sa obsah neočakávane posúvado 0,10,1 až 0,25nad 0,25obrázky a vložené prvky bez rozmerov, reklamy, neskoro vložené bannery, webové písma

    Podrobnosti, ktoré sa oplatí poznať:

    • LCP sa počíta od začiatku navigácie, takže zahŕňa aj presmerovania, spojenie so serverom a čas do prvého bajtu. Ako LCP prvok sa berie <img>, obrázok v SVG, <video> (plagát), prvok s obrázkom na pozadí cez CSS alebo blok s textom.
    • INP sleduje kliky, ťuknutia a klávesy počas celej návštevy. Posúvanie, prechod myšou a zoom sa nepočítajú. Zvyčajne sa berie najhoršia odozva, pri veľa interakciách sa ignoruje jedna najhoršia na každých 50. INP nahradilo staršiu metriku FID 12. marca 2024.
    • CLS počíta najväčší „zhluk" posunov. Posun, ktorý nastane do 500 ms po vašom kliku, sa do skóre nezapočítava.

    Aká je skutočná úloha rýchlosti pri hodnotení vo vyhľadávaní

    Google v dokumentácii píše, že majitelia webov by mali dosiahnuť dobré Core Web Vitals, a dodáva, že to zodpovedá tomu, čo chcú jeho hlavné systémy hodnotenia odmeňovať (Search Central, Core Web Vitals, aktualizované 10. 12. 2025). V stránke o page experience ďalej uvádza, že Core Web Vitals používajú jeho systémy hodnotenia, že neexistuje „jeden signál" a že ostatné aspekty page experience priamo nezvyšujú poradie. A hlavné: Google vždy hľadá najrelevantnejší obsah, aj keď má stránka slabší zážitok.

    Praktický záver: rýchly web vás nevynesie na prvé miesto, ak odpoveď na dopyt poskytuje iná stránka. Slabá rýchlosť však môže vašu snahu brzdiť a hlavne stojí návštevníkov, ktorých už máte. Google sám uvádza, že naháňanie dokonalého skóre len kvôli SEO nemusí byť najlepšie využitý čas.

    Rýchlosť a tržby: čo štúdie naozaj hovoria

    Súvislosť s peniazmi je lepšie doložená než súvislosť s poradím, no treba byť opatrný pri interpretácii:

    • Vodafone Italy (web.dev, 17. 3. 2021): A/B test, v ktorom dostala polovica návštev z platených kanálov stránku optimalizovanú na Web Vitals a polovica pôvodnú. Optimalizovaná verzia mala o 31 % lepšie LCP a podľa Vodafone o 8 % vyššie tržby, o 15 % lepší pomer leadov k návštevám a o 11 % lepší pomer košíkov k návštevám. Ide o jeden veľký podnik a jednu sadu zmien (vykresľovanie na serveri, optimalizácia obrázkov), preto výsledok neprenášajte mechanicky na svoj web.
    • Deloitte, „Milliseconds Make Millions" (24. 3. 2020): pri zrýchlení mobilného webu o 0,1 s pozorovali v maloobchode nárast konverzií o 8,4 % a priemernej hodnoty objednávky o 9,2 %, v cestovnom ruchu o 10,1 % a 1,9 %. Dáta pochádzajú zo štvortýždňového sledovania značiek v Európe a USA. Je to pozorovacia štúdia, nie experiment na vašom webe.

    Obe štúdie ukazujú smer, nie záruku. Ak je váš web už v pásme „dobré", od ďalšieho zrýchlenia nečakajte podobné čísla.

    Ako zmerať vlastný web: postup krok za krokom

    Najprv pochopte rozdiel medzi dvomi druhmi dát. Reálne (field) dáta pochádzajú z Chrome User Experience Report (CrUX), teda od skutočných návštevníkov za posledných 28 dní, a práve z nich Google hodnotí. Laboratórne (lab) dáta vznikajú v simulovanom teste (Lighthouse) na jednom zariadení a sieti. Sú skvelé na hľadanie príčin a na kontrolu zmien, ale web.dev výslovne uvádza, že nenahrádzajú meranie v teréne. Lab test navyše nevie zmerať INP (používa náhradnú metriku Total Blocking Time).

    1. Otvorte PageSpeed Insights (pagespeed.web.dev) a zadajte adresu úvodnej stránky. Pozrite si hore sekciu s reálnymi dátami: hodnoty LCP, INP, CLS a celkové „Core Web Vitals Assessment". Prepnite karty Mobil a Počítač.
    2. Ak sekcia chýba, na stránku nie je dosť dát. PageSpeed Insights vtedy ukáže údaje za celý web (origin), a ak nie sú ani tie, ukáže len laboratórny test. Menej navštevované stránky reálne dáta často nemajú, a vtedy sa spoľahnite na lab test a skúšky na skutočnom telefóne.
    3. Zopakujte to pre 2 až 3 najdôležitejšie stránky: najnavštevovanejšiu, stránku, na ktorej sa rozhoduje o dopyte alebo nákupe (kontakt, produkt, košík), a úvodnú. Google hodnotí väčšinou konkrétnu stránku, nie len web ako celok.
    4. Otvorte Search Console, report Core Web Vitals. Zobrazuje skupiny podobných stránok, stav Dobré, Potrebuje zlepšenie a Slabé, a to podľa najslabšej metriky. Mobil a počítač sú osobitne, dáta sú za 28 dní a zahŕňajú len indexované stránky.
    5. Pozrite si diagnostiku v laboratórnom teste (časť „Diagnostics" a „Opportunities" v PSI), ktorá ukáže konkrétny LCP prvok, najväčšie súbory a skripty.
    6. Zapíšte si východiskové čísla (LCP, INP, CLS pre mobil, dátum). Bez nich neuvidíte, či zmena pomohla.
    7. Po oprave vyčkajte. Reálne dáta sú kĺzavé 28-dňové, takže plný efekt uvidíte v Search Console až po približne štyroch týždňoch. Po oprave môžete v reporte kliknúť na „Start Tracking", čo spustí 28-dňové sledovanie. Nespúšťa nové prechádzanie stránok Googlom. Okamžitý efekt overíte iba v lab teste.

    Skóre 0 až 100: Lighthouse váži dielčie metriky (v dokumentácii verzie 10: LCP 25 %, TBT 30 %, CLS 25 %, FCP 10 %, Speed Index 10 %). Zelená je 90 až 100, oranžová 50 až 89, červená 0 až 49. Skóre kolíše aj bez zmien, napríklad kvôli A/B testom, reklamám alebo rozšíreniam v prehliadači.

    Ako opraviť LCP (načítanie): poradie podľa vplyvu

    web.dev rozkladá LCP na štyri časti s odporúčaným podielom z celkového času: čas do prvého bajtu (TTFB) zhruba 40 %, oneskorenie pred začiatkom sťahovania hlavného prvku do 10 %, samotné sťahovanie zhruba 40 % a vykreslenie do 10 %. Ak má web LCP 4 s, ukážte si v lab teste, ktorá časť je neprimerane veľká, a zasiahnite tam.

    1. Zistite, čo je LCP prvok. Na väčšine webov je to obrázok. Podľa Web Almanac 2025 je to obrázok pri 76 % mobilných a 85 % desktopových stránok, ostatok tvorí text.
    2. Nikdy nelenošte načítanie hlavného obrázka (loading="lazy"). web.dev: „Never lazy-load your LCP image." Web Almanac 2025 pritom zistil, že 16 až 17 % stránok má LCP obrázok načítavaný lenivo, čo je jedna z najčastejších a najľahšie opraviteľných chýb.
    3. Dajte hlavnému obrázku prioritu cez fetchpriority="high", ale len jednému či dvom obrázkom, inak efekt zaniká. Atribut má len približne 17 % LCP obrázkov na mobile.
    4. Obrázok musí byť nájditeľný v HTML. Ak sa hlavný obrázok načítava až z externého CSS alebo JavaScriptu, prehliadač ho objaví neskoro. Vtedy ho načítajte vopred (<link rel="preload">).
    5. Zmenšite obrázok. Posielajte rozmer, ktorý sa naozaj zobrazuje (atribúty srcset a sizes), a použite moderný formát. web.dev: WebP a AVIF zvyčajne komprimujú lepšie než JPEG a PNG a majú sa používať všade, kde sa dá. Podľa Web Almanac 2025 je medzi LCP obrázkami JPG 57 %, PNG 26 %, WebP 11 % a AVIF 0,7 %, čiže priestor na zlepšenie je veľký.
    6. Znížte čas do prvého bajtu. Ak je TTFB vysoké, LCP 2,5 s je podľa web.dev „náročné, alebo až nemožné". Podľa Web Almanac 2025 má dobrý TTFB (do 0,8 s) len 44 % mobilných stránok. Pomáha: kvalitnejší hosting s dostatkom pamäte a aktuálnym softvérom, CDN, cachovanie nepersonalizovaných stránok cez Cache-Control, odstránenie zbytočných presmerovaní (napríklad odkazy bez https://) a statické HTML tam, kde sa obsah nemení. web.dev upozorňuje, že cachovanie môže pomalý backend len zamaskovať.
    7. Obrázky servírujte z vlastnej domény, ak sa dá. Každá cudzia doména znamená dodatočné nadviazanie spojenia.
    8. Pokročilé: bfcache (rýchle návraty tlačidlom späť) a Speculation Rules (predvykreslenie pravdepodobnej ďalšej stránky) vedia priblížiť LCP takmer k nule. Sú to úpravy pre vývojára.

    Ako opraviť CLS (skákanie obsahu)

    Podľa Web Almanac 2025 má dobrú hodnotu 81 % mobilných stránok, ale 62 % mobilných stránok stále obsahuje aspoň jeden obrázok bez rozmerov.

    1. Rozmery obrázkov a videí. Vždy nastavte width a height (alebo CSS aspect-ratio), aby prehliadač vopred rezervoval miesto. Bez nich majú obrázky pred načítaním výšku 0 a posunú všetko pod sebou.
    2. Reklamy, vložené prvky a iframe. Rezervujte miesto cez min-height alebo aspect-ratio. Ak sa reklama nenačíta, nechajte miesto prázdne, lebo jeho zbalenie spôsobí rovnaký posun.
    3. Neskoro vložený obsah, napríklad cookie lišty, oznamy a bannery. Nevkladajte ich nad existujúci obsah. Rezervujte im miesto, alebo ich zobrazte ako prekrytie (overlay).
    4. Webové písma. Zvoľte náhradné písmo, ktoré je veľkosťou podobné, a doladiť ho možno cez size-adjust a príbuzné vlastnosti. Kľúčové písmo načítajte vopred (preload). font-display: optional zabráni opätovnému prerozloženiu, ale písmo sa na prvej návšteve nemusí zobraziť.
    5. Animácie. Animujte transform, nie top, left, margin, lebo tie spúšťajú posuny.
    6. bfcache. Stránky, ktoré môže prehliadač vrátiť z pamäte pri kroku späť, žiadne posuny nemajú. Zablokujú ho napríklad unload listenery alebo hlavička Cache-Control: no-store. Test nájdete v Chrome DevTools, záložka Application, Back-forward Cache.

    Ako opraviť INP (odozva)

    Podľa Web Almanac 2025 má dobré INP 77 % mobilných stránok (na počítači 97 %), takže na mobile je to stále slabé miesto veľkej časti webov. Príčinou je takmer vždy JavaScript.

    1. Odstráňte zbytočné skripty. Sledovacie kódy, chat, widgety, nepoužívané pluginy, staré A/B testy. web.dev: nepotrebný JavaScript súťaží o hlavné vlákno, čo škodí odozve najmä pri štarte.
    2. Skripty tretích strán načítavajte s async alebo defer, ak nie sú nevyhnutné pre prvé zobrazenie. async nevyrieši všetko, mnohé sledovacie skripty stránku aj tak spomalia. Dôležité je ich vplyv zmerať, napríklad zablokovaním žiadosti v DevTools alebo v Lighthouse.
    3. Rozdeľte dlhé úlohy. Úloha dlhšia ako 50 ms blokuje hlavné vlákno a návštevník čaká. Vývojár ich rozdelí cez scheduler.yield() (s setTimeout ako záložným riešením).
    4. Odľahčite spracovanie kliku. Vo funkcii po kliku robte len to, čo treba na viditeľnú odozvu, zvyšok (štatistiky, ukladanie) odložte.
    5. Zmenšite DOM. Veľké DOM spomaľuje každé prekreslenie. Pomáha aj content-visibility na mimo-obrazovkové časti.
    6. Vyhýbajte sa vykresľovaniu veľkých blokov HTML v JavaScripte a „layout thrashing" (čítanie a zapisovanie štýlov v jednej úlohe).

    Žiadny z týchto krokov nie je „jedno kliknutie", preto sa INP najčastejšie rieši s vývojárom, ak nejde o jednoduché odstránenie skriptu.

    WordPress, Shoptet, Shopify a iné platformy

    Platforma nerozhoduje sama, no štatistiky sú zaujímavé. Web Almanac 2025 (kapitola CMS, mobilné dáta) uvádza, že Core Web Vitals spĺňa 74 % mobilných webov na Wixe, 85 % na Dudě a 45 % na WordPresse (pri LCP je to 53 %). Je to priemer cez milióny webov, nie verdikt: jeden WordPress s kvalitným hostingom a ľahkou šablónou môže byť rýchlejší než Wix s 20 vloženými aplikáciami. Pre Shoptet ani Shopify sme nenašli primárny zdroj s hodnotami v rovnakej metodike, preto ich neuvádzame.

    WordPress, praktické kroky:

    • Od verzie 6.3 jadro WordPressu automaticky pridáva fetchpriority="high" obrázku, ktorý považuje za LCP, a lepšie rozhoduje, ktoré obrázky nelenošiť. Podľa tímu WordPress Core to typicky zlepší LCP o 5 až 10 %. Skontrolujte však, či to funguje aj vo vašej šablóne a v page builderi.
    • Pluginy vyberajte striktne. Každý plugin, ktorý pridáva JavaScript na všetky stránky, môže zhoršiť INP.
    • Zapnite cachovanie stránok (v pluginovi alebo priamo u hostingu) a používajte jedno riešenie, nie viac naraz. To je praktické pravidlo, nie z dokumentácie.
    • Udržujte aktuálne PHP a databázu, web.dev odporúča držať softvér servera aktuálny alebo mať hosting, ktorý to robí za vás.
    • Obrázky nahrávajte v rozumnej veľkosti a v moderných formátoch (WordPress podporuje WebP).

    Uzavreté platformy (Shoptet, Shopify, Wix a podobne): nemáte prístup k serveru a niekedy ani ku všetkému kódu, takže sa sústreďte na to, čo ovplyvníte: obrázky, počet aplikácií a doplnkov, tretie skripty a témy.

    30-minútový zoznam úloh pre majiteľov webov (bez programovania)

    1. (5 min) Zmerajte úvodnú stránku a jednu dôležitú podstránku v PageSpeed Insights na mobile. Zapíšte LCP, INP, CLS.
    2. (5 min) V diagnostike nájdite „Largest Contentful Paint element". Zistite, ktorý obrázok to je.
    3. (8 min) Nahraďte tento obrázok menším súborom primeraným zobrazenej veľkosti, ideálne WebP alebo AVIF. Skontrolujte, že nie je nastavený na lenivé načítanie.
    4. (5 min) Prejdite zoznam pluginov, widgetov a sledovacích kódov. Vypnite alebo odstráňte tie, ktoré nikto nepoužíva (starý chat, nepoužívaný A/B test, duplicitný analytický kód).
    5. (3 min) Skontrolujte cookie lištu: ak sa objaví až po načítaní a posunie obsah, požiadajte dodávateľa o prekrytie alebo rezervované miesto.
    6. (2 min) Opýtajte sa hostingu, či máte zapnuté cachovanie, aktuálne PHP a CDN.
    7. (2 min) Otestujte formulár dopytu alebo objednávku ručne na telefóne. Po každej úprave musí fungovať.

    Potom meranie zopakujte. Nečakajte zázrak v Search Console, tá sa aktualizuje po týždňoch.

    Kedy sa oplatí zaplatiť vývojára

    • Reálne LCP zostáva nad 2,5 s, aj keď sú obrázky v poriadku a TTFB je vysoké (problém so serverom, databázou alebo témou).
    • INP je nad 200 ms a nedá sa to vyriešiť odstránením skriptu (problém v kóde šablóny, page builderi alebo aplikácii).
    • CLS vzniká v téme alebo vo vložených komponentoch, ktoré neviete upraviť.
    • Web je e-shop alebo generuje dopyty a každá chyba v košíku či formulári stojí peniaze.
    • Chcete trvalé monitorovanie, aby sa web nezhoršoval pri každej novej funkcii.

    Dobrý vývojár vám ukáže namerané čísla pred a po a bude vedieť vysvetliť, čo zmenil. Pri webe na mieru je rýchlosť jednoduchšie zabudovať hneď na začiatku, nie dodatočne opravovať.

    Mýty o rýchlosti webu

    • „Potrebujem 100/100 v PageSpeed." Nie. Dokumentácia Lighthouse hovorí, že dokonalé skóre 100 je „extrémne náročné dosiahnuť a nie je očakávané", a odporúča cieliť na 90 až 100. Hodnotia sa reálne dáta a tri metriky.
    • „Core Web Vitals zaručia prvé miesto." Nie. Relevancia obsahu je stále prvá.
    • „Skóre v PSI je to, čo používa Google." Nie. Search Console používa reálne dáta z CrUX.
    • „Stačí mať rýchlu úvodnú stránku." Nie. Podľa Web Almanac 2025 vyhovuje na mobile 45 % domovských stránok a 56 % ostatných, ale hodnotí sa každá stránka osobitne.
    • „CDN všetko vyrieši." Nie. Znižuje TTFB, ale neodstráni ťažký JavaScript ani nerozmerované obrázky.
    • „Lenivé načítanie na všetkých obrázkoch." Nie. Pre obrázky mimo prvej obrazovky áno, pre hlavný nikdy.
    • „Raz opravené, navždy hotové." Nie. Nový plugin, banner či obrázok môže hodnoty zhoršiť, preto meranie opakujte.

    Najčastejšie otázky

    Aké hodnoty Core Web Vitals sú dobré? LCP do 2,5 s, INP do 200 ms a CLS do 0,1 pre 75 % návštev, na mobile aj na počítači.

    Je Core Web Vitals faktor hodnotenia v Google? Google uvádza, že ich používajú jeho systémy hodnotenia, ale nie je to jediný signál a relevantný obsah má prednosť. Je to základ zážitku, nie skratka.

    Prečo PageSpeed Insights nezobrazuje reálne dáta? Pre stránku alebo celý web nie je dosť vzoriek od Chrome používateľov. Stránka tiež musí byť verejná.

    Aké skóre v PageSpeed Insights je dobré? 90 až 100 je zelená. Skóre nie je cieľ samo osebe a kolíše medzi meraniami.

    Ako dlho trvá, kým sa oprava prejaví? V lab teste hneď. V reálnych dátach a v Search Console približne štyri týždne, lebo ide o 28-dňové obdobie.

    Čo je INP a čo nahradilo? Interaction to Next Paint meria odozvu na interakcie počas celej návštevy. 12. marca 2024 nahradilo metriku FID.

    Je mobil dôležitejší než počítač? Hodnotia sa osobitne. Podľa Web Almanac 2025 vyhovuje všetkým trom metrikám 48 % mobilných a 56 % desktopových stránok, takže mobil býva problematickejší.

    Dá sa to opraviť bez programátora? Časť áno: obrázky, pluginy, tretie skripty, nastavenia hostingu. Zásahy do kódu šablóny či servera potrebujú technickú pomoc.

    Čo ďalej

    Rýchlosť je súčasť toho, čo robíme pri tvorbe webov, a pri technickej časti SEO. Ak prevádzkujete online predaj, pozrite web pre e-shopy. Ak váhate, čo web vlastne stojí, pomôže prehľad cien webstránok.

    Ak chcete vedieť, ako dopadá váš web, dohodnite si bezplatný krátky hovor. Spolu pozrieme výsledky merania a povieme vám, čo má zmysel opraviť ako prvé.

    Zdroje

    Všetky odkazy boli overené v októbri 2026.

    Súvisiace služby

    Tvorba webov na mieruZistiť viacKoľko stojí tvorba web stránkyZistiť viacSEO: vyššie pozície na GoogliZistiť viac

    Chcete to mať vyriešené bez starostí?

    Krátky bezplatný hovor: pozrieme sa na váš web a povieme vám, čo má najväčší zmysel urobiť ako prvé.