Core Web Vitals: täielik juhend (LCP, CLS, INP)

Mis on Core Web Vitals?

Google'i poolt loodud kolm UX-mõõdikut, mis mõjutavad otseselt SEO positsioone. Halb skoor = kaotatud nähtavus.

1. LCP – Largest Contentful Paint

Mida mõõdab: Kui kaua võtab suurima elemendi (tavaliselt hero-pildi või pealkirja) ilmumine.

Eesmärk: < 2.5 sekundit

Tavalised põhjused, miks halb: - Suur optimeerimata hero-pilt - Aeglane server (TTFB > 600ms) - Render-blokeerivad CSS/JS failid - Webfondid laaditakse hiljem

Lahendused: - Preload kriitiline hero-pilt: <link rel="preload" as="image"> - WebP/AVIF formaat - CDN - font-display: swap

2. CLS – Cumulative Layout Shift

Mida mõõdab: Kui palju leht "hüppab" laadimise ajal. Ärritav, kui nupp liigub vajutamise hetkel.

Eesmärk: < 0.1

Tavalised põhjused: - Pildid ilma width/height atribuutideta - Reklaamid, mis laaditakse hiljem - Webfondid (FOUT) - Dünaamiline sisu

Lahendused: - Lisa kõikidele piltidele width ja height - Reserveeri ruum reklaamidele - font-display: optional või swap koos size-adjust - CSS aspect-ratio

3. INP – Interaction to Next Paint

Asendas FID 2024. aastal. Mõõdab, kui kiiresti leht reageerib kasutaja klikile, puudutusele või klahvile.

Eesmärk: < 200ms

Tavalised põhjused: - Rasked JavaScript-tööriistad - Liiga palju event listenereid - Third-party skriptid (chat, analytics) - React/Vue lehed ilma optimeerimiseta

Lahendused: - Code splitting - Debounce ja throttle - requestIdleCallback() raskete tööde jaoks - Eemalda kasutamata third-party skriptid

Kuidas mõõta?

1. PageSpeed Insights – pagespeed.web.dev
2. Google Search Console → Core Web Vitals raport
3. Chrome DevTools → Performance tab
4. CrUX (Chrome User Experience Report) – päris kasutajate andmed

Labor vs. väliandmed – miks skoorid erinevad

PageSpeed Insights näitab kahte asja korraga ja neid aetakse pidevalt segi. Ülemine osa ("Discover what your real users are experiencing") on väliandmed CrUX-ist: päris külastajate mõõtmised viimase 28 päeva jooksul. Alumine osa on laboriandmed – üks simuleeritud laadimine Lighthouse'i mootoris, fikseeritud 4G-ühenduse ja aeglustatud protsessoriga.

Google kasutab otsingus ainult väliandmeid. See tähendab kolme praktilist asja:

• Lighthouse'i skoor 100 ei tähenda, et Core Web Vitals oleks "läbitud" – see on ainult ennustus.
• Pärast parandust kulub kuni 28 päeva, enne kui Search Console'i raport muutub roheliseks. Ära arva pärast kolme päeva, et parandus ei töötanud.
• Kui lehel pole piisavalt liiklust, väliandmeid ei näidata ja Google kasutab domeeni tasandi (origin-level) andmeid. Väikese lehe puhul mõjutab avaleht siis ka alamlehtede hinnangut.

Mõõdikud loetakse läbituks, kui 75% laadimistest jääb piirmäära alla – eraldi mobiilis ja arvutis. Mobiil on peaaegu alati see, mis kukub läbi.

Kuidas leida päris pudelikael

Skoori vaatamine ei ütle, mida parandada. Praktiline järjekord:

1. Chrome DevTools → Performance → salvesta laadimine mobiiliemulatsioonis, 4x CPU aeglustusega. Otsi LCP-marker ajajoonelt ja vaata, mis element see on.
2. DevTools → Network → sorteeri "Time" – kui TTFB on üle 600 ms, siis ei ole probleem esiotsas, vaid serveris või vahemälus.
3. CLS jaoks lülita sisse DevTools → Rendering → Layout Shift Regions – ekraanil vilguvad täpselt need alad, mis hüppavad.
4. INP jaoks kasuta Performance paneeli "Interactions" rada – see näitab, milline sündmuskäsitleja pika ülesande (long task) tekitab.
5. web-vitals JS-teek lehel endal saadab päris kasutajate mõõtmised analüütikasse, nii et sa ei sõltu ainult kuu vanustest CrUX-andmetest.

Tüüpilised WordPressi põhjused

Enamik Eesti väikeettevõtte lehti kukub läbi samadel põhjustel ja need on kõik lahendatavad ilma lehte ümber tegemata:

• Slider avalehel. Revolution Slider ja sarnased laadivad mitu suurt pilti ning oma JavaScripti enne esimest renderdust. Slider on peaaegu alati kõige kallim element lehel ja harva see, mida külastaja kasutab.
• Kolm cache-pluginat korraga. Konfliktsed vahemälud tekitavad olukorra, kus CSS-i "optimeerimine" laadib faile hoopis hiljem.
• Google Fonts kolmandalt domeenilt. Fondi allalaadimine lisab eraldi DNS-i ja TLS-i ringi. Iselaaditud WOFF2 fail koos font-display: swap ja size-adjust väärtusega lahendab nii LCP kui CLS.
• Chat-vidin ja piksleid neli tükki. Iga kolmanda osapoole skript käivitub põhilõimes ja lööb otse INP-d. Laadi need kasutaja esimese interaktsiooni järel, mitte lehe laadimisel.
• Jagatud hostimine ilma objekt-vahemäluta. Kui TTFB kõigub 800 ms ja 2 s vahel, ei aita ükski esiotsa trikk – vaja on paremat majutust või serveripoolset lehe vahemälu.

Mis on realistlik ajakava

Ühe keskmise WordPressi lehe puhul jaguneb töö tavaliselt nii: piltide formaadi ja mõõtude korda tegemine ning hero-pildi preload umbes pool päeva, fontide iselaadimine ja paigutuse reserveerimine paar tundi, kolmandate skriptide edasilükkamine pool päeva, serveripoolne vahemälu ja TTFB olenevalt majutusest tund kuni terve päev. Pärast seda tuleb oodata CrUX-i akna täitumist.

Ära optimeeri seda, mida ei mõõda. Kui LCP on 4,2 s ja CLS 0,02, siis CLS-i puudutamine ei anna midagi – kogu aeg tuleb panna suurima elemendi kiirendamisse.

Kokkuvõte

Core Web Vitals on tehniline, aga oluline. Hea uudis: korralik haldus parandab kõiki kolme korraga ja hoiab need korras. Halb uudis: ilma haldusega lagunevad nad iga uue plugin-uuenduse, uue bänneri ja uue jälgimisskriptiga tagasi. Mõõda väliandmeid, paranda suurimat pudelikaela, oota 28 päeva, korda.