Core Web Vitals för webbutiker: LCP, INP och CLS förklarade

Vad LCP, INP och CLS mäter, gränsvärdena vid 75:e percentilen, labbdata mot fältdata och de vanligaste åtgärderna för Shopify- och WooCommerce-butiker.

FixReports redaktion12 min läsning

Core Web Vitals är tre mätvärden från Google som beskriver hur verkliga besökare upplever en sida: Largest Contentful Paint (LCP) för inläsning, Interaction to Next Paint (INP) för responsivitet och Cumulative Layout Shift (CLS) för visuell stabilitet. En sida klarar bedömningen när minst 75 % av besöken ligger inom intervallet ”bra”: LCP inom 2,5 sekunder, INP inom 200 millisekunder och CLS på högst 0,1, mätt separat för mobil och dator. I webbutiker beror dåliga värden oftast på stora eller lazy-loadade hero- och produktbilder, skript från appar och spårning, webbtypsnitt samt banners eller recensionswidgetar som trycker ner innehållet efter att sidan har visats.

Det viktigaste i korthet

Vilka gränsvärden gäller för Core Web Vitals?

En sida uppfyller Core Web Vitals när 75:e percentilen av dess sidladdningar hamnar inom intervallet bra för alla tre mätvärdena.

MätvärdeVad det mäterBraBehöver förbättrasDåligt
LCPTiden tills den största bilden, videon eller textblocket i visningsområdet har renderats2,5 s eller mindreÖver 2,5 s upp till 4,0 sÖver 4,0 s
INPTiden från ett klick, tryck eller tangenttryck tills nästa bildruta har ritats upp200 ms eller mindreÖver 200 ms upp till 500 msÖver 500 ms
CLSHur mycket synligt innehåll som flyttar sig oväntat0,1 eller mindreÖver 0,1 upp till 0,25Över 0,25

Gränsvärdena kommer från web.dev:s guider om LCP (öppnas i en ny flik), INP (öppnas i en ny flik) och CLS (öppnas i en ny flik), i oktober 2026.

Att mätningen sker vid 75:e percentilen betyder att resultatet speglar de flesta besökare, inte bara de snabbaste, och Google delar upp mobil och dator (öppnas i en ny flik). PageSpeed Insights godkänner en sida när alla tre mätvärdena är bra; om det inte finns tillräckligt med INP-data bedöms bara LCP och CLS (dokumentationen för PageSpeed Insights (öppnas i en ny flik)). Google säger att stabila Core Web Vitals inte ändras mer än en gång per år.

I en webbutik är LCP-elementet ofta hero-bannern eller den största produktbilden, och därför spelar bildhanteringen så stor roll.

Varför ersatte INP FID i mars 2024?

INP ersatte FID eftersom FID bara mätte den första interaktionen och bara en del av dess fördröjning, medan INP tittar på interaktioner under hela besöket.

Google meddelade i maj 2023 att INP skulle bli en Core Web Vital, och bytet trädde i kraft den 12 mars 2024 (öppnas i en ny flik). FID rapporterade bara den första interaktionen och bara dess inmatningsfördröjning, inte tiden det tog att köra händelsehanterare eller rita upp resultatet. INP observerar klick, tryck och tangenttryck under hela besöket och rapporterar det längsta, med extremvärden bortrensade; scrollning och hovring räknas inte. Användare av API:erna för CrUX och PageSpeed Insights hade till den 9 september 2024 på sig att byta (web.dev (öppnas i en ny flik)).

Varje interaktion består av tre delar: inmatningsfördröjning (väntan på upptagna skript), bearbetningstid (körning av händelsehanterarna) och presentationsfördröjning (uppritning av nästa bildruta) (web.dev (öppnas i en ny flik)).

I en webbutik är de interaktionerna variantväljaren, knapparna för antal, lägg i varukorgen, den utfällbara varukorgen, filter och menyer. En sida kunde klara FID tack vare ett snabbt första tryck och ändå kännas långsam när någon öppnade filtren senare.

Vad är skillnaden mellan labbdata och fältdata?

