Core Web Vitals verkkokaupassa: LCP, INP ja CLS selitettynä

Mitä LCP, INP ja CLS mittaavat, hyvän ja heikon rajat 75. persentiilissä, laboratorio- ja kenttädata sekä korjaukset Shopifyssa ja WooCommercessa.

FixReportsin toimitusLukuaika 10 min

Core Web Vitals ovat kolme Googlen mittaria, jotka kuvaavat, miten todelliset kävijät kokevat sivun: Largest Contentful Paint (LCP) mittaa latautumista, Interaction to Next Paint (INP) reagointia ja Cumulative Layout Shift (CLS) visuaalista vakautta. Sivu läpäisee arvioinnin, kun vähintään 75 % käynneistä osuu ”hyvä”-alueelle: LCP enintään 2,5 sekuntia, INP enintään 200 millisekuntia ja CLS enintään 0,1, mitattuna erikseen mobiililaitteille ja tietokoneille. Verkkokaupoissa heikot tulokset johtuvat yleensä suurista tai laiskasti ladatuista hero- ja tuotekuvista, sovellus- ja seurantaskripteistä, verkkofonteista sekä bannereista tai arvostelu-widgeteistä, jotka työntävät sisältöä alaspäin sen jälkeen, kun sivu on jo näkynyt.

Tärkeimmät kohdat

Mitkä ovat Core Web Vitals -raja-arvot?

Sivu täyttää Core Web Vitals -vaatimukset, kun sen sivulatausten 75. persentiili osuu kaikissa kolmessa mittarissa hyvälle alueelle.

MittariMitä se mittaaHyväKaipaa parannustaHeikko
LCPAika, kunnes näkymän suurin kuva, video tai tekstilohko on piirrettyEnintään 2,5 sYli 2,5 s ja enintään 4,0 sYli 4,0 s
INPAika napsautuksesta, napautuksesta tai näppäinpainalluksesta seuraavan kuvan piirtämiseenEnintään 200 msYli 200 ms ja enintään 500 msYli 500 ms
CLSKuinka paljon näkyvä sisältö siirtyy odottamattaEnintään 0,1Yli 0,1 ja enintään 0,25Yli 0,25

Raja-arvot ovat web.devin LCP (avautuu uuteen välilehteen)-, INP (avautuu uuteen välilehteen)- ja CLS (avautuu uuteen välilehteen)-oppaista lokakuun 2026 tilanteen mukaan.

Kun tulos lasketaan 75. persentiilistä, se kuvaa useimpia kävijöitä eikä vain nopeimpia, ja Google erottelee mobiilin ja tietokoneen (avautuu uuteen välilehteen). PageSpeed Insights hyväksyy sivun, kun kaikki kolme mittaria ovat hyviä; jos INP-dataa ei ole tarpeeksi, se arvioi pelkät LCP:n ja CLS:n (PageSpeed Insightsin dokumentaatio (avautuu uuteen välilehteen)). Googlen mukaan vakaat Core Web Vitals -mittarit muuttuvat enintään kerran vuodessa.

Verkkokaupassa LCP-elementti on usein hero-banneri tai päätuotekuva, minkä vuoksi kuvien käsittelyllä on niin suuri merkitys.

Miksi INP korvasi FID:n maaliskuussa 2024?

INP korvasi FID:n, koska FID mittasi vain ensimmäistä vuorovaikutusta ja vain osaa sen viiveestä, kun taas INP tarkastelee vuorovaikutuksia koko käynnin ajalta.

Google ilmoitti toukokuussa 2023, että INP:stä tulee Core Web Vitals -mittari, ja muutos tuli voimaan 12. maaliskuuta 2024 (avautuu uuteen välilehteen). FID raportoi vain ensimmäisen vuorovaikutuksen ja siitäkin vain syöttöviiveen, ei tapahtumankäsittelijöiden suorittamiseen tai tuloksen piirtämiseen kulunutta aikaa. INP seuraa napsautuksia, napautuksia ja näppäinpainalluksia koko käynnin ajan ja raportoi niistä pisimmän poikkeamat pois lukien; vierittäminen ja osoittimen vieminen elementin päälle eivät ole mukana. CrUX- ja PageSpeed Insights -rajapintojen käyttäjillä oli aikaa siirtyä 9. syyskuuta 2024 asti (web.dev (avautuu uuteen välilehteen)).

