Core Web Vitals for nettbutikker: LCP, INP og CLS forklart

Hva LCP, INP og CLS måler, grensene for god og dårlig ved 75-persentilen, labdata mot feltdata og de vanlige rettelsene i Shopify- og WooCommerce-butikker.

FixReports-redaksjonen12 min lesing

Core Web Vitals er tre målinger fra Google som beskriver hvordan ekte besøkende opplever en side: Largest Contentful Paint (LCP) for innlasting, Interaction to Next Paint (INP) for responsivitet og Cumulative Layout Shift (CLS) for visuell stabilitet. En side består når minst 75 % av besøkene ligger i området «god»: LCP innen 2,5 sekunder, INP innen 200 millisekunder og CLS på 0,1 eller lavere, målt separat for mobil og datamaskin. I nettbutikker skyldes dårlige resultater som regel store hero- og produktbilder eller slike bilder med lazy loading, skript fra apper og sporing, nettfonter og bannere eller anmeldelseswidgeter som dytter innholdet nedover etter at siden har dukket opp.

Kort oppsummert

Hva er grenseverdiene for Core Web Vitals?

En side oppfyller Core Web Vitals når 75-persentilen av sidevisningene ligger i området «god» for alle tre målingene.

MålingHva den målerGodTrenger forbedringDårlig
LCPTiden til det største bildet, den største videoen eller tekstblokken i visningsområdet er gjengitt2,5 s eller mindreOver 2,5 s og opptil 4,0 sOver 4,0 s
INPTiden fra et klikk, trykk eller tastetrykk til neste bilde (frame) er tegnet200 ms eller mindreOver 200 ms og opptil 500 msOver 500 ms
CLSHvor mye synlig innhold flytter seg uventet0,1 eller mindreOver 0,1 og opptil 0,25Over 0,25

Grenseverdiene er hentet fra veiledningene til web.dev om LCP (åpnes i en ny fane), INP (åpnes i en ny fane) og CLS (åpnes i en ny fane), per oktober 2026.

At det måles ved 75-persentilen, betyr at resultatet gjenspeiler de fleste besøkende, ikke bare de raskeste, og Google skiller mellom mobil og datamaskin (åpnes i en ny fane). PageSpeed Insights godkjenner en side når alle tre målingene er gode; uten nok INP-data vurderes LCP og CLS alene (dokumentasjonen for PageSpeed Insights (åpnes i en ny fane)). Google sier at de stabile Core Web Vitals-målingene ikke endres oftere enn én gang i året.

I en nettbutikk er LCP-elementet ofte hero-banneret eller hovedbildet av produktet, og derfor betyr bildehåndteringen så mye.

Hvorfor erstattet INP FID i mars 2024?

INP erstattet FID fordi FID bare målte den første interaksjonen og bare en del av forsinkelsen, mens INP ser på interaksjoner gjennom hele besøket.

Google kunngjorde i mai 2023 at INP skulle bli en Core Web Vital, og byttet trådte i kraft 12. mars 2024 (åpnes i en ny fane). FID rapporterte bare den første interaksjonen, og bare inputforsinkelsen, ikke tiden som gikk med til å kjøre hendelsesbehandlere eller tegne resultatet. INP observerer klikk, trykk og tastetrykk gjennom hele besøket og rapporterer den lengste, der ekstreme avvik holdes utenfor; rulling og hovring teller ikke. Brukere av API-ene til CrUX og PageSpeed Insights hadde frist til 9. september 2024 med å bytte (web.dev (åpnes i en ny fane)).

Hver interaksjon består av tre deler: inputforsinkelse (venting på skript som holder hovedtråden opptatt), behandlingstid (kjøring av hendelsesbehandlerne) og presentasjonsforsinkelse (tegning av neste bilde) (web.dev (åpnes i en ny fane)).

I en nettbutikk er dette interaksjoner med variantvelgeren, antallsknappene, «Legg i handlekurven», handlekurvpanelet, filtrene og menyene. En side kunne bestå FID med et raskt første trykk og likevel føles treg når noen åpner filtrene senere.

Hva er forskjellen på labdata og feltdata?