Labbdata kommer från ett enskilt test under fasta förhållanden, medan fältdata samlas in från verkliga besökare över tid, och Google rekommenderar att du utgår från fältdata när du bestämmer vad som ska åtgärdas först (web.dev (öppnas i en ny flik)).

LabbdataFältdata
KällaEn simulerad sidladdning (Lighthouse, Chrome DevTools, labbdelen av PageSpeed Insights)Verkliga besökare i Chrome (Chrome UX Report) eller din egen övervakning av verkliga användare (RUM)
FörhållandenFast enhet och fast nätverk. Lighthouses standardtest för mobil (öppnas i en ny flik) använder ”Slow 4G” (150 ms tur och retur, 1,6 Mbps nedladdning) och en CPU som är 4x långsammareDe enheter, nätverk och platser som dina besökare faktiskt har
INPMäts inte vid en vanlig sidladdning. Total Blocking Time (TBT) är en grov ersättareMäts från verkliga interaktioner
Passar bäst förFelsökning och kontroll av en ändring före lanseringAtt veta vad besökarna faktiskt får

TBT summerar den del av varje uppgift på huvudtråden som överstiger 50 ms; web.dev föreslår under 200 ms på genomsnittlig mobil hårdvara men säger att det inte ersätter INP (web.dev (öppnas i en ny flik)).

Tre detaljer i Chrome UX Report (CrUX) är viktiga för webbutiker:

  • Det är ett rullande genomsnitt över 28 dagar (öppnas i en ny flik) som uppdateras dagligen.
  • Det omfattar Chrome på dator och Android för användare som uppfyller Chromes villkor för rapportering. Chrome på iOS ingår inte, så en butik med mest iPhone-kunder ser fältdata från bara en del av sin publik (metodik (öppnas i en ny flik)).
  • Sidor och ursprung visas bara när de är offentligt sökbara och tillräckligt populära, så en butik med lite trafik kan ha data enbart på ursprungsnivå, eller ingen alls.

Shopifys instrumentpanel för webbprestanda (öppnas i en ny flik) rapporterar också LCP, INP och CLS från verkliga användare vid 75:e percentilen, men över 30 dagar i stället för 28, så räkna med vissa skillnader mot CrUX.

Vad gör LCP långsamt på butikens sidor?

LCP är oftast långsamt i webbutiker eftersom huvudbilden är för tung, upptäcks sent eller medvetet fördröjs av lazy loading eller en animering.

  • Lazy loading av LCP-bilden. web.dev säger att du aldrig ska göra det (web.dev (öppnas i en ny flik)). Dess analys av WordPress-sidor visade långsammare LCP vid 75:e percentilen på webbplatser som använde inbyggd lazy loading, och när bilder ovanför vecket inte längre lazy-loadades försvann försämringen (web.dev (öppnas i en ny flik)).
  • En bild som hittas sent. En hero-bild som är satt som CSS-background-image, eller som läggs in av ett skript för en bildspelare, finns inte i den HTML som webbläsaren läser först. Shopify avråder från CSS-bakgrunder för hero-innehåll och från intoningseffekter på LCP-bilden (Shopify (öppnas i en ny flik)).
  • Låg prioritet. Bilder läses in med låg prioritet tills layouten är klar, så Shopify rekommenderar fetchpriority="high" på LCP-bilden (Shopify (öppnas i en ny flik)). web.dev påpekar att attributet blir mindre användbart om du sätter det på fler än en eller två bilder (web.dev (öppnas i en ny flik)).
  • Renderingsblockerande CSS och skript. Stora stilmallar och synkrona skript i <head> fördröjer renderingen även efter att bilden har kommit (web.dev (öppnas i en ny flik)).
  • Filstorlek och typsnitt. Använd moderna format, srcset och sizes samt ett CDN. För webbtypsnitt använder du ett annat font-display-värde än 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">

Vad gör INP långsamt på butikens sidor?

Långsam INP i en webbutik innebär oftast för mycket JavaScript på huvudtråden, mycket av det från appar, spårningstaggar och funktioner i temat, så att tryck måste vänta.