Jokaisessa vuorovaikutuksessa on kolme osaa: syöttöviive (odotetaan kiireisiä skriptejä), käsittelyaika (käsittelijät suoritetaan) ja esitysviive (seuraava kuva piirretään) (web.dev (avautuu uuteen välilehteen)).

Verkkokaupassa näitä vuorovaikutuksia ovat varianttivalitsin, määräpainikkeet, ostoskoriin lisääminen, ostoskorin sivupaneeli, suodattimet ja valikot. Sivu saattoi läpäistä FID:n nopean ensimmäisen napautuksen ansiosta mutta tuntua silti hitaalta, kun joku avasi suodattimet myöhemmin.

Mitä eroa on laboratoriodatalla ja kenttädatalla?

Laboratoriodata tulee yhdestä testistä vakioiduissa olosuhteissa, kun taas kenttädata kerätään todellisilta kävijöiltä ajan mittaan, ja Google suosittelee käyttämään kenttädataa, kun päätetään, mitä korjataan ensin (web.dev (avautuu uuteen välilehteen)).

LaboratoriodataKenttädata
LähdeYksi simuloitu sivulataus (Lighthouse, Chrome DevTools, PageSpeed Insightsin laboratorio-osio)Todelliset Chrome-kävijät (Chrome UX Report) tai oma todellisten käyttäjien seuranta (RUM)
OlosuhteetVakioitu laite ja verkko. Lighthousen oletusarvoinen mobiilitesti (avautuu uuteen välilehteen) käyttää ”Slow 4G” -profiilia (150 ms:n edestakainen viive, 1,6 Mbit/s latausnopeus) ja 4-kertaista suorittimen hidastustaMitä tahansa laitteita, verkkoja ja sijainteja kävijöilläsi on
INPEi mitata pelkässä sivulatauksessa. Total Blocking Time (TBT) on karkea korvikeMitataan todellisista vuorovaikutuksista
Sopii parhaitenVianetsintään ja muutoksen tarkistamiseen ennen julkaisuaSen selvittämiseen, mitä kävijät todella kokevat

TBT laskee yhteen jokaisen pääsäikeen tehtävän 50 ms:n ylittävän osan; web.dev suosittaa keskitason mobiililaitteilla alle 200 ms:n arvoa mutta toteaa, ettei TBT korvaa INP:tä (web.dev (avautuu uuteen välilehteen)).

Chrome UX Reportissa (CrUX) on kolme verkkokaupoille tärkeää yksityiskohtaa:

  • Se on liukuva 28 päivän keskiarvo (avautuu uuteen välilehteen), joka päivitetään päivittäin.
  • Se kattaa tietokoneiden ja Androidin Chromen käyttäjät, jotka täyttävät Chromen raportointiehdot. iOS:n Chrome ei ole mukana, joten kauppa, jonka asiakkaat käyttävät enimmäkseen iPhonea, näkee kenttädataa vain osasta yleisöään (menetelmä (avautuu uuteen välilehteen)).
  • Yksittäiset sivut ja koko sivusto (origin) näkyvät vain, jos ne ovat julkisesti löydettävissä ja riittävän suosittuja, joten vähäisen liikenteen kaupalla voi olla dataa vain koko sivuston tasolla tai ei lainkaan.

Shopifyn verkkosuorituskyvyn koontinäkymä (avautuu uuteen välilehteen) raportoi myös todellisten käyttäjien LCP-, INP- ja CLS-arvot 75. persentiilissä, mutta 30 päivän eikä 28 päivän ajalta, joten pieniä eroja CrUX-dataan on odotettavissa.

Mikä hidastaa LCP:tä kaupan sivuilla?

