Core Web Vitals 2026 – LCP-, INP- ja CLS-opas suomeksi
Core Web Vitals voi ratkaista, nouseeko sivustosi kärkisijoille vai jääkö toiselle sivulle – silloin kun sisältö on tasavahvaa kilpailijoiden kanssa. Maaliskuussa 2024 Google korvasi FID:n INP:llä, mutta suurin osa suomenkielisistä SEO-oppaista puhuu yhä vanhasta mittarista. Tässä oppaassa käydään läpi LCP-, INP- ja CLS-raja-arvot vuonna 2026, yleisimmät syyt heikkoihin pisteisiin, mittaustyökalut ja konkreettiset WordPress-korjausohjeet.
Core Web Vitals 2026 – avainpoiminnat: Kolme mittaria – LCP alle 2,5 s (latausnopeus), INP alle 200 ms (responsiivisuus) ja CLS alle 0,1 (vakaus). Kaikki vaikuttavat Googlen sijoituksiin. FID korvattiin INP:llä maaliskuussa 2024. Mittarit arvioidaan 75. persentiilin mukaan aidosta Chrome-käyttäjädatasta. Yleisin LCP-ongelma ovat raskaat kuvat, yleisin INP-ongelma on kolmannen osapuolen JavaScript, ja yleisin CLS-ongelma ovat puuttuvat kuvamitat. Tavallinen WordPress-sivun korjaus maksaa 500–3 000 € kertaluonteisena.
Mitä Core Web Vitals ovat ja miksi ne ratkaisevat
Core Web Vitals on Googlen virallinen mittaristo, jolla arvioidaan verkkosivun käyttäjäkokemuksen teknistä laatua. Mittaristo otettiin käyttöön Googlen ranking-signaalina kesäkuussa 2021 osana Page Experience -päivitystä, ja sitä on tarkennettu useaan otteeseen – viimeksi maaliskuussa 2024, kun FID korvattiin INP:llä.
Mittaristo mittaa kolmea asiaa, jotka käyttäjä aidosti kokee sivustollasi (ks. web.dev:n virallinen Vitals-opas):
- Latausnopeus – milloin sivun pääsisältö näkyy käyttäjälle (LCP)
- Responsiivisuus – kuinka nopeasti sivu vastaa, kun käyttäjä klikkaa, kirjoittaa tai tekee valinnan (INP)
- Visuaalinen vakaus – pysyykö asettelu paikallaan vai hyppääkö sisältö latauksen aikana (CLS)
Googlen virallisen Core Web Vitals -dokumentaation mukaan mittaristo on osa Page Experience -signaalia. Käytännössä tämä tarkoittaa, että jos kaksi sivua kilpailee samasta sijoituksesta yhtä hyvällä sisällöllä, Core Web Vitals voi ratkaista voittajan.
Core Web Vitals vs. yleinen ”sivuston nopeus”
Monet sekoittavat Core Web Vitalsin yleisiin PageSpeed Insights -pisteisiin (0–100). Ne eivät ole sama asia. PageSpeed Insights -pisteet ovat kokoelma yli 40 eri mittaria, ja vain kolme niistä kuuluu Core Web Vitalsiin. Vain Core Web Vitals -mittarit vaikuttavat Googlen sijoituksiin – muut PageSpeed-mittarit ovat diagnostisia, eivät varsinaisia rankingtekijöitä.
Core Web Vitals -raja-arvot 2026
Google arvioi jokaisen mittarin kolmella tasolla: Hyvä (Good), Parannusta vaativa (Needs Improvement) ja Heikko (Poor). Sivuston täytyy saavuttaa ”Hyvä”-taso kaikissa kolmessa mittarissa läpäistäkseen Core Web Vitalsin kokonaisuutena.
Miksi 75. persentiili ratkaisee, ei keskiarvo
Google arvioi Core Web Vitalsin 75. persentiilin mukaan – eli vähintään 75 % sivustollasi käyvistä aidoista käyttäjistä täytyy saada hyvä käyttökokemus, jotta sivu läpäisee testin. Tämä ei ole keskiarvo eikä mediaani. Se kuvaa hitaimman neljänneksen rajaa.
Miksi tämä on tärkeää? Esimerkki: sivusto saa LCP:n 1,8 s nopealla kuituyhteydellä työpöytälaitteella, mutta 4,2 s iOS Safarilla 4G-verkossa. Mittarit lasketaan erikseen mobiili- ja desktop-alustoille. Jos 30 % käyttäjistä käyttää hidasta mobiilia ja heidän LCP-arvonsa on 4,2 s, koko sivu saa ”heikko”-luokituksen, vaikka 70 % kokisi sen nopeaksi.
Käytännön oppi: Älä optimoi omaa nopeaa MacBookiasi ja kuituyhteyttäsi varten. Optimoi hitainta neljännestä käyttäjistäsi – he ovat ne, jotka määrittävät sijoituksesi.
Miksi FID korvattiin INP:llä maaliskuussa 2024
Kaksi vuotta sitten Google teki merkittävän muutoksen: FID (First Input Delay) poistettiin Core Web Vitals -mittaristosta ja tilalle tuli INP (Interaction to Next Paint). Tämä on tärkein muutos Core Web Vitalsissa viimeisen kahden vuoden aikana, ja suurin osa suomenkielisistä SEO-oppaista on yhä vanhentuneita.
Mikä oli FID:n ongelma
FID mittasi vain ensimmäisen klikkauksen viivettä – aikaa, joka kuluu siitä, kun käyttäjä klikkaa ensimmäisen kerran, siihen, kun selain alkaa vastata siihen. Ongelma: sivu voi vastata ensimmäiseen klikkaukseen välittömästi, mutta jäätyä täysin myöhempiin vuorovaikutuksiin.
Kuvittele tämä: klikkaat linkkiä – vastaus heti. Klikkaat lomakkeen pudotusvalikkoa – odotat 800 ms. Täytät kentän – selain reagoi viiveellä. FID antaisi tälle sivulle täydet pisteet ensimmäisen klikkauksen perusteella, vaikka todellinen käyttökokemus on heikko.
Mitä INP mittaa sen sijaan
INP mittaa koko sivuvierailun hitaimman vuorovaikutuksen vasteaikaa. Jos käyttäjä tekee sivulla 100 vuorovaikutusta, INP on käytännössä 98. persentiilin (tyypillisesti pisin tai toiseksi pisin) vasteaika.
- Input Delay: aika käyttäjän toiminnosta siihen, kun selain alkaa prosessoida tapahtumankäsittelijää
- Processing Time: aika, jonka tapahtumankäsittelijä kestää suorittaa (esim. JavaScriptin suoritus)
- Presentation Delay: aika tapahtumankäsittelijän jälkeen siihen, kun selain päivittää näytön
Yhteensä: INP = Input Delay + Processing Time + Presentation Delay. Käytännössä jokainen vuorovaikutus mitataan, ja hitain tai toiseksi hitain määrittää koko sivun INP-arvon.
Mitä tämä tarkoittaa käytännössä
Sivusto, joka läpäisi FID:n helposti, voi nyt epäonnistua INP:ssä. Erityisesti seuraavat sivut ovat vaarassa:
- Lomakkeet – useita kenttäkohtaisia vuorovaikutuksia
- Suodattimet ja valikot – jokainen valinta voi aiheuttaa JavaScript-uudelleenrenderöinnin
- Checkout ja maksusivut – monta vaihetta raskailla kolmansilla osapuolilla
- Interaktiiviset karusellit, välilehdet ja pudotusvalikot
- Sivut, joilla on paljon analytiikkaa ja chat-widgettejä
Jos sivustosi INP on yli 500 ms, se on aidosti kriittisessä tilassa. Tämä on yksi yleisimpiä syitä Googlen liikenteen pudotukseen vuoden 2024 jälkeen.
Core Web Vitals -mittaustyökalut: 4 ilmaista tapaa
Core Web Vitals voidaan mitata usealla tavalla, mutta ammattilaisen kannattaa tietää neljän työkalun erot. Kaikki ovat ilmaisia ja Googlen virallisia tai vahvasti tukemia.
Google PageSpeed Insights (pagespeed.web.dev)
Paras pikadiagnoosiin yksittäisillä sivuilla. Näyttää sekä kenttädatan (aidot käyttäjät, 28 päivän rullaava ikkuna) että lab-datan (simulaatio). Antaa konkreettiset korjausehdotukset per mittari. Mobiili- ja desktop-tulokset erikseen. Testaa PageSpeed Insights -työkalulla suoraan.
Google Search Console – Core Web Vitals -raportti
Paras koko sivuston seurantaan. Perustuu aitoon Chrome User Experience Report -dataan. Ryhmittelee URL:t samantyyppisiksi ja näyttää ongelmat per ryhmä. Löytyy Search Consolen vasemmasta valikosta ”Experience → Core Web Vitals”. Huom: vaatii vähintään noin 500 näyttökertaa kuukaudessa, jotta dataa olisi riittävästi.
Web Vitals Chrome -lisäosa
Paras kehitys- ja testausvaiheeseen. Näyttää reaaliaikaiset LCP-, INP- ja CLS-arvot sivua selatessasi. Toimii myös paikallisissa testiympäristöissä. Lataa Chrome Web Storesta. Tämä on yksi tärkeimmistä on-page-työkaluista tekniseen testaukseen.
Chrome DevTools Lighthouse
Paras syväanalyysiin. Sisäänrakennettu Chromen kehittäjätyökaluihin (F12 → Lighthouse-välilehti). Antaa lab-pisteet (ei kenttädataa), mutta tarjoaa erittäin tarkat korjausehdotukset koodirivien tarkkuudella. INP-ongelmien juurten etsinnässä välttämätön.
Kenttädata vs. lab-data – kumpi ratkaisee
Yksi yleisimmistä virheistä on sekoittaa lab-data ja kenttädata. Nämä kaksi voivat poiketa toisistaan merkittävästi, ja vain toinen ratkaisee Googlen silmissä.
| Ominaisuus | Kenttädata | Lab-data |
|---|---|---|
| Mistä tulee | Aidot Chrome-käyttäjät, 28 päivän rullaava ikkuna | Simulaatio vakio-olosuhteissa |
| Vaikuttaa Googlen sijoituksiin | Kyllä | Ei |
| Näkyy missä | Search Console, PageSpeed Insights (yläosa) | PageSpeed Insights (alaosa), Lighthouse |
| Vaatii liikennettä | Kyllä, noin 500+ käyntiä kuukaudessa | Ei |
| Päivittyy | 28 päivän viiveellä | Heti |
| Käytä kun | Haluat tietää todellisen vaikutuksen sijoituksiin | Kehitys ja debuggaus |
Käytännön työjärjestys:
- Tee korjaukset ja testaa lab-datalla (PageSpeed Insights tai Lighthouse)
- Julkaise muutokset
- Odota 2–4 viikkoa, jotta kenttädata päivittyy
- Varmista parannus Google Search Consolen Core Web Vitals -raportista
Varoitus: Jos PageSpeed Insightsin kenttädata ja lab-data eroavat merkittävästi, luota aina kenttädataan. Kenttädata kertoo, mitä aidot käyttäjät kokevat – lab-data simuloi vain yhtä mahdollista käyttötilannetta.
LCP – latausnopeuden syvennys ja korjaukset
LCP (Largest Contentful Paint) mittaa aikaa siitä, kun sivu alkaa latautua, siihen, kun näkymäalueen suurin sisältöelementti (yleensä hero-kuva, videon esikatselukuva tai iso tekstilohko) tulee näkyviin. Tämä on ”käyttäjän kokema latausnopeus” – hetki, jolloin sivu näyttää valmistuneelta.
Mikä elementti on LCP?
Google tarkastelee näkymäalueella näkyviä elementtejä ja valitsee suurimman. Tyypilliset LCP-elementit ovat hero-kuva (yleisin LCP WordPress-sivuilla), suuri tekstilohko (esim. H1 + leipäteksti), videon ensimmäinen ruutu tai hero-taustakuva CSS:ssä.
4 yleisintä syytä huonoon LCP:hen
Hidas palvelinvaste (TTFB yli 800 ms)
Jos Time To First Byte on yli 600 ms, sivun lataus alkaa jo myöhässä. Korjaus: nopeampi webhotelli (vältä jaettua webhotellia kilpailluilla sivustoilla), CDN (Cloudflaren ilmainen taso usein riittää), palvelinpuolen välimuisti ja tietokantaoptimointi.
Optimoimattomat hero-kuvat
Yleisin LCP-ongelma WordPress-sivuilla. 2 MB:n pakkaamaton JPEG-kuva ei käytännössä läpäise LCP:tä mobiilissa. Korjaus: WebP- tai AVIF-formaatti (50–70 % pienempi), oikeat responsiiviset koot srcset-attribuutilla, lazy loading muille kuville mutta ei hero-kuvalle sekä <link rel="preload"> hero-kuvalle.
Renderöinnin estävä CSS ja JavaScript
Jos <head>-elementissä on iso CSS-tiedosto tai synkroninen JavaScript-skripti, selain ei voi renderöidä mitään ennen niiden latausta. Korjaus: kriittinen CSS inline-muotoon, loput async– tai defer-attribuutilla. Poista käyttämätön CSS.
Client-side-renderöinti ilman SSR:ää
Jos sivu renderöidään vasta JavaScriptillä selaimessa (esim. React SPA ilman SSR:ää), LCP odottaa JavaScriptin latausta ja suoritusta. Korjaus: server-side-renderöinti (Next.js SSR, Nuxt) tai Static Site Generation, joka tuottaa valmiin HTML:n palvelimella.
Konkreettinen koodiesimerkki: hero-kuvan preload
Yksi nopeimmista LCP-parannuksista WordPress-sivuille on hero-kuvan esilataus. Lisää <head>-elementtiin:
Tämä käskee selainta priorisoimaan hero-kuvan latauksen ennen muita resursseja. Tyypillinen parannus: LCP laskee 500–1 000 ms.
INP – responsiivisuuden syvennys ja korjaukset
INP (Interaction to Next Paint) on Core Web Vitalsin haastavin mittari – ja samalla se, jonka korjaaminen vaatii eniten teknistä osaamista. INP:tä ei ratkaista pelkällä välimuistilla.
INP:n kolme osa-aluetta
Jokainen vuorovaikutus koostuu kolmesta vaiheesta:
- Input Delay (yleensä 0–100 ms): aika käyttäjän klikkauksesta siihen, kun selaimen pääsäie vapautuu prosessoimaan sen
- Processing Time (yleensä 50–400 ms): aika, jonka tapahtumankäsittelijän JavaScript kestää suorittaa – tämä on yleisin INP:n ongelmakohta
- Presentation Delay (yleensä 0–50 ms): aika tapahtumankäsittelijän jälkeen siihen, kun selain päivittää näytön visuaalisesti
3 yleisintä INP-ongelmaa
Kolmannen osapuolen JavaScript
Google Analytics, Meta Pixel, chat-widgetit (Intercom, LiveChat), mainosverkostot (Google Ads) ja A/B-testaustyökalut (Hotjar). Nämä kaikki suorittavat JavaScriptiä pääsäikeessä ja estävät käyttäjän vuorovaikutuksia. Korjaus: lataa ne asynkronisesti, käytä viivästystä kunnes sivu on valmis ja harkitse server-side-integraatioita.
Raskaat WordPress-sivunrakentajat
Elementor, Divi, WPBakery ja Visual Composer tuottavat kaikki valtavia määriä JavaScriptiä client-puolelle. Erityisesti Elementor Pron widget-kirjasto on INP-ongelmien aiheuttaja. Korjaus: Elementorin light mode, minimalistinen teemapohja tai siirtyminen kevyempään ratkaisuun (Gutenberg-blokit, Bricks Builder, Breakdance).
Pitkät JavaScript-tehtävät (Long Tasks)
Yli 50 ms kestävät JavaScript-tehtävät estävät pääsäikeen toimintaa. Erityisesti sivuston latauksen alussa tehtävät raskaat alustukset (analytiikka, mainokset, hydration) aiheuttavat INP-ongelmia. Korjaus: tehtävien paloittelu (scheduler.yield API), web workerit raskaalle laskennalle ja code splitting.
Käytännön vinkki INP-debuggaukseen: Avaa Chrome DevTools → Performance-välilehti → nauhoita sivun lataus ja klikkaa ongelmallisia elementtejä. Etsi ”Long Tasks” -merkinnät timeline-näkymässä. Jokainen yli 50 ms tehtävä on potentiaalinen INP-ongelma.
CLS – visuaalisen vakauden syvennys ja korjaukset
CLS (Cumulative Layout Shift) mittaa, kuinka paljon sivun elementit liikkuvat odottamatta latauksen aikana. Ajattele tilannetta, jossa yrität klikata linkkiä ja viime hetkellä mainos pomppaa paikalle, ja klikkaat sitä vahingossa – se on CLS-ongelma.
CLS lasketaan matemaattisesti: impact fraction × distance fraction. Kaavaa ei tarvitse muistaa – riittää, että tiedät tämän: mitä suurempi liikkuva elementti ja mitä pidemmän matkan se liikkuu, sitä suurempi CLS.
5 yleisintä CLS-ongelmaa ja korjausta
Kuvat ilman width- ja height-attribuutteja
Yleisin yksittäinen syy. Kun kuva latautuu, selain ei tiedä, kuinka paljon tilaa varata, ja muut elementit hyppäävät kuvan latautuessa. Korjaus: lisää aina width– ja height-attribuutit img-tagiin. WordPressissä mediakirjasto tekee tämän automaattisesti, mutta kustomiteemoissa tämä kannattaa tarkistaa aina.
Mainokset, jotka latautuvat viiveellä
Google AdSense tai muut mainokset ilmestyvät usein 1–3 sekunnin viiveellä ja työntävät sisältöä. Korjaus: määrittele kiinteä tila mainospaikalle etukäteen CSS:llä, esim. .ad-slot { min-height: 250px; }
Web-fontit ja FOIT/FOUT
Kun custom-fontti latautuu, teksti vaihtaa fonttia (FOUT) tai on näkymätön siihen asti (FOIT). Jos uusi fontti on eri kokoinen, teksti työntyy. Korjaus: font-display: optional tai font-display: swap CSS:ssä ja fontin esilataus preload-tagilla.
Evästebannerit ja popupit
Evästebanneri (GDPR-vaatimus) ilmestyy usein 200–500 ms viiveellä ja työntää sisältöä. Korjaus: näytä banneri kiinteällä asemoinnilla, jotta se ei vaikuta layoutiin. Tai sumenna sisältö taustalla, kunnes banneri suljetaan.
Iframe-upotukset ilman mittoja
YouTube-videot, kartat ja sosiaalisen median upotukset upotetaan usein iframella. Jos niillä ei ole width- ja height-attribuutteja, selain varaa tilan myöhässä. Korjaus: käytä CSS:n aspect-ratio-ominaisuutta ja kiinteitä mittoja iframelle.
WordPress-kohtaiset Core Web Vitals -korjaukset
Yli 60 % Suomen yritysten verkkosivuista käyttää WordPressiä. Tässä on todellinen optimointijärjestys – ei ”asenna WP Rocket ja olet valmis”, vaan rehellinen näkymä siitä, mitä pitää tehdä.
Vaihe 1 – Webhotelli ja TTFB (ensimmäinen prioriteetti)
Jos webhotellisi TTFB on yli 600 ms, mikään muu optimointi ei riitä. Vaihda ensin. Suomalaisten toimittajien vertailu on laaja aihe, mutta seuraavat ovat tyypillisesti Core Web Vitals -kelpoisia: Seravo, Louhi, Kinsta, WP Engine ja SiteGround Cloud. Jaettu webhotelli alle 10 €/kk on harvoin riittävä kilpailluille sivustoille.
Vaihe 2 – Välimuistitus
Palvelintason välimuisti (object cache + full-page cache) ja selaimen välimuisti (browser cache). Paras työkalu on palvelintarjoajan oma välimuisti (esimerkiksi Seravon oma välimuisti) tai WP Rocket + LiteSpeed Cache. Vältä monia päällekkäisiä välimuistituksia – ne voivat aiheuttaa konflikteja.
Vaihe 3 – Kuvien optimointi
Asenna ShortPixel tai Imagify – ne konvertoivat kuvat automaattisesti WebP- tai AVIF-formaattiin ja luovat responsiiviset koot. Käytä lazy loadingia (WordPress 5.5+ sisältää natiivin). Hero-kuville fetchpriority="high" ja loading="eager".
Vaihe 4 – Sivunrakentajan arviointi
Jos käytät Elementoria tai Diviä ja INP on heikko, harkitse vaihtoa:
- Gutenberg (WordPressin natiivi) – kevyin, nopein, mutta vaatii tottumista
- Bricks Builder – nopea Core Web Vitals -kannalta, visuaalinen sivunrakentaja
- GeneratePress + GenerateBlocks – erittäin kevyt yhdistelmä
- Elementor ”light mode” – optimoitu versio, vähemmän ominaisuuksia
Vaihe 5 – JavaScript-optimointi
WP Rocketin ”Delay JavaScript execution” viivästyttää kolmannen osapuolen skriptit, kunnes käyttäjä toimii (klikkaa tai vierittää sivua). Tämä parantaa sekä LCP:tä että INP:tä merkittävästi. Varmista, että kriittiset skriptit (esim. cookie consent) eivät viivästy.
Vaihe 6 – Fonttien optimointi
Isännöi fontit itse (älä linkitä Google Fontseja CDN:n kautta). Esilataa (preload) käytetyt variantit. Käytä font-display: swap. Lataa vain tarvittavat painot (ei 300–900, vaan esim. 400 + 700).
Realistinen aikajänne: Keskimääräisen WordPress-sivun Core Web Vitals -optimointi kestää kokeneelta kehittäjältä 8–16 tuntia sivuston koosta ja sivunrakentajasta riippuen. Hintahaarukka: 500–3 000 € kertaluonteisena. Jos vaihdat sivunrakentajaa, puhutaan eri projektista (sisällön migraatio).
Milloin palkata kehittäjä?
Kaikki Core Web Vitals -korjaukset eivät vaadi kehittäjää. Tässä selkeä jaottelu:
| Tehtävä | DIY mahdollista | Kehittäjä suositeltava |
|---|---|---|
| Kuvien optimointi (WebP, pakkaus) | ✅ Lisäosa riittää | |
| Caching-lisäosan asennus | ✅ | |
| Kuvien width- ja height-attribuutit | ✅ WordPress tekee tämän automaattisesti | |
| Evästebannerin kiinteä asemointi | ✅ CSS-rivi | |
| Kolmannen osapuolen skriptien priorisointi | ✅ Vaatii teknistä ymmärrystä | |
| Sivunrakentajan vaihto | ✅ Iso projekti | |
| Kustomikoodimuutokset (defer, async) | ✅ | |
| Server-side-renderöinti / SSR-migraatio | ✅ Kehittäjäprojekti | |
| Hero-kuvan preload + fetchpriority | ✅ Teeman editointi | |
| Webhotellin vaihto | ✅ DIY mahdollista | Tai kumppani, joka tekee migraation |
Palkkaa kehittäjä erityisesti, kun:
- INP on heikko (yli 500 ms) – juurisyyt ovat lähes aina JavaScript-koodissa
- LCP on yli 4 s eikä parane kuvaoptimoinnilla ja välimuistiasetuksilla
- Sivusto on toteutettu kustomikoodilla eikä valmisalustalla
- Käytät Elementoria tai Diviä ja INP ei parane lisäosien avulla
- Sivusto on verkkokauppa, jossa on suuri katalogi
Asiakascase: LCP 3,2 s → 1,6 s, sijoitukset +32 %
Lähtötilanne: Suomalainen verkkokauppa. WordPress, WooCommerce ja Elementor Pro. Kuukausittainen orgaaninen liikenne 4 200 kävijää. LCP mobiilissa oli 3,2 s (Heikko), INP 580 ms (Heikko), CLS oli 0,18 (Parannusta).
Tehdyt toimenpiteet
- Webhotellin vaihto jaetusta hostauksesta Seravon Premium-tasolle (TTFB 750 ms → 180 ms)
- ShortPixel kaikille tuotekuville: WebP-konversio ja pakkaus (kuvien koko -65 %)
- Hero-kuvien preload etusivulla ja tärkeimmillä kategoriasivuilla
- Elementorin siivous: turhien widgettien poisto, globaalin CSS:n minimointi
- WP Rocket ”Delay JavaScript execution” aktivoitu kolmansien osapuolten skripteille
- Kriittinen CSS-polku: above-the-fold-CSS inline-muotoon, loput async
- Fonttien optimointi: Google Fonts omalle palvelimelle, vain 2 varianttia ladattuna
- Evästebanneri kiinteään asemointiin – ei enää layout shift -ongelmaa
Tulokset 4 viikon jälkeen
Liiketoimintavaikutus 3 kuukauden jälkeen: orgaaninen liikenne +32 % (4 200 → 5 544 kävijää kuukaudessa), konversioaste +18 % (0,95 % → 1,12 %), myynti +54 %. Kaikki kolme Core Web Vitals -mittaria saavuttivat ”Hyvä”-tason ja sivusto nousi 14 avainsanalla ylemmäs Googlessa. ROI oli positiivinen jo toisena kuukautena.
Jatkuva seuranta ja raportointi
Core Web Vitals ei ole kertaluonteinen projekti. Uudet lisäosat, teemapäivitykset, lisätty analytiikka tai muut muutokset voivat heikentää mittareita yllättäen.
Viikoittainen rutiini
- Avaa Google Search Console → Experience → Core Web Vitals
- Tarkista, onko uusia ”Poor”-merkintöjä
- Vertaa desktop- ja mobiilipisteitä erikseen
- Klikkaa ”Open Report” ja tarkista URL-ryhmien muutokset
Kuukausittainen syvätarkistus
- PageSpeed Insights -testi 5–10 tärkeimmälle sivulle (etusivu, tuotekategoriat, top-artikkelit)
- Mobiili ja desktop erikseen
- Tallenna tulokset – näet pitkän aikavälin trendin
- Vertaa GA4-dataan: näkyykö yhteys Core Web Vitals -parannusten ja konversioiden välillä
Muutosten jälkeiset testit
Aina kun teet merkittäviä muutoksia sivustoon, testaa Core Web Vitals välittömästi: uusi lisäosa asennettu, teema päivitetty, uusi sivunrakentajan versio, uusi analytiikkatyökalu tai chat-widgetti, sivuston ulkoasuuudistus tai uuden tuotesivun tai artikkelin julkaisu.
Usein kysyttyä
Mitä Core Web Vitals tarkoittaa vuonna 2026?
Miksi FID poistui ja INP tuli tilalle?
Vaikuttaako Core Web Vitals Googlen sijoituksiin?
Mikä on 75. persentiili Core Web Vitals -mittauksessa?
Mistä mittaan Core Web Vitals -pisteeni?
Mikä on kenttädata vs. lab-data Core Web Vitals -mittauksissa?
Kuinka kauan Core Web Vitals -korjaukset näkyvät Google Search Consolessa?
Mikä on yleisin syy huonoon LCP-pisteeseen?
Mikä on yleisin syy huonoon INP-pisteeseen?
Mikä on yleisin syy huonoon CLS-pisteeseen?
Riittääkö WP Rocket ratkaisemaan Core Web Vitals -ongelmat?
Voiko Core Web Vitals parantua ilman kehittäjää?
Mitkä ovat Core Web Vitals -mittareiden hyvät raja-arvot vuonna 2026?
Milloin kannattaa palkata kehittäjä Core Web Vitals -korjauksiin?
Kuinka usein Core Web Vitals kannattaa tarkistaa?
Lähteet
- Google Search Central – Core Web Vitals (developers.google.com/search/docs/appearance/core-web-vitals)
- web.dev – Web Vitals (web.dev/articles/vitals)
- Google Chrome User Experience Report (CrUX)
- Google PageSpeed Insights (pagespeed.web.dev)
- Google Search Console – Core Web Vitals Report
- SEOvelho – Asiakasreferenssit ja Core Web Vitals -data
Ovatko sivustosi Core Web Vitals -mittarit kunnossa?
Tilaa maksuton Core Web Vitals -arviointi. Käyn läpi sivustosi LCP-, INP- ja CLS-pisteet sekä konkreettiset korjausehdotukset. Ei sitoumuksia.
Vastaus 24 tunnissa. Ei sitoumuksia.
