Core Web Vitals: LCP, INP ja CLS käytännössä

Core Web Vitals on Googlen kolmen mittarin kokonaisuus, joka arvioi sivuston käyttökokemusta. Nämä mittarit vaikuttavat suoraan hakusijoituksiin, ja vuonna 2026 niiden painoarvo on entistä suurempi.

Mittarit ovat LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ja CLS (Cumulative Layout Shift). Jokainen mittaa eri puolta käyttökokemuksesta: latausnopeutta, interaktiivisuutta ja visuaalista vakautta.

LCP: suurimman sisältöelementin latausaika

LCP mittaa, kuinka kauan kestää, ennen kuin sivun tärkein visuaalinen elementti on renderöity. Tämä on tyypillisesti hero-kuva, otsikko tai suuri tekstilohko.

Tavoitearvot

• Hyvä: alle 2,5 sekuntia
• Parantamisen varaa: 2,5-4,0 sekuntia
• Huono: yli 4,0 sekuntia

Mikä aiheuttaa hidasta LCP:tä

Hitaat palvelinvastaukset. Jos palvelimen TTFB (Time to First Byte) on hidas, kaikki muu viivästyy. Mittaa TTFB Google Search Consolesta tai WebPageTestillä. Jos se ylittää 600 ms, ongelma on palvelimessa tai DNS:ssä.

Render-estävät resurssit. CSS- ja JavaScript-tiedostot, jotka estävät sivun renderöinnin. Kriittinen CSS pitää olla inline-muodossa, ja ei-kriittinen CSS ladattava asynkronisesti.

Hitaat kuvalataukset. Hero-kuva on usein LCP-elementti. Jos se on 3 MB:n PNG-tiedosto, LCP kärsii.

Client-side rendering. Jos sivun sisältö renderöidään kokonaan JavaScriptillä selaimessa, LCP on väistämättä hidas.

Käytännön korjaukset

1. Optimoi kuvat. Käytä WebP- tai AVIF-formaattia. Aseta kuvien mitat HTML:ssä. Käytä `loading="eager"` ja `fetchpriority="high"` LCP-kuvalle.

1. Esilataa kriittiset resurssit. Lisää `<link rel="preload">` fonteille ja hero-kuville.

1. Käytä palvelinpuolen renderöintiä. Next.js:n SSR tai SSG varmistaa, että HTML sisältää sisällön valmiiksi, eikä selain joudu odottamaan JavaScriptin suoritusta.

1. CDN ja välimuisti. Tarjoile staattiset resurssit CDN:n kautta ja aseta aggressiiviset välimuistiotsikot.

1. Pienennä TTFB. Päivitä hosting, ota käyttöön HTTP/2 tai HTTP/3, ja minimoi palvelinpuolen prosessointi.

INP: interaktiivisuuden mittari

INP korvasi FID:n (First Input Delay) maaliskuussa 2024. Siinä missä FID mittasi vain ensimmäistä interaktiota, INP mittaa kaikkia interaktioita koko sivuvierailun aikana ja raportoi huonoimman tuloksen (poislukien poikkeamat).

Tavoitearvot

• Hyvä: alle 200 millisekuntia
• Parantamisen varaa: 200-500 millisekuntia
• Huono: yli 500 millisekuntia

Mikä aiheuttaa huonoa INP:tä

Raskas JavaScript. Pitkät main thread -tehtävät estävät selainta reagoimasta käyttäjän toimintaan. Jos JavaScript-tehtävä kestää 300 ms, selaimen reagointi viivästyy sen verran.

Kolmannen osapuolen skriptit. Analytics, chat-widgetit ja mainosskriptit kilpailevat main threadistä. Jokainen lisätty skripti kasvattaa riskiä.

Monimutkaiset DOM-päivitykset. Jos klikkaus laukaisee tuhannen DOM-noodin päivityksen, renderöinti vie aikaa.

Käytännön korjaukset

1. Pilko pitkät tehtävät. Käytä `requestAnimationFrame`, `setTimeout` tai `scheduler.yield()` pilkkomaan yli 50 ms kestävät JavaScript-tehtävät pienempiin osiin.

1. Vähennä JavaScriptiä. Auditoi kolmannen osapuolen skriptit. Poista kaikki, mitä et oikeasti tarvitse. Käytä `defer`- ja `async`-attribuutteja.

1. Virtualisoi pitkät listat. Jos sivulla on satoja elementtejä, renderöi vain näkyvät elementit (esim. react-window tai vastaava ratkaisu).

1. Debounce ja throttle. Rajoita toistuvia tapahtumankäsittelijöitä (scroll, resize, input).

1. Käytä Web Workers -tekniikkaa. Siirrä raskas laskenta pois main threadistä.

CLS: visuaalinen vakaus

CLS mittaa, kuinka paljon sivun sisältö siirtyy odottamattomasti latauksen aikana. Olet varmasti kokenut tämän: painat nappia, ja juuri sillä hetkellä sivu hyppää ja klikkaat väärään kohtaan.