LCP on verkkokaupoissa yleensä hidas, koska pääkuva on liian raskas, löytyy myöhään tai sen latautumista viivästetään tarkoituksella laiskalla latauksella tai animaatiolla.

  • LCP-kuvan laiska lataus. web.devin mukaan näin ei pidä koskaan tehdä (web.dev (avautuu uuteen välilehteen)). Sen WordPress-sivuja koskevassa analyysissa natiivia laiskaa latausta (lazy loading) käyttävien sivustojen LCP oli 75. persentiilissä hitaampi, ja kun ensimmäisen näkymän kuvia ei enää ladattu laiskasti, heikentyminen poistui (web.dev (avautuu uuteen välilehteen)).
  • Myöhään löytyvä kuva. CSS:n background-image-taustakuvaksi asetettu tai kuvakarusellin skriptin lisäämä hero-kuva ei ole siinä HTML:ssä, jonka selain käy ensimmäisenä läpi. Shopify kehottaa välttämään CSS-taustoja hero-sisällössä ja häivytystehosteita LCP-kuvassa (Shopify (avautuu uuteen välilehteen)).
  • Matala prioriteetti. Kuvat latautuvat matalalla prioriteetilla, kunnes asettelu on valmis, joten Shopify suosittelee LCP-kuvaan fetchpriority="high"-määritettä (Shopify (avautuu uuteen välilehteen)). web.dev huomauttaa, että sen asettaminen useammalle kuin yhdelle tai kahdelle kuvalle heikentää sen hyötyä (web.dev (avautuu uuteen välilehteen)).
  • Renderöinnin estävät CSS ja skriptit. Suuret tyylitiedostot ja synkroniset skriptit <head>-osiossa viivästävät renderöintiä silloinkin, kun kuva on jo saapunut (web.dev (avautuu uuteen välilehteen)).
  • Tiedostokoko ja fontit. Käytä moderneja kuvamuotoja, srcset- ja sizes-määritteitä sekä CDN:ää. Käytä verkkofonteille muuta font-display-arvoa kuin auto tai block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Mikä tekee INP:stä hitaan kaupan sivuilla?

Hidas INP tarkoittaa verkkokaupoissa yleensä, että pääsäikeellä ajetaan liikaa JavaScriptiä, josta suuri osa tulee sovelluksista, seurantatageista ja teeman ominaisuuksista, joten napautukset joutuvat odottamaan.

Jos asiakas napauttaa ”Lisää ostoskoriin” -painiketta, kun arvostelu-, chat- ja analytiikkaskriptit ovat vielä käynnissä, napautus joutuu odottamaan. Varianttivalitsin, joka renderöi koko tuotelomakkeen uudelleen, pidentää käsittelyaikaa. Valtavat megavalikot ja kokoelmaruudukot, joissa on paljon värinäytteitä, lisäävät esitysviivettä.

web.dev suosittelee pitkien tehtävien pilkkomista ja pääsäikeen vapauttamista välillä (yielding), näytön päivittämistä ensin ja muun työn lykkäämistä sekä DOM:n pitämistä pienempänä (web.dev (avautuu uuteen välilehteen)). Shopify lisää kauppakohtaisia toimia: käy läpi jokainen sovellus, pikseli ja teeman skripti, lykkää kaikkea, mikä ei ole kriittistä, lataa ominaisuudet vasta vuorovaikutuksen yhteydessä ja poista A/B-testauksen välkkymisenestokoodit käytöstä, kun mitään testiä ei ole käynnissä (Shopify (avautuu uuteen välilehteen)).

Mikä aiheuttaa asettelun siirtymiä tuote- ja kokoelmasivuilla?

Verkkokauppojen asettelun siirtymät johtuvat useimmiten sisällöstä, joka ilmestyy tai muuttaa kokoaan ensimmäisen renderöinnin jälkeen: kuvista ilman mittoja, ilmoitus- ja evästepalkeista, arvostelu-widgeteistä, sovelluslohkoista ja fonttien vaihtumisesta.

web.dev luettelee yleisimmiksi syiksi mediat, joiden mittoja ei tiedetä, olemassa olevan sisällön yläpuolelle lisätyn sisällön, kolmansien osapuolten widgetit, jotka muuttavat kokoaan, sekä verkkofontit, joiden koko poikkeaa varafontista (web.dev (avautuu uuteen välilehteen)). Verkkokaupoissa tämä tarkoittaa sivun yläreunaan lisättyä ilmaisen toimituksen palkkia, otsikon jälkeen latautuvia tähtiarvioita, hinnan alle tulevaa osamaksuviestiä ja suosituskaruselleja. Shopify huomauttaa, että myös ponnahdussisältö voi aiheuttaa siirtymiä (Shopify (avautuu uuteen välilehteen)).

