Pomalý web a SEO: čo znamenajú Core Web Vitals v praxi

Keď prejdem web a nahlásim „pomalé stránky", je to najčastejší nález, pri ktorom ľudia zdvihnú ruky. Titulok skrátite za minútu, alt text doplníte za dve. Ale „stránka sa načítava 5,8 sekundy" znie ako niečo, na čo potrebujete programátora a tri týždne. Niekedy áno. Často nie.

Tento článok vysvetľuje, čo Core Web Vitals naozaj merajú, aké čísla sú hranica medzi dobrým a slabým výsledkom, a ktoré príčiny spomalenia sa dajú opraviť bez zásahu do kódu.

Ako rýchlosť webu vstupuje do SEO

Google používa Core Web Vitals ako súčasť signálov o používateľskej skúsenosti. Dôležité je vedieť, aký vplyv to má:

• Rýchlosť nie je hlavný faktor hodnotenia. Obsah, ktorý odpovedá na otázku, prebije rýchlejšiu stránku so slabším obsahom.
• Rýchlosť rozhoduje, keď sú dve stránky obsahovo porovnateľné. Pri konkurenčných frázach je to bežná situácia.
• Nepriamy efekt je väčší než priamy. Pomalá stránka znamená viac ľudí, ktorí odídu pred načítaním. Na mobile s dátami to nie je teoretická úvaha.

Čo rýchlosť nespraví: nedostane vás z tretej strany na prvú. Ak vám niekto tvrdí, že po optimalizácii rýchlosti pôjdete o dvadsať pozícií vyššie, ignorujte to. Reálne čakajte lepšiu miestnosť na manévrovanie a nižší podiel odchodov.

Tri metriky a ich presné hranice

Core Web Vitals sú tri čísla. Každé má tri pásma: dobré, treba zlepšiť, slabé.

LCP — Largest Contentful Paint

Čas, kým sa zobrazí najväčší obsahový prvok vo viditeľnej časti stránky. Väčšinou je to hlavný obrázok, banner alebo veľký blok textu.

| Hodnota | Vyhodnotenie | |---|---| | do 2,5 s | dobré | | 2,5 – 4,0 s | treba zlepšiť | | nad 4,0 s | slabé |

LCP je metrika, ktorú kazia obrázky. Fotka 3 200 × 2 100 px, ktorá sa v prehliadači zobrazí ako 800 px široká, sa musí celá stiahnuť. Na e-shope s veľkou fotkou produktu je to najčastejší dôvod, prečo LCP presiahne 4 sekundy.

INP — Interaction to Next Paint

Čas od kliknutia alebo ťuknutia po moment, kedy prehliadač vykreslí odpoveď. V marci 2024 nahradilo INP staršiu metriku FID. Rozdiel je podstatný: FID meralo len oneskorenie prvej interakcie, INP zohľadňuje priebeh celej návštevy a berie najhoršie interakcie.

| Hodnota | Vyhodnotenie | |---|---| | do 200 ms | dobré | | 200 – 500 ms | treba zlepšiť | | nad 500 ms | slabé |

INP kazí JavaScript. Chat widget, tri analytické skripty, carousel, cookie lišta, pixel na retargeting — každý z nich blokuje hlavné vlákno. Na mobilnom telefóne za 200 eur to nie je 30 ms, ale 600.

CLS — Cumulative Layout Shift

Bezrozmerné číslo, ktoré vyjadruje, ako veľmi obsah počas načítania poskakuje. Chcete kliknúť na odkaz, nad ním sa doloží banner, obsah sa posunie a kliknete inam.

| Hodnota | Vyhodnotenie | |---|---| | do 0,1 | dobré | | 0,1 – 0,25 | treba zlepšiť | | nad 0,25 | slabé |

CLS má najlacnejšie opravy. Vo veľkej väčšine prípadov ide o obrázky a iframy bez uvedených rozmerov, prípadne o reklamy a lišty vkladané do toku stránky.

Prečo sa vaše číslo z testu líši od toho v Search Console

Toto mýli veľa ľudí. Existujú dva druhy dát:

Laboratórne dáta vznikajú tak, že nástroj (napríklad PageSpeed Insights v režime analýzy) načíta stránku v simulovanom prostredí. Dostanete okamžitý výsledok a zoznam príčin. Číslo je ale len modelová situácia — jedno zariadenie, jedna rýchlosť pripojenia.

Dáta od reálnych používateľov zbiera Chrome od skutočných návštevníkov. Do vyhodnotenia ide 75. percentil za posledných 28 dní. To znamená: nie priemer, ale hodnota, ktorú dosiahnu tri štvrtiny návštev. Práve tieto čísla vidíte v Search Console v prehľade Core Web Vitals.