Labdata kommer fra én test under faste forhold, mens feltdata samles inn fra ekte besøkende over tid, og Google anbefaler å bruke feltdata til å avgjøre hva du bør rette først (web.dev (åpnes i en ny fane)).

LabdataFeltdata
KildeÉn simulert sidevisning (Lighthouse, Chrome DevTools, labdelen av PageSpeed Insights)Ekte besøkende i Chrome (Chrome UX Report) eller din egen overvåking av ekte brukere (RUM)
ForholdFast enhet og nettverk. Lighthouses standard mobiltest (åpnes i en ny fane) bruker «Slow 4G» (150 ms tur-retur, 1,6 Mbps nedlasting) og en 4x nedbremsing av prosessorenDe enhetene, nettverkene og stedene de besøkende faktisk har
INPMåles ikke ved en vanlig sidevisning. Total Blocking Time (TBT) er en grov tilnærmingMåles ut fra ekte interaksjoner
Best tilFeilsøking og kontroll av en endring før lanseringÅ vite hva de besøkende faktisk opplever

TBT summerer den delen av hver oppgave på hovedtråden som går ut over 50 ms; web.dev foreslår under 200 ms på gjennomsnittlig mobilmaskinvare, men sier at TBT ikke kan erstatte INP (web.dev (åpnes i en ny fane)).

Tre detaljer ved Chrome UX Report (CrUX) har betydning for nettbutikker:

  • Rapporten er et glidende gjennomsnitt over 28 dager (åpnes i en ny fane) og oppdateres daglig.
  • Den dekker Chrome på datamaskin og Android for brukere som oppfyller Chromes vilkår for rapportering. Chrome på iOS er ikke med, så en butikk der de fleste kundene bruker iPhone, ser feltdata fra bare en del av publikummet sitt (metodikk (åpnes i en ny fane)).
  • Sider og opprinnelser (origins) vises bare når de er offentlig synlige og populære nok, så en butikk med lite trafikk har kanskje bare data på opprinnelsesnivå, eller ingen data i det hele tatt.

Shopifys dashbord for nettytelse (åpnes i en ny fane) rapporterer også LCP, INP og CLS fra ekte brukere ved 75-persentilen, men over 30 dager i stedet for 28, så regn med noen forskjeller fra CrUX.

Hva gjør LCP tregt på butikksider?

LCP er som regel tregt i nettbutikker fordi hovedbildet er for tungt, oppdages sent eller med vilje blir forsinket av lazy loading eller en animasjon.

  • Lazy loading av LCP-bildet. web.dev sier at du aldri skal gjøre dette (web.dev (åpnes i en ny fane)). En analyse av WordPress-sider fant tregere LCP ved 75-persentilen på nettsteder som brukte innebygd lazy loading, og når bildene over bretten ikke ble lastet med lazy loading, forsvant forverringen (web.dev (åpnes i en ny fane)).
  • Et bilde som oppdages sent. Et hero-bilde som er satt som CSS-background-image, eller som settes inn av et skript for en bildekarusell, finnes ikke i HTML-en som nettleseren skanner først. Shopify fraråder CSS-bakgrunner for hero-innhold og inntoningseffekter på LCP-bildet (Shopify (åpnes i en ny fane)).
  • Lav prioritet. Bilder lastes med lav prioritet til layouten er ferdig, så Shopify anbefaler fetchpriority="high" på LCP-bildet (Shopify (åpnes i en ny fane)). web.dev påpeker at attributtet blir mindre nyttig hvis du setter det på mer enn ett eller to bilder (web.dev (åpnes i en ny fane)).
  • Renderingsblokkerende CSS og skript. Store stilark og synkrone skript i <head> forsinker gjengivelsen selv etter at bildet har kommet (web.dev (åpnes i en ny fane)).
  • Filstørrelse og fonter. Bruk moderne formater, srcset og sizes og et CDN. For nettfonter bør du bruke en annen font-display-verdi enn auto eller 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">

Hva gjør INP tregt på butikksider?

Treg INP i nettbutikker betyr som regel for mye JavaScript på hovedtråden, mye av det fra apper, sporingstagger og temafunksjoner, slik at trykkene må vente.

