Core Web Vitals 2026: mitä INP mittaa ja miksi WordPress-sivut kaatuvat siihen

INP on se Core Web Vitals -mittari, jonka takia moni suomalainen WordPress-sivusto näyttää Search Consolessa punaista. Se ei mittaa latausnopeutta vaan sitä, kuinka nopeasti sivu vastaa, kun käyttäjä tekee jotain. Tässä käydään läpi, mitä se tarkalleen mittaa, mistä huono tulos yleensä johtuu, miten se mitataan oikein ja mitä tämä sivusto tekee toisin.

INP mittaa aikaa klikkauksesta seuraavaan piirrettyyn ruutuun

web.dev-dokumentaation mukaan Interaction to Next Paint arvioi sivun kokonaisvastaavuutta tarkkailemalla kaikkien klikkausten, napautusten ja näppäinpainallusten viivettä sivun koko elinkaaren ajan. Aika lasketaan siitä, kun käyttäjä aloittaa vuorovaikutuksen, siihen, kun selain pystyy seuraavan kerran piirtämään ruudun. Vieritys, hiiren liikuttaminen ja zoomaus eivät ole vuorovaikutuksia tässä mielessä.

Kynnykset ovat selvät: hyvä on enintään 200 millisekuntia, parannettavaa 200–500 millisekuntia ja huono yli 500 millisekuntia. Arvo lasketaan 75. persentiilillä, eli neljäsosa käyttäjistä saa kokea tätä huonompaa ja sivu on silti hyvä.

Jokainen vuorovaikutus jakautuu kolmeen vaiheeseen. Syöteviive (input delay) on aika ennen kuin tapahtumankäsittelijä pääsee edes alkamaan, tyypillisesti siksi, että pääsäie on kiinni jossain muussa. Käsittelyaika (processing duration) on aika, jonka kaikki tapahtumankäsittelijät vievät. Esitysviive (presentation delay) on aika siitä, kun käsittelijät ovat valmiit, siihen, kun selain on laskenut layoutin, maalannut ja näyttänyt ruudun. Huono INP voi syntyä missä tahansa näistä, ja korjaus riippuu siitä, missä.

INP korvasi aiemman First Input Delay -mittarin 12.3.2024. FID mittasi vain ensimmäisen vuorovaikutuksen syöteviiveen. INP mittaa kaikki vuorovaikutukset kaikkine vaiheineen, ja siksi moni sivu, joka läpäisi FID:n, ei läpäise INP:tä. Muut kaksi Core Web Vitalia ovat web.devin mukaan edelleen LCP (suurin sisältöelementti näkyvissä 2,5 sekunnissa) ja CLS (asettelun siirtymä enintään 0,1).

WordPress-sivustoista alle puolet läpäisee Core Web Vitalsit

HTTP Archiven Web Almanac 2025:n CMS-luvun mukaan WordPress pyörittää 64,3 prosenttia kaikista CMS-pohjaisista sivustoista mobiilissa. Samasta luvusta: 45 prosenttia WordPress-sivustoista saavutti hyvän Core Web Vitals -tuloksen vuonna 2025, neljä prosenttiyksikköä enemmän kuin vuotta aiemmin. Vertailun vuoksi Almanacin suorituskykyluvun mukaan kaikista sivustoista 48 prosenttia läpäisi mobiilissa ja 56 prosenttia työpöydällä (data heinäkuulta 2025).

Pelkkä INP näyttää paremmalta kuin kokonaisuus. Almanacin mukaan mobiilissa 77 prosenttia sivuista sai hyvän INP:n ja työpöydällä 97 prosenttia. Ero kertoo olennaisen: INP on mobiiliongelma, koska puhelimen prosessori on hitaampi ja sama JavaScript vie siinä moninkertaisen ajan. WordPress-kohtaista INP-prosenttia Almanac ei anna. Search Engine Journalin raportti HTTP Archiven Tech Report -datasta kertoo, että kesäkuussa 2025 85,89 prosenttia WordPress-sivustoista sai hyvän INP:n ja vain 43,44 prosenttia hyvän kokonaistuloksen, viimeisenä kuudesta vertaillusta alustasta. Luku on toissijaisesta lähteestä, koska Tech Report -sovellus ei avautunut ilman selainta.