Siirtymiä, jotka tapahtuvat 500 ms:n kuluessa käyttäjän syötteestä, ei lasketa, mutta vierityksen aikana tapahtuvat siirtymät lasketaan, ja laboratoriotyökalut jättävät ne usein huomaamatta (web.dev (avautuu uuteen välilehteen)). Anna kuville width- ja height-määritteet tai CSS:n aspect-ratio, varaa tilaa widgeteille, näytä bannerit sisällön päälle asettuvina kerroksina, vähennä fontin vaihtumisesta johtuvia siirtymiä size-adjust-ominaisuudella ja animoi transform-ominaisuudella top- tai left-ominaisuuksien sijaan.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Miten Core Web Vitals -tuloksia parannetaan Shopifyssa?

Shopifyssa suurin hyöty saadaan yleensä lataamalla ensimmäinen kuva heti korkealla prioriteetilla, karsimalla sovellusten skriptejä ja tarkistamalla tulos hallintapaneelin verkkosuorituskykyraporteista.

Tarkista data hallintapaneelista

Yhteenveto näkyy sivulla Verkkokauppa > Teemat (Online Store > Themes), ja täydet LCP-, INP- ja CLS-raportit löytyvät kohdasta Analytiikka > Raportit (Analytics > Reports). Data voi viivästyä jopa 36 tuntia, ja yksityistilan on oltava pois päältä (Shopify Help Center (avautuu uuteen välilehteen)).

Hallitse kuvien latausta Liquidissa

image_tag-suodatin lataa sivun alempien osioiden kuvat laiskasti, ellet aseta preload-parametria (image_tag-viite (avautuu uuteen välilehteen)): osiot 1–3 ladataan heti, osiosta 4 alkaen laiskasti. Koska section.index on teemaeditorissa nil, käytä ehtoa > 3 äläkä ehtoa <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Tuoteruudukoissa Shopify ehdottaa, että vain muutama ensimmäinen tuotekortti ladataan heti (esimerkiksi forloop.index <= 4) (Shopify (avautuu uuteen välilehteen)). Käytä preload: true -asetusta säästeliäästi; Shopify suosittelee esilataamaan vain yhden tai kaksi myöhään löytyvää resurssia.

Poista sovellusten jäänteet

Poista käyttämättömät sovellusten upotukset käytöstä kohdassa Verkkokauppa > Muokkaa teemaa > Sovellusten upotukset (Online Store > Edit theme > App embeds) (Shopify Help Center (avautuu uuteen välilehteen)). Sovelluksen poistaminen poistaa sen sovelluslohkot, mutta sovellukset, jotka muokkasivat teematiedostoja suoraan, voivat jättää jälkeensä ”haamukoodia”, joka Shopifyn mukaan voi aiheuttaa laatu- ja suorituskykyongelmia (Shopify (avautuu uuteen välilehteen)). Shopifyn mukaan script tag -skriptit myös lakkaavat toimimasta 1. maaliskuuta 2027. Fonttien osalta Shopify suosittelee omaa CDN:äänsä tai järjestelmäfontteja ulkoisten fonttipalvelujen sijaan (Shopify (avautuu uuteen välilehteen)).

Miten Core Web Vitals -tuloksia parannetaan WooCommercessa?