Hvis en kunde trykker på «Legg i handlekurven» mens skript for anmeldelser, chat og analyse fortsatt kjører, må trykket vente. En variantvelger som gjengir hele produktskjemaet på nytt, øker behandlingstiden. Enorme megamenyer og kolleksjonsrutenett med mange fargeprøver øker presentasjonsforsinkelsen.

web.dev anbefaler å dele opp lange oppgaver og gi fra seg hovedtråden (yielding), oppdatere skjermen først og utsette resten, og holde DOM-en mindre (web.dev (åpnes i en ny fane)). Shopify legger til tiltak som er særlig aktuelle for nettbutikker: gå gjennom hver app, hver piksel og hvert temaskript, utsett det som ikke er kritisk, last inn funksjoner først ved interaksjon, og slå av anti-flimmer-snutter for A/B-testing når ingen test kjører (Shopify (åpnes i en ny fane)).

Hva forårsaker layoutforskyvninger på produkt- og kolleksjonssider?

Layoutforskyvninger i nettbutikker kommer for det meste fra innhold som dukker opp eller endrer størrelse etter første gjengivelse: bilder uten dimensjoner, kunngjøringslinjer og bannere for informasjonskapsler, anmeldelseswidgeter, appblokker og fontbytter.

web.dev lister opp de vanligste årsakene: medier med ukjente dimensjoner, innhold som legges til over eksisterende innhold, tredjepartswidgeter som endrer sin egen størrelse, og nettfonter som har en annen størrelse enn reservefonten (web.dev (åpnes i en ny fane)). I nettbutikker betyr det et banner om gratis frakt som settes inn øverst, stjernevurderinger som lastes etter tittelen, informasjon om delbetaling under prisen og karuseller med anbefalinger. Shopify påpeker at innhold i popup-vinduer også kan føre til forskyvninger (Shopify (åpnes i en ny fane)).

Forskyvninger innen 500 ms etter at brukeren har gjort noe, teller ikke, men forskyvninger under rulling gjør det, og labverktøy fanger dem ofte ikke opp (web.dev (åpnes i en ny fane)). Gi bildene width og height eller et CSS-aspect-ratio, reserver plass til widgeter, vis bannere oppå innholdet, reduser forskyvninger ved fontbytte med size-adjust, og animer med transform i stedet for top eller left.