Almanacin CMS-luku nimeää yhden syyn suoraan: page builderit tuottavat monimutkaisempia DOM-rakenteita ja suurempia CSS- ja JavaScript-paketteja, mikä nostaa suorituskykyriskiä laajassa mittakaavassa. Elementor on käytössä 43 prosentilla WordPress-sivustoista. Almanac ei kuitenkaan erottele builder-sivustojen ja muiden WordPress-sivustojen INP-arvoja, joten suoraa lukua sille, paljonko builder maksaa millisekunteina, ei ole.

Syyt ovat pääsäikeessä: skriptit, suuri DOM ja JavaScriptillä piirretty HTML

web.devin optimointiohje kuvaa mekanismit. Syöteviive kasvaa, kun pääsäie on kiinni skriptien lataamisessa, jäsentämisessä ja kääntämisessä: selain joutuu tarkistamaan syntaksin, kääntämään tavukoodiksi ja suorittamaan, ennen kuin klikkaus pääsee käsittelyyn. Käsittelyaika kasvaa, kun koodi lukee ja kirjoittaa tyylejä samassa tehtävässä (layout thrashing), jolloin selain joutuu laskemaan layoutin synkronisesti kesken kaiken. Esitysviive kasvaa, kun DOM on suuri, koska renderöintityö skaalautuu DOM:n koon mukaan, ja kun HTML piirretään JavaScriptillä, koska selain ei luovuta vuoroa ennen kuin se on jäsentänyt ja renderöinyt kaiken.

Tästä seuraa, miksi tyypillinen WordPress-sivu jää kiinni. Page builder tuottaa syvän DOM:n, jossa yhtä painiketta ympäröi kymmenen sisäkkäistä diviä. Jokainen lisäosa tuo oman JavaScript-tiedostonsa, joka jäsennetään ja suoritetaan riippumatta siitä, tarvitaanko sitä sivulla. Ja päälle tulevat kolmannen osapuolen skriptit: Almanacin kolmansien osapuolten luvun mukaan noin 90 prosenttia sivuista lataa ainakin yhden kolmannen osapuolen resurssin, mediaani mobiilissa on 79 pyyntöä sivua kohden kaikilla sivustoilla, ja skriptit ovat yleisin kolmannen osapuolen pyyntötyyppi (24,8 prosenttia). Analytiikka, chat-widget, evästebanneri, mainospikselit ja upotettu video jakavat saman pääsäikeen kuin käyttäjän klikkaus.

Suoraa tilastoa siitä, kuinka suuri osa huonoista INP-arvoista johtuu juuri kolmannen osapuolen skripteistä, en löytänyt. Mekanismi on dokumentoitu; osuus ei.

Fontit ovat oma lukunsa. Almanacin mukaan 87 prosenttia mobiilisivuista käyttää ainakin yhtä web-fonttia. web.devin fonttiohjeen mukaan fontit vaikuttavat ennen kaikkea LCP:hen ja CLS:ään: väärä font-display-arvo joko viivyttää tekstin näkymistä tai aiheuttaa hyppäyksen, kun fontti vaihtuu. Ohje suosittelee WOFF2-muotoa, fonttien osajoukkoja (subsetting) ja size-adjust-ominaisuutta, jolla varafontin mitat sovitetaan oikeaan fonttiin. INP:hen fontit vaikuttavat vain epäsuorasti, jos fonttien lataus ja vaihto osuu samaan aikaan klikkauksen kanssa. Kun sivusto epäonnistuu kaikissa kolmessa mittarissa, fontit ovat usein CLS:n ja LCP:n syy, eivät INP:n.

Mittaa oikeiden käyttäjien datasta, älä laboratoriosta

Core Web Vitals -tulos, jota Google käyttää, on kenttädataa. Se tulee Chrome User Experience Reportista (CrUX), johon kertyy dataa Chrome-käyttäjiltä, jotka ovat sallineet käyttötilastojen jakamisen ja synkronoivat selaushistoriansa. Mukana ovat työpöytä-Chrome ja Android-Chrome, eivät iOS-Chrome eivätkä muut Chromium-selaimet. Data kootaan sekä koko sivuston (origin) että yksittäisen URL:n tasolla, ja sivun pitää olla julkisesti löydettävissä ja riittävän suosittu, jotta dataa ylipäätään näytetään. Tarkkaa kävijärajaa Google ei kerro.