Tavoitearvot

• Hyvä: alle 0,1
• Parantamisen varaa: 0,1-0,25
• Huono: yli 0,25

Mikä aiheuttaa CLS-ongelmia

Kuvat ilman mittoja. Jos kuvan leveyttä ja korkeutta ei ole määritelty, selain ei varaa sille tilaa ennen latautumista. Kun kuva latautuu, muu sisältö siirtyy.

Dynaamisesti lisätty sisältö. Mainokset, bannerit ja upotukset, jotka ilmestyvät vasta JavaScriptin suorituksen jälkeen.

Verkkofontit (FOUT/FOIT). Fontin vaihtuessa tekstin koko ja leveys muuttuvat, mikä aiheuttaa layout shiftejä.

Animaatiot, jotka muuttavat layoutia. CSS-ominaisuudet kuten `top`, `left`, `width` ja `height` laukaisevat layout-laskennan. `transform` ja `opacity` eivät.

Käytännön korjaukset

1. Aseta kuvien mitat aina. HTML:ssä `width` ja `height` tai CSS:ssä `aspect-ratio`. Tämä yksi toimenpide korjaa suuren osan CLS-ongelmista.

1. Varaa tila dynaamiselle sisällölle. Jos tiedät, että mainos on 300x250 pikseliä, varaa sille tila CSS:llä etukäteen.

1. Käytä `font-display: swap` harkiten. Parempi vaihtoehto on esilatata fontit `<link rel="preload">` ja käyttää `font-display: optional`, joka välttää layout shiftin kokonaan.

1. Animoi vain transform ja opacity. Nämä ominaisuudet eivät laukaise layout-laskentaa, joten ne eivät aiheuta CLS:ää.

1. Vältä sisällön injektointia olemassa olevan sisällön yläpuolelle. Jos lisäät elementtejä dynaamisesti, lisää ne sivun alaosaan tai käytä CSS-containmentia.

Miten mittaat Core Web Vitals -arvoja

Kenttädata (oikeilta käyttäjiltä)

• Google Search Console: Näyttää CWV-tiedot URL-tasolla. Tämä on Googlen virallinen mittari sijoituksia varten.
• Chrome User Experience Report (CrUX): Julkinen dataset, johon pääsee BigQueryn, PageSpeed Insightsin tai CrUX-dashboardin kautta.
• web-vitals JavaScript -kirjasto: Lisää oma mittaus sivustollesi ja lähetä data analytiikkatyökaluun.

Laboratoriodata (simuloitu)

• Lighthouse: Chrome DevToolsissa tai komentoriviltä. Simuloi hitaan yhteyden ja laitteen.
• PageSpeed Insights: Yhdistää CrUX-kenttädatan ja Lighthouse-laboratoriotestin.
• WebPageTest: Yksityiskohtaisin työkalu, jolla voit testata eri laitteilta ja sijainneista.

Tärkeä ero: kenttädata kertoo, miten oikeat käyttäjät kokevat sivuston. Laboratoriodata on kontrolloitu testi. Google käyttää sijoituspäätöksissä kenttädataa. Laboratoriodata on hyödyllinen ongelmien diagnosointiin.

Priorisointi: mistä aloittaa

Jos kaikki kolme mittaria ovat punaisella, priorisoi näin:

1. LCP ensin. Se vaikuttaa eniten hakusijoituksiin ja käyttäjien ensivaikutelmaan. Kuvaoptimointi ja palvelinvasteajan parantaminen tuottavat yleensä nopeimmat tulokset.

1. CLS toiseksi. Se on usein helpoin korjata. Kuvien mittojen lisääminen ja fonttien esilataaminen korjaavat tyypilliset ongelmat tunnissa.

1. INP viimeisenä. Se on vaikein korjata, koska vaatii usein JavaScript-arkkitehtuurin muutoksia. Aloita kolmannen osapuolen skriptien auditoinnista.

Core Web Vitals ja sijoitukset

Google on sanonut suoraan, että Core Web Vitals on sijoitustekijä. Se ei kuitenkaan ole ainoa tai edes tärkein tekijä. Loistava sisältö huonoilla CWV-arvoilla voi silti sijoittua korkealle. Mutta jos kaksi sivua ovat sisällöltään tasavertaisia, paremmat CWV-arvot ratkaisevat.

Käytännössä CWV-optimointi ei ole vain SEO-toimenpide. Se on käyttäjäkokemustyötä. Nopeammat sivut konvertoivat paremmin. Amazon raportoi, että jokainen 100 ms lisäviive latausajassa vähensi myyntiä 1 %. Sama pätee pienemmässä mittakaavassa jokaiseen verkkokauppaan ja palvelusivustoon.

Mittaa, korjaa, mittaa uudelleen. CWV-optimointi on jatkuva prosessi, ei kertaluontoinen projekti.