Om en kund trycker på ”Lägg i varukorgen” medan skript för recensioner, chatt och analys fortfarande körs, får trycket vänta. En variantväljare som renderar om hela produktformuläret ökar bearbetningstiden. Stora megamenyer och kategorirutnät med många färgrutor ökar presentationsfördröjningen.

web.dev rekommenderar att du delar upp långa uppgifter och lämnar tillbaka kontrollen till huvudtråden, uppdaterar skärmen först och skjuter upp resten, och håller DOM:en mindre (web.dev (öppnas i en ny flik)). Shopify lägger till butiksspecifika steg: gå igenom varje app, pixel och skript i temat, skjut upp det som inte är kritiskt, läs in funktioner först vid interaktion och stäng av anti-flimmer-kod för A/B-tester när inget test pågår (Shopify (öppnas i en ny flik)).

Vad orsakar layoutförskjutningar på produkt- och kategorisidor?

Layoutförskjutningar i webbutiker kommer mest från innehåll som dyker upp eller ändrar storlek efter den första renderingen: bilder utan mått, aviserings- och cookiefält, recensionswidgetar, appblock och typsnittsbyten.

web.dev listar de vanligaste orsakerna som media med okända mått, innehåll som läggs till ovanför befintligt innehåll, widgetar från tredje part som ändrar storlek på sig själva och webbtypsnitt som har en annan storlek än sitt reservtypsnitt (web.dev (öppnas i en ny flik)). I en webbutik betyder det ett fält om fri frakt som läggs in högst upp, stjärnbetyg som läses in efter rubriken, information om delbetalning under priset och karuseller med rekommendationer. Shopify påpekar att innehåll i popup-fönster också kan orsaka förskjutningar (Shopify (öppnas i en ny flik)).

Förskjutningar inom 500 ms efter en användares inmatning räknas inte, men förskjutningar under scrollning gör det, och labbverktyg missar dem ofta (web.dev (öppnas i en ny flik)). Ge bilder width och height eller ett CSS-aspect-ratio, reservera plats för widgetar, visa banners som överlägg, minska förskjutningar vid typsnittsbyten med size-adjust och animera med transform i stället för 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; }

Hur förbättrar du Core Web Vitals i Shopify?

I Shopify kommer de största vinsterna från att läsa in den första bilden direkt med hög prioritet, banta appskripten och kontrollera resultatet i adminpanelens rapporter om webbprestanda.

Kontrollera data i adminpanelen

En sammanfattning visas på sidan Onlinebutik > Teman (Online Store > Themes), och fullständiga rapporter om LCP, INP och CLS finns under Analys > Rapporter (Analytics > Reports). Data kan vara upp till 36 timmar försenade, och privat läge måste vara avstängt (Shopify Help Center (öppnas i en ny flik)).

Styr bildinläsningen i Liquid

Filtret image_tag lazy-loadar bilder i sektioner längre ner på sidan om du inte anger preload (referens för image_tag (öppnas i en ny flik)): direkt inläsning för sektion 1 till 3, lazy loading från sektion 4. Eftersom section.index är nil i temaredigeraren ska du testa med > 3 i stället för <= 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 produktrutnät föreslår Shopify att bara de första korten läses in direkt (till exempel forloop.index <= 4) (Shopify (öppnas i en ny flik)). Använd preload: true sparsamt; Shopify rekommenderar att du bara förinläser en eller två resurser som upptäcks sent.

Ta bort det som appar lämnar efter sig

Stäng av oanvända appinbäddningar under Onlinebutik > Redigera tema > Appinbäddningar (Online Store > Edit theme > App embeds) (Shopify Help Center (öppnas i en ny flik)). När du avinstallerar en app tas dess appblock bort, men appar som har redigerat temafilerna direkt kan lämna kvar ”spökkod” (ghost code) som enligt Shopify kan orsaka problem med kvalitet och prestanda (Shopify (öppnas i en ny flik)). Shopify uppger också att skripttaggar (script tags) slutar köras den 1 mars 2027. För typsnitt rekommenderar Shopify sitt eget CDN eller systemtypsnitt framför externa typsnittstjänster (Shopify (öppnas i en ny flik)).