/* 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; }

Hvordan forbedrer du Core Web Vitals i Shopify?

I Shopify kommer det meste av gevinsten fra å laste det første bildet umiddelbart med høy prioritet, rydde i appskriptene og sjekke resultatet i rapportene for nettytelse i administrasjonspanelet.

Sjekk dataene i administrasjonspanelet

En oppsummering vises på siden Nettbutikk > Temaer (Online Store > Themes), og fullstendige rapporter om LCP, INP og CLS finner du under Analyse > Rapporter (Analytics > Reports). Dataene kan være forsinket med opptil 36 timer, og privat modus må være slått av (Shopify Help Center (åpnes i en ny fane)).

Styr bildeinnlastingen i Liquid

image_tag-filteret laster bilder i seksjoner lenger ned på siden med lazy loading, med mindre du angir preload (referanse for image_tag (åpnes i en ny fane)): umiddelbart for seksjon 1 til 3, lazy loading fra seksjon 4. Fordi section.index er nil i temaredigeringsprogrammet, bør du teste med > 3 i stedet for <= 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 -%}

I produktrutenett foreslår Shopify å laste bare de første kortene umiddelbart (for eksempel forloop.index <= 4) (Shopify (åpnes i en ny fane)). Bruk preload: true med måte; Shopify anbefaler å forhåndslaste bare én eller to ressurser som oppdages sent.

Fjern det appene etterlater seg

Slå av appinnbygginger du ikke bruker, under Nettbutikk > Rediger tema > Appinnbygginger (Online Store > Edit theme > App embeds) (Shopify Help Center (åpnes i en ny fane)). Når du avinstallerer en app, fjernes appblokkene, men apper som har redigert temafilene direkte, kan etterlate seg «spøkelseskode» (ghost code) som ifølge Shopify kan gi problemer med kvalitet og ytelse (Shopify (åpnes i en ny fane)). Shopify sier også at skripttagger (script tags) slutter å kjøre 1. mars 2027. For fonter anbefaler Shopify sitt eget CDN eller systemfonter fremfor eksterne fonttjenester (Shopify (åpnes i en ny fane)).

Hvordan forbedrer du Core Web Vitals i WooCommerce?

I WooCommerce må du sørge for at utvidelser ikke overstyrer WordPress’ prioritering av bilder, mellomlagre alt unntatt handlekurv og kasse, og fjerne skript som lastes overalt uten at det trengs.

  • Behold kjernens bildehåndtering. Siden WordPress 6.3 (lansert 8. august 2023) legger kjernen til fetchpriority="high" på det sannsynlige LCP-bildet (minst 50 000 kvadratpiksler som standard) og hopper over lazy loading for de tre første innholdsbildene (Make WordPress Core (åpnes i en ny fane)). Hvis en optimaliseringsutvidelse legger til sin egen lazy loading, må du sjekke at den unntar hero-bildet og hovedbildet av produktet.
  • Mellomlagre sider, ikke handlekurver. WooCommerce-veiledningen anbefaler sidemellomlagring på serveren eller via en utvidelse, og et CDN, men at sidene for handlekurv og kasse ikke mellomlagres (WooCommerce developer docs (åpnes i en ny fane)).
  • Sjekk cart fragments. Siden WooCommerce 7.8 lastes skriptet for handlekurvfragmenter (cart fragments) bare der en handlekurvwidget (Cart widget) finnes, men noen temaer har den widgeten hardkodet. Mini-Cart-blokken bruker ikke cart fragments (WooCommerce developer blog (åpnes i en ny fane)).
  • Finn tunge utvidelser. WooCommerce foreslår Query Monitor for å finne trege utvidelser, og å utsette JavaScript som ikke er kritisk.

Hvis layouten din viser mer enn tre bilder over bretten, kan du heve terskelen i WordPress:

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

Hvor lang tid tar det før rettelsene vises?

Labtester viser effekten av en rettelse med en gang, men feltdata trenger opptil omtrent fire uker for å gjenspeile den fullt ut, fordi CrUX beregner gjennomsnittet av de siste 28 dagene.

Kjør labtesten flere ganger før og etter en endring, fordi enkeltkjøringer varierer, og følg deretter feltdataene i PageSpeed Insights, Core Web Vitals-rapporten i Search Console eller rapportene i Shopify. En gratis skanning gir en første vurdering på omtrent ett minutt. Vår Ytelsesrapport kjører en strupet labtest på mobil (slow 4G, 4x CPU) og legger til feltdata fra Chrome UX Report, inkludert INP når Google har nok data om butikken din.

Ofte stilte spørsmål

Påvirker Core Web Vitals rangeringen i Google?

Google sier at Core Web Vitals brukes av rangeringssystemene, men at gode resultater ikke garanterer topplasseringer, og at Google fortsatt viser det mest relevante innholdet selv når sideopplevelsen er dårlig (Google Search Central (åpnes i en ny fane)).

Hvorfor viser PageSpeed Insights ingen feltdata for butikken min?

CrUX tar bare med sider og opprinnelser som er offentlig synlige og har nok kvalifiserte besøkende i Chrome. En butikk med lite trafikk har kanskje bare data på opprinnelsesnivå, eller ingen, så støtt deg på labtester og plattformens egne rapporter.

Må jeg ha en Lighthouse-poengsum på 90 eller mer for å bestå?

Nei. Ytelsespoengsummen i Lighthouse er et labresultat, mens vurderingen av Core Web Vitals bruker feltdata ved 75-persentilen, så en side kan bestå med en middels Lighthouse-poengsum og stryke med en høy.

Bør jeg bruke lazy loading på alle produktbilder?

Nei. Bruk lazy loading på bilder under den første skjermen, men last inn hero-bildet og hovedbildet av produktet umiddelbart, med fetchpriority="high" på ett av dem.

Hvorfor er resultatene på mobil dårligere enn på datamaskin?

Google måler mobil og datamaskin hver for seg, og telefoner har tregere prosessorer og nettverk. Lighthouses mobiltest simulerer dette med en Slow 4G-profil og en 4x nedbremsing av prosessoren.

Kilder

Alle veiledninger