Search Consolen Core Web Vitals -raportti näyttää saman CrUX-datan URL-ryhmittäin: hyvä, parannettavaa, huono. Ryhmän tila on sen huonoimman mittarin tila. Kun korjaus on tehty, raportissa voi käynnistää 28 päivän validoinnin. Jos raportti sanoo “ei dataa”, sivusto on joko uusi tai liian pieni CrUX:lle, ja silloin ainoa vaihtoehto on PageSpeed Insightsin tai Lighthousen laboratoriomittaus. Laboratoriomittaus ei kuitenkaan mittaa INP:tä samalla tavalla, koska siinä ei ole oikeaa käyttäjää klikkaamassa.

Tämä koskee myös mainostoimisto.ai-sivustoa: se julkaistiin 22.9.2026, joten CrUX-dataa ei ole. Kun sitä kertyy, tulokset julkaistaan täällä, myös jos ne ovat huonoja.

Toinen rehellinen huomautus. Googlen sivukokemusdokumentaatio sanoo, että ydinjärjestelmät pyrkivät palkitsemaan hyvän sivukokemuksen, mutta myös, että Google-haku näyttää aina relevanteimman sisällön, vaikka sivukokemus olisi heikko, eikä mikään yksittäinen signaali ratkaise. INP ei siis ole sijoitustekijä siinä mielessä, että sen korjaaminen nostaisi sivun. Se on käyttäjätekijä: sivu, joka ei reagoi napautukseen puoleen sekuntiin, menettää kävijän, ja se näkyy lopulta kaikessa muussa.

Mitä tämä sivusto tekee toisin

mainostoimisto.ai on rakennettu niin, että INP-ongelmaa ei pääse syntymään. Ratkaisut ovat samoja, joita web.dev suosittelee, ei mitään keksittyä.

HTML tulee valmiina palvelimelta. Sivusto on Astro-staattinen, joten selain saa valmiin HTML:n eikä sen tarvitse rakentaa sivua JavaScriptillä. Tämä poistaa web.devin kuvaaman esitysviiveen suurimman lähteen.

Animaatiot koskevat vain transform- ja opacity-ominaisuuksia. web.devin animaatio-ohjeen mukaan nämä kaksi ominaisuutta hoidetaan komposiittivaiheessa ilman layoutia tai maalausta, ja kaikkia muita animoitavia ominaisuuksia pitää välttää, ellei ole pakko. Sivuston kolme ulkoasua (kineettinen typografia, WebGL ja lähtöaulan taulu) liikkuvat paljon, mutta liike ei pysäytä pääsäiettä, koska se ei koske layoutia.

WebGL ajetaan vain, kun se on näkyvissä. B-ulkoasun WebGL-tausta käynnistyy vasta, kun elementti tulee näyttöön, ja pysähtyy, kun se poistuu. Näkymätön canvas ei syö prosessoria eikä kilpaile klikkauksen kanssa.

Kolmannen osapuolen skriptejä vältetään sääntönä. Ei chat-widgetiä eikä mainospikseliä, ja bottien käynnit lasketaan Cloudflaren lokista, ei selaimessa ajettavasta skriptistä. Fonteissa noudatetaan web.devin ohjetta: WOFF2 ja font-display-arvo, joka ei jätä tekstiä näkymättömäksi.

Tämä ei ole ylpeilyä vaan koeasetelma. Väite on, että staattinen sivusto ilman kolmannen osapuolen skriptejä läpäisee INP:n ilman erillistä optimointia. Kun CrUX-dataa on, väite joko pitää tai ei pidä. Siihen asti tämä on hypoteesi, ja se sanotaan ääneen. Vertailu WordPressiin jatkuu artikkelissa Staattinen sivusto vai WordPress, ja koko teknisen SEO:n kuva on pilarissa Tekninen SEO tekoälyaikana.

Mitä WordPress-sivuston omistaja voi tehdä huomenna

Avaa PageSpeed Insights ja katso, onko kenttädataa. Jos INP on punaisella, katso ensin lisäosien määrä ja se, montako niistä lataa JavaScriptiä joka sivulle. Sen jälkeen kolmannen osapuolen skriptit: jokainen chat, pikseli ja upotus, jota kukaan ei käytä, pois. Jos sivusto on rakennettu page builderilla, DOM:n koon pienentäminen on yleensä työläin mutta vaikuttavin korjaus, ja joskus halvempi tie on rakentaa teema uudelleen ilman builderia. Sitä ennen kannattaa lukea, mitä Google sanoo alustan valinnasta, koska vastaus ei ole se, mitä toimistot yleensä sanovat.