Hur förbättrar du Core Web Vitals i WooCommerce?

I WooCommerce ska du se till att tillägg inte åsidosätter WordPress bildprioritering, cacha allt utom varukorg och kassa och ta bort skript som läses in överallt utan att behövas.

  • Behåll kärnans bildhantering. Sedan WordPress 6.3 (som släpptes den 8 augusti 2023) lägger kärnan till fetchpriority="high" på den troliga LCP-bilden (som standard minst 50 000 kvadratpixlar) och hoppar över lazy loading för de tre första innehållsbilderna (Make WordPress Core (öppnas i en ny flik)). Om ett optimeringstillägg lägger till egen lazy loading, kontrollera att det undantar hero-bilden och den största produktbilden.
  • Cacha sidor, inte varukorgar. WooCommerces guide rekommenderar sidcachning på servern eller via ett tillägg samt ett CDN, men att sidorna för varukorg och kassa inte cachas (WooCommerce developer docs (öppnas i en ny flik)).
  • Kontrollera cart fragments. Sedan WooCommerce 7.8 läses skriptet för cart fragments bara in där en Cart-widget finns, men vissa teman hårdkodar den widgeten. Blocket Mini-Cart använder inte cart fragments (WooCommerce developer blog (öppnas i en ny flik)).
  • Hitta tunga tillägg. WooCommerce föreslår Query Monitor för att hitta långsamma tillägg, och att du skjuter upp JavaScript som inte är kritiskt.

Om din layout visar fler än tre bilder ovanför vecket kan du höja tröskeln 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;
} );

Hur lång tid tar det innan åtgärderna syns?

Labbtester visar effekten av en åtgärd direkt, men fältdata behöver upp till ungefär fyra veckor för att spegla den fullt ut, eftersom CrUX räknar ett genomsnitt över de senaste 28 dagarna.

Kör labbtestet flera gånger före och efter en ändring, eftersom enskilda körningar varierar, och följ sedan fältvärdena i PageSpeed Insights, rapporten Core Web Vitals i Search Console eller Shopifys rapporter. En gratis skanning ger en första bild på ungefär en minut. Vår Prestandarapport kör ett strypt labbtest för mobil (Slow 4G, 4x CPU) och lägger till fältdata från Chrome UX Report, inklusive INP när Google har tillräckligt med data för din butik.

Vanliga frågor

Påverkar Core Web Vitals rankningen i Google?

Google säger att Core Web Vitals används av dess rankningssystem, men att bra värden inte garanterar topplaceringar och att Google ändå visar det mest relevanta innehållet även när sidupplevelsen är dålig (Google Search Central (öppnas i en ny flik)).

Varför visar PageSpeed Insights inga fältdata för min butik?

CrUX tar bara med sidor och ursprung som är offentligt sökbara och har tillräckligt många besökare i Chrome som uppfyller villkoren. En butik med lite trafik kan ha data enbart på ursprungsnivå, eller ingen alls, så förlita dig på labbtester och plattformens egna rapporter.

Behöver jag ett Lighthouse-poäng på 90 eller mer för att klara bedömningen?

Nej. Prestandapoängen i Lighthouse är ett labbresultat, medan bedömningen av Core Web Vitals använder fältdata vid 75:e percentilen, så en sida kan klara den med ett blygsamt Lighthouse-poäng och misslyckas med ett högt.

Ska jag använda lazy loading för alla produktbilder?

Nej. Använd lazy loading för bilder under den första skärmbilden, men läs in hero-bilden och den största produktbilden direkt, med fetchpriority="high" på en av dem.

Varför är mina resultat sämre på mobil än på dator?

Google mäter mobil och dator separat, och telefoner har långsammare processorer och nätverk. Lighthouses mobiltest simulerar det med profilen Slow 4G och en CPU som är 4x långsammare.

Källor

Alla guider