Z toho vyplývajú dve praktické veci. Prvá: po nasadení opravy sa údaje v Search Console nezmenia hneď. Kým sa 28-dňové okno naplní novými návštevami, uplynie približne mesiac. Druhá: ak má stránka málo návštev, reálne dáta pre ňu vôbec nemusia existovať a hodnotí sa podľa skupiny podobných URL alebo celého webu.

Čo spomaľuje weby najčastejšie

Pri prechádzaní webov sa opakujú tie isté príčiny. V poradí podľa toho, ako často ich nachádzam:

1. Nezmenšené obrázky. Nahraný originál z fotoaparátu alebo z fotobanky. Riešenie: zmenšiť na maximálnu zobrazovanú šírku a uložiť vo WebP. Pri fotke produktu sa dá typicky ísť z 2 MB na 150 kB bez viditeľného rozdielu.

2. Obrázky bez atribútov width a height. Prehliadač nevie, koľko miesta si má rezervovať, a po dotiahnutí obrázka posunie obsah. Priamy dopad na CLS.

3. Lazy loading nasadený aj na hlavný obrázok. Odkladané načítanie je dobré pre obrázky nižšie na stránke. Ak ho dáte na hero obrázok, LCP sa zhorší, pretože prehliadač ho začne stahovať neskoro.

4. Príliš veľa skriptov tretích strán. Každý pixel, chat a A/B nástroj má cenu. Skontrolujte, ktoré tam ostali po kampaniach, ktoré už dávno neprebiehajú.

5. Pomalá odpoveď servera. Ak samotné TTFB (čas do prvého bajtu) trvá 1,5 sekundy, žiadna optimalizácia obrázkov to nezachráni. Príčinou je zvyčajne zdieľaný hosting, chýbajúca cache alebo ťažké dopyty do databázy.

6. Fonty. Vlastný font bez font-display: swap znamená, že text je chvíľu neviditeľný. Načítanie štyroch rezov, z ktorých používate dva, je zbytočná záťaž.

7. Šablóna a nadbytočné pluginy. Vo WordPresse je bežné, že šablóna nesie funkcie, ktoré nepotrebujete, a každý plugin pridá svoje CSS a JS na každú stránku.

Poradie, v akom to riešiť

Optimalizácia rýchlosti sa dá robiť donekonečna. Preto poradie podľa vzťahu úsilie a výsledok:

1. Zmerajte, kde ste. Zistite hodnoty LCP, INP a CLS pre najdôležitejšie typy stránok: domovská, kategória, detail produktu alebo článku. Nie pre celý web ako jedno číslo.
2. Vyriešte obrázky. Zmenšenie, WebP, správne rozmery v HTML, lazy loading len pod viditeľnou časťou. Toto je najväčší posun za najmenej práce.
3. Prejdite skripty tretích strán. Vyhoďte, čo nepoužívate. Zvyšok načítavajte odloženo, ak to nástroj dovoľuje.
4. Skontrolujte TTFB a cache. Zapnutá stránková cache mení hodnoty výrazne. Ak je TTFB stále vysoké, problém je v hostingu.
5. Až potom sa venujte CSS a JavaScriptu šablóny. Tu už väčšinou potrebujete niekoho, kto rozumie kódu.

Jednu vec spomeniem otvorene: kroky 1 až 3 zvládnete sami. Krok 5 nie, ak nepíšete kód. Nemá zmysel tvrdiť opak.

Čo v tejto oblasti robím a čo nie

Pri prechádzaní webu označím stránky, ktoré sa načítavajú pomaly, a uvediem, čo ich spomaľuje — napríklad ktoré obrázky sú neúmerne veľké alebo kde chýbajú rozmery. Nález dostanete s konkrétnou URL, nie ako všeobecné odporúčanie „zrýchlite web".

Čo nespravím: nezmením vám hosting, neprepíšem šablónu a nezasiahnem do JavaScriptu. Hotový text opravy píšem pri nálezoch, kde sa oprava dá vyjadriť textom — titulky, meta popisy, alt texty, štruktúrované dáta. Rýchlosť je iná kategória; tam dodám presné zadanie, čo opraviť a na ktorej stránke.

A keď opravu nasadíte, viem overiť dopad: porovnám 28 dní pred a 28 dní po zmene. Nie dojmom, že „to teraz behá lepšie", ale čo sa stalo s návštevnosťou z vyhľadávania.

Čo si z toho odniesť

Hraničné hodnoty, ktoré si stačí zapamätať: LCP do 2,5 s, INP do 200 ms, CLS do 0,1. Hodnotí sa 75. percentil reálnych návštev za 28 dní, takže výsledok opravy uvidíte s odstupom približne mesiaca.

Rýchlosť nie je náhrada za obsah. Je to prekážka, ktorá vám môže brať návštevy, aj keď máte lepší obsah než konkurencia. Väčšina prekážok pritom leží v obrázkoch a skriptoch, ktoré tam nikto nechcel — len ich nikto neodstránil.

#seoobsah