Core Web Vitals 2026 – LCP, INP ja CLS -opas suomeksi
Core Web Vitals ratkaisee, nouseeko sivustosi kärkisijoille vai jääkö toiselle sivulle – 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 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), CLS alle 0,1 (vakaus). Kaikki vaikuttavat Googlen sijoituksiin. FID korvautui INP:llä 3/2024. Arvioidaan 75. persentiilin mukaan aidosta Chrome-käyttäjädatasta. Yleisin LCP-ongelma on raskaat kuvat, INP-ongelma kolmannen osapuolen JavaScript, CLS-ongelma puuttuvat kuvamitat. Tavallinen WP-sivun korjaus maksaa 500–3 000 € kertaluonteisena.
Mitä Core Web Vitals on ja miksi se ratkaisee
Core Web Vitals (Googlen suomenkielisessä dokumentaatiossa ”Verkon Vitals-perustiedot”) on Googlen virallinen mittaristo, jolla arvioidaan verkkosivun käyttäjäkokemuksen teknistä laatua. Mittaristo otettiin käyttöön Googlen rankingsignaalina 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ö layout paikallaan vai hyppääkö sisältö latauksen aikana (CLS)
Google virallisen Core Web Vitals -dokumentaationsa mukaan mittaristo on erottamaton osa page experience -signaalia. Tämä tarkoittaa käytännössä, että jos kaksi sivua kilpailee samasta sijoituksesta yhtä hyvällä sisällöllä, Core Web Vitals ratkaisee voittajan.
Core Web Vitals vs. yleinen ”sivuston nopeus”
Monet sekoittavat Core Web Vitalsin yleiseen PageSpeed Insights -pisteisiin (0–100). Ne eivät ole sama asia. PageSpeed Insights -pisteet ovat kokoelma 40+ eri mittaria, ja vain 3 niistä kuuluu Core Web Vitalsiin. Vain Core Web Vitals vaikuttaa Googlen sijoituksiin – muut PageSpeed-mittarit ovat diagnostisia, eivät 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ä” kokemus, jotta sivu läpäisee testin. Tämä ei ole keskiarvo, eikä mediaani – se on neljänneksen raja-arvo.
Miksi tämä on tärkeää? Esimerkki: sivusto saa LCP:n 1,8 s nopealla kuituyhteydellä desktopilla, 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 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 Vitalsista 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. 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 – odota 800 ms. Täytät kentän – selain lagaa. 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 pisimmän 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
- Filterit ja valikot – jokainen valinta aiheuttaa JS-rerender
- Checkout ja maksusivut – monta vaihetta raskailla kolmansilla osapuolilla
- Interaktiiviset karusellit, tabit ja dropdownit
- 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 voi mitata usealla tavalla, mutta ammattilaisen kannattaa tietää neljän työkalun erot. Kaikki ovat ilmaisia ja Googlen virallisia tai vahvasti tukema.
Google PageSpeed Insights (pagespeed.web.dev)
Paras pikadiagnoosiin yksittäisille sivuille. 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 monitorointiin. 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 ~500 näyttökertaa kuukaudessa jotta dataa on 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. Ammattilaisen on-page-työkalu numero yksi.
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 koodirivin 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 toisella on väliä Googlen silmissä.
| Ominaisuus | Kenttädata | Lab-data |
|---|---|---|
| Mistä tulee | Aidot Chrome-käyttäjät, 28 pv 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ä (~500+ käyntiä/kk) | Ei |
| Päivittyy | 28 pv viiveellä | Heti |
| Käytä kun | Todellinen vaikutus sijoituksiin | Kehitys ja debug |
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
- Verifoi parannus 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 viewportin suurin sisältöelementti (yleensä hero-kuva, videopreview 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 viewportissa näkyviä elementtejä ja valitsee suurimman. Tyypilliset LCP-elementit: hero-kuva (yleisin LCP WordPress-sivuilla), suuri tekstilohko (esim. H1 + leipäteksti), videon ensimmäinen frame 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ä jaettu hostaus kilpailluilla sivustoilla), CDN (Cloudflare ilmainen taso usein riittää), server-side-välimuisti, tietokantaoptimointi.
Optimoimattomat hero-kuvat
Yleisin LCP-ongelma WordPress-sivuilla. Pakkaamaton JPEG 2 MB ei koskaan läpäise LCP:tä mobiilissa. Korjaus: WebP- tai AVIF-formaatti (50–70 % pienempi), oikeat responsiiviset koot srcset-attribuutilla, lazy loading paitsi hero-kuvalle, <link rel="preload"> hero-kuvalle.
Render-blocking CSS ja JavaScript
Jos head-elementissä on iso CSS-tiedosto tai synkroninen JS-skripti, selain ei voi renderoida mitään ennen niiden latausta. Korjaus: kriittinen CSS inline, loput async tai defer -atribuutilla. Poista käyttämätön CSS.
Client-side rendering ilman SSR:ää
Jos sivu renderoidaan vasta JavaScriptillä selaimessa (esim. React SPA ilman SSR:ää), LCP odottaa JS-latausta ja suoritusta. Korjaus: Server-Side Rendering (Next.js SSR, Nuxt) tai Static Site Generation tuottaa valmiin HTML:n palvelimella.
Konkreettinen koodi-esimerkki: hero-kuvan preload
Yksi nopein LCP-parannus 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 main thread 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 event handlerin 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), A/B-testaustyökalut (Hotjar). Nämä kaikki suorittavat JS:ää pääsäikeessä, blokaten käyttäjän vuorovaikutukset. Korjaus: lataa ne asynkronisesti, käytä viivästystä kunnes sivu on valmis, harkitse serverside-integraatioita.
Raskaat WordPress-sivunrakentajat
Elementor, Divi, WPBakery, Visual Composer – kaikki tuottavat valtavia määriä JavaScriptia 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 blokaavat main threadin. Erityisesti sivuston latauksen alussa tehtävät raskaat alustukset (analytiikka, mainokset, hydration) aiheuttavat INP-ongelmia. Korjaus: tehtävien paloittelu (scheduler.yield API), web workersit raskaalle laskennalle, 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. Ei tarvitse muistaa kaavaa – riittää tietää, että mitä suurempi liikkuva elementti ja mitä pidempi matka 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ä miten paljon tilaa varata, ja muut elementit hyppäävät kuvan latautuessa. Korjaus: aina lisää width ja height -attribuutit img-tägiin. WordPressissä Media Library tekee tämän automaattisesti, mutta kustomissa teemoissa tarkista 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 (reserved space) 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ä + 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 fixed-positionilla (absoluuttinen), niin se ei vaikuta layoutiin. Tai sumenna sisältö taustalla kunnes banneri suljetaan.
Iframe-upotukset ilman mittoja
YouTube-videot, kartat, somepostaukset upotettuina iframella. Jos niillä ei ole width/height -atribuutteja, selain varaa tilan myöhässä. Korjaus: aspect-ratio CSS + kiinteät mitat iframelle.
WordPress-spesifit Core Web Vitals -korjaukset
Yli 60 % Suomen yritysten verkkosivuista käyttää WordPressia. Tässä on todellinen optimointijärjestys – ei ”asenna WP Rocket ja valmis”, vaan rehellinen näkymä siitä mitä pitää tehdä.
Vaihe 1 – Webhotelli ja TTFB (ensimmäinen priorisointi)
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, WPEngine, 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) + selainpuoli (browser cache). Paras työkalu: palvelintarjoajan oma välimuisti (Seravolla valmiina), tai WP Rocket + LiteSpeed Cache. Vältä monia päällekkäisiä välimuistituksia – ne konfliktoivat.
Vaihe 3 – Kuvien optimointi
Asenna ShortPixel tai Imagify – konvertoi automaattisesti WebP/AVIF-formaattiin ja luo 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 (WP:n natiivi) – kevyin, nopein, mutta vaatii tottumista
- Bricks Builder – nopea Core Web Vitals -kannalta, visual builder
- GeneratePress + GenerateBlocks – erittäin kevyt kombinaatio
- 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, scrollaa). 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
Hostaa custom-fontit itse (älä linkkaa Google Fontseja CDN:stä). 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, riippuen sivuston koosta ja sivunrakentajasta. 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 mahdollinen | Kehittäjä suositeltu |
|---|---|---|
| Kuvien optimointi (WebP, kompressointi) | ✅ Plugin riittää | |
| Caching-pluginin asennus | ✅ | |
| Image width/height -attribuutit | ✅ (WP tekee auto) | |
| Evästebannerin fixed-position | ✅ CSS-rivi | |
| Kolmannen osapuolen skriptien priorisointi | ✅ Vaatii teknistä ymmärrystä | |
| Sivunrakentajan vaihto | ✅ Iso projekti | |
| Kustomi koodimuutokset (defer, async) | ✅ | |
| Server-side rendering / SSR-migraatio | ✅ Kehittäjäprojekti | |
| Hero-kuvan preload + fetchpriority | ✅ Teema-editointi | |
| Webhotellin vaihto | ✅ DIY mahdollinen | Tai partneri joka tekee migraation |
Palkkaa kehittäjä erityisesti kun:
- INP on heikko (yli 500 ms) – juurisyyt ovat lähes aina JS-koodissa
- LCP yli 4 s eikä parane kuvaoptimoinnilla ja cachingilla
- Sivusto on kustomi koodilla (ei valmisalustalla)
- Käytät Elementoria tai Diviä ja INP ei parane pluginien avulla
- Sivusto on verkkokauppa isolla katalogilla
Asiakascase: LCP 3,2 s → 1,6 s, sijoitukset +32 %
Lähtötilanne: Suomalainen verkkokauppa. WordPress + WooCommerce + Elementor Pro. Kuukausittainen orgaaninen liikenne 4 200 kävijää. LCP mobiilissa 3,2 s (Heikko), INP 580 ms (Heikko), CLS 0,18 (Parannusta).
Tehdyt toimenpiteet
- Webhotellin vaihto jaetusta hostauksesta Seravon Premium-tasolle (TTFB 750 ms → 180 ms)
- ShortPixel kaikille tuotekuville WebP-konversio + kompressointi (kuvien koko -65 %)
- Hero-kuvien preload etusivulla ja tärkeimmillä kategoriasivuilla
- Elementorin siivous: turhien widgettien poisto, Global CSS -minimointi
- WP Rocket ”Delay JavaScript execution” aktivoitu kolmansien osapuolten skripteille
- CSS critical path: above-the-fold CSS inlineksi, loput async
- Fonttien optimointi: Google Fonts itse-hostatuksi, vain 2 varianttia ladattuna
- Evästebanneri fixed-positioniin – ei enää layout shiftiä
Tulokset 4 viikon jälkeen
Liiketoimintavaikutus 3 kuukauden jälkeen: orgaaninen liikenne +32 % (4 200 → 5 544 kävijää/kk), konversioaste +18 % (0,95 % → 1,12 %), myynti +54 %. Kaikki kolme Core Web Vitals -mittaria saavutti ”Hyvä”-tason ja sivusto nousi 14 avainsanalla ylemmäs Googlessa. ROI positiivinen jo toisena kuukautena.
Jatkuva seuranta ja raportointi
Core Web Vitals ei ole kertaluonteinen projekti. Uudet pluginit, teemapäivitykset, lisätty analytiikka tai muut muutokset voivat heikentää mittareita yllättäen.
Viikoittainen rutiini
- Avaa Google Search Console → Experience → Core Web Vitals
- Tarkasta onko uusia ”Poor”-merkintöjä
- Vertaa desktop- ja mobile-pisteitä 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)
- Mobile ja desktop erikseen
- Tallenna tulokset – näet pitkän aikavälin trendin
- Vertaa GA4-dataan: näkyykö yhteys CWV-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 plugin asennettu, teema päivitetty, uusi sivunrakentaja-versio, uusi analytiikkatyökalu tai chat-widget, sivuston designin uudistus, uuden tuotesivun tai artikkelin julkaisu.
Usein kysyttyä
Mitä Core Web Vitals tarkoittaa 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 -hyvät raja-arvot 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 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.