Kysymyksiä, joita tästä haetaan

Mikä on hyvä INP-arvo?

Enintään 200 millisekuntia 75. persentiilillä sivun latauksista. 200–500 ms on parannettavaa, yli 500 ms on huono. Rajat ovat web.dev-dokumentaatiosta.

Vaikuttaako huono INP Google-sijoitukseen?

Sivukokemus on osa Googlen ydinjärjestelmiä, mutta Google sanoo itse näyttävänsä relevanteimman sisällön, vaikka sivukokemus olisi heikko. INP ratkaisee harvoin sijoituksen yksin; se ratkaisee, jäävätkö kävijät sivulle.

Miksi PageSpeed Insights ei näytä INP-arvoa sivulleni?

Kenttädata tulee CrUX-tietokannasta, joka vaatii riittävästi Chrome-käyttäjien käyntejä. Pienellä tai uudella sivustolla dataa ei ole. Silloin voi käyttää Lighthousen laboratoriomittausta, joka ei kuitenkaan mittaa INP:tä samalla tavalla.

Lähteet

1. web.dev: Interaction to Next Paint (INP)Määritelmä, kynnykset 200/500 ms, 75. persentiili, kolme vaihetta, mitkä vuorovaikutukset lasketaan
2. web.dev: Web VitalsKolme Core Web Vitalia (LCP 2,5 s, INP 200 ms, CLS 0,1) ja mittaustyökalut
3. web.dev: INP replaces FID as a Core Web VitalINP korvasi FID:n 12.3.2024
4. web.dev: Optimize Interaction to Next PaintSyyt: skriptien jäsennys ja suoritus, pitkät tehtävät, layout thrashing, suuri DOM, HTML:n renderöinti JavaScriptillä
5. Chrome for Developers: CrUX methodologyKeitä data koskee (Chrome-käyttäjät, jotka ovat sallineet jakamisen), origin- ja URL-taso, riittävän suosion vaatimus
6. Search Console Help: Core Web Vitals reportRaportin data on CrUX-kenttädataa; URL-ryhmät; 28 päivän validointi; ei dataa -tilanne
7. HTTP Archive Web Almanac 2025: CMSWordPress 64,3 % CMS-sivustoista; 45 % WordPress-sivustoista hyvä CWV; page builderit ja DOM; Elementor 43 %
8. HTTP Archive Web Almanac 2025: PerformanceMobiilissa 48 % hyvä CWV, 77 % hyvä INP; työpöydällä 97 % hyvä INP; 87 % mobiilisivuista käyttää web-fonttia (heinäkuu 2025)
9. HTTP Archive Web Almanac 2025: Third PartiesNoin 90 % sivuista käyttää kolmannen osapuolen resursseja; skriptit 24,8 % kolmannen osapuolen pyynnöistä
10. Search Engine Journal: 2025 Core Web Vitals Challenge: WordPress Versus EveryoneToissijainen lähde HTTP Archiven Tech Report -luvuille: WordPress 85,89 % hyvä INP, 43,44 % hyvä CWV (kesäkuu 2025)
11. web.dev: Best practices for fontsWOFF2, font-display, size-adjust; fontit vaikuttavat LCP:hen ja CLS:ään
12. web.dev: How to create high-performance CSS animationsAnimoi transform ja opacity, vältä layoutia tai maalausta laukaisevia ominaisuuksia
13. Google Search Central: Understanding page experience in Google Search resultsGoogle näyttää relevanteimman sisällön, vaikka sivukokemus olisi heikko; ei yhtä signaalia

Löysitkö virheen?

Tämän tekstin kirjoitti kone ja toinen kone tarkisti faktat. Ihminen ei ole lukenut jokaista tekstiä. Jos jokin on väärin, kerro — ilmoitus menee Ilkka Immoselle, korjaus tehdään ja se merkitään tähän tekstiin näkyviin.

Mikä on väärinSähköposti, jos haluat kuulla korjauksesta

Lähetä ilmoitus