Varmista WooCommercessa, etteivät lisäosat ohita WordPressin kuvien priorisointia, tallenna välimuistiin kaikki paitsi ostoskori ja kassa ja poista skriptit, jotka latautuvat tarpeettomasti joka sivulla.

  • Säilytä ytimen kuvankäsittely. WordPress 6.3:sta lähtien (julkaistu 8. elokuuta 2023) ydin lisää fetchpriority="high"-määritteen todennäköiseen LCP-kuvaan (oletuksena vähintään 50 000 neliöpikseliä) ja jättää kolme ensimmäistä sisältökuvaa laiskan latauksen ulkopuolelle (Make WordPress Core (avautuu uuteen välilehteen)). Jos optimointilisäosa lisää oman laiskan latauksensa, tarkista, että se jättää hero-kuvan ja päätuotekuvan sen ulkopuolelle.
  • Tallenna välimuistiin sivut, älä ostoskoreja. WooCommercen opas suosittelee palvelimen tai lisäosan sivuvälimuistia ja CDN:ää mutta ostoskori- ja kassasivujen jättämistä välimuistin ulkopuolelle (WooCommercen kehittäjädokumentaatio (avautuu uuteen välilehteen)).
  • Tarkista cart fragments. WooCommerce 7.8:sta lähtien cart fragments -skripti latautuu vain sivuilla, joilla on Cart-widget, mutta jotkin teemat sisältävät widgetin kovakoodattuna. Mini-Cart-lohko ei käytä cart fragments -toimintoa (WooCommercen kehittäjäblogi (avautuu uuteen välilehteen)).
  • Etsi raskaat lisäosat. WooCommerce ehdottaa Query Monitoria hitaiden lisäosien löytämiseen ja ei-kriittisen JavaScriptin lykkäämistä.

Jos asettelussasi on ensimmäisessä näkymässä enemmän kuin kolme kuvaa, voit nostaa WordPressin raja-arvoa:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Kuinka kauan kestää, ennen kuin korjaukset näkyvät?

Laboratoriotestit näyttävät korjauksen vaikutuksen heti, mutta voi kulua jopa noin neljä viikkoa, ennen kuin vaikutus näkyy kenttädatassa täysin, koska CrUX laskee keskiarvon edelliseltä 28 päivältä.

Aja laboratoriotesti useita kertoja ennen muutosta ja sen jälkeen, koska yksittäiset ajot vaihtelevat, ja seuraa sitten kenttälukuja PageSpeed Insightsissa, Search Consolen Core Web Vitals -raportissa tai Shopifyn raporteissa. Ilmainen skannaus antaa ensimmäisen arvion noin minuutissa. Suorituskykyraportti ajaa hidastetun mobiililaboratoriotestin (hidas 4G, 4-kertainen suoritinhidastus) ja lisää siihen Chrome UX Reportin kenttädatan, myös INP:n, kun Googlella on kaupastasi riittävästi dataa.

Usein kysytyt kysymykset

Vaikuttavatko Core Web Vitals Googlen hakusijoituksiin?

Googlen mukaan sen sijoitusjärjestelmät käyttävät Core Web Vitals -mittareita, mutta hyvät tulokset eivät takaa kärkisijoja, ja Google näyttää silti osuvimman sisällön, vaikka sivukokemus olisi heikko (Google Search Central (avautuu uuteen välilehteen)).

Miksi PageSpeed Insights ei näytä kauppani kenttädataa?

CrUX sisältää vain sivut ja sivustot (originit), jotka ovat julkisesti löydettävissä ja joilla on riittävästi kelvollisia Chrome-kävijöitä. Vähäisen liikenteen kaupalla voi olla dataa vain koko sivuston tasolla tai ei lainkaan, joten nojaa laboratoriotesteihin ja alustasi omiin raportteihin.

Tarvitaanko läpäisyyn vähintään 90 pisteen Lighthouse-tulos?

Ei. Lighthousen suorituskykypisteet ovat laboratoriotulos, kun taas Core Web Vitals -arviointi käyttää kenttädataa 75. persentiilissä, joten sivu voi läpäistä arvioinnin vaatimattomalla Lighthouse-tuloksella ja epäonnistua korkealla.

Pitäisikö kaikki tuotekuvat ladata laiskasti?

Ei. Lataa laiskasti ensimmäisen näkymän alapuolella olevat kuvat, mutta lataa hero-kuva ja päätuotekuva heti ja anna toiselle niistä fetchpriority="high".

Miksi mobiilitulokseni ovat huonompia kuin tietokoneella?

Google mittaa mobiilin ja tietokoneen erikseen, ja puhelimissa on hitaammat suorittimet ja verkot. Lighthousen mobiilitesti simuloi tätä Slow 4G -profiililla ja 4-kertaisella suorittimen hidastuksella.

Lähteet

Kaikki oppaat