Praktisk guide till Core Web Vitals 2026 – trösklar för LCP, INP och CLS, hur ni mäter rätt med fältdata i stället för bara labbverktyg, och de tekniska åtgärderna som ger mest effekt per investerad timme.
Core Web Vitals är Googles tre mått på faktisk användarupplevelse — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) och Cumulative Layout Shift (CLS) — och 2026 är de varken nya eller valfria. De ingår i Page Experience-signalerna i sökrankningen, men den verkliga anledningen att bry sig är enklare: en sajt som känns långsam tappar besökare innan den ens hunnit visa vad den säljer. Vi har sett e-handelssajter höja konverteringen 10–15 procent enbart genom att sänka LCP från 6 till 2 sekunder — utan att röra en enda produktbild eller ändra ett enda pris.
Den här guiden går igenom vad varje mått faktiskt mäter, vilka trösklar som gäller 2026, hur du mäter rätt (labb kontra fält) och de tekniska åtgärderna som ger mest effekt per investerad timme. Vi utgår från verklig prioritering snarare än en uttömmande checklista — de flesta team har inte tid att fixa allt, och det behövs inte heller.
Core Web Vitals 2026 — vad mäts och varför det spelar roll
Google mäter tre saker som tillsammans fångar hur en sida upplevs: hur snabbt det viktigaste innehållet syns (LCP), hur snabbt sidan svarar när användaren interagerar (INP) och hur stabil layouten är medan sidan laddar (CLS). Trösklarna för "bra" är: LCP under 2,5 sekunder, INP under 200 millisekunder, CLS under 0,1. Allt mellan det och dubbla värdet klassas som "behöver förbättras", allt däröver som "dåligt".
INP ersatte First Input Delay (FID) permanent 2024, och det var ingen kosmetisk förändring. FID mätte bara fördröjningen till första interaktionen — INP mäter varje interaktion under hela sessionen och rapporterar den värsta. Det gör måttet betydligt svårare att klara för interaktionstunga appar, särskilt sådana byggda i React eller andra ramverk med mycket klientsidesrendering. Om er app är komplex och interaktiv rekommenderar vi att gräva djupare i just INP — vi har en separat guide om INP-optimering i komplexa React-appar som går igenom det i detalj.
LCP — tiden till det viktigaste innehållet
LCP mäter när det största synliga elementet i viewporten är färdigrenderat — oftast en hero-bild, en rubrik eller en video-thumbnail. De vanligaste bovarna är en ooptimerad bild i full upplösning, ett typsnitt som blockerar rendering, en långsam serverrespons (TTFB), eller render-blockerande JavaScript och CSS högt upp i dokumentet.
Det enskilt mest effektiva vi gör är att identifiera LCP-elementet och säkerställa att det laddas med högsta prioritet — inte lazy-loadat, inte bakom ett typsnitt som måste laddas färdigt först, och i rätt bildformat (AVIF eller WebP i stället för JPEG/PNG, vilket typiskt halverar filstorleken utan synlig kvalitetsförlust).
| 1 | // Next.js — prioritera LCP-bilden explicit |
| 2 | import Image from "next/image" |
| 3 | |
| 4 | export function Hero() { |
| 5 | return ( |
| 6 | <Image |
| 7 | src="/hero.avif" |
| 8 | alt="Produktöversikt" |
| 9 | width={1200} |
| 10 | height={630} |
| 11 | priority |
| 12 | /> |
| 13 | ) |
| 14 | } |
Utöver bilden: flytta kritisk CSS inline eller prioritera den, lägg <link rel="preconnect"> mot tredjepartsdomäner (typsnitt, analytics, betalningswidgetar) och undvik render-blockerande skript i <head>. På serversidan räknas TTFB rakt in i LCP — en API-route eller databasfråga som tar en sekund extra syns direkt i måttet, vilket är ett skäl till att prestandaarbete sällan stannar vid frontend. Ligger flaskhalsen i databasen snarare än i klienten är det ofta läge att gå igenom slow queries parallellt.
INP — responsen som avgör om appen känns snabb
INP mäter fördröjningen mellan en interaktion — klick, tryck, tangenttryckning — och nästa gång skärmen faktiskt uppdateras. Grundorsaken är nästan alltid densamma: en blockerad huvudtråd. JavaScript kör på en enda tråd, och en tung omrendering eller en synkron beräkning som triggas av ett klick håller tråden upptagen och stänger ute skärmuppdateringen.
Snabbaste vägen till bättre INP: bryt upp långa uppgifter, skjut icke-brådskande arbete (till exempel att uppdatera en sidopanel efter ett klick) bort från den synkrona hanteraren, och minska mängden JavaScript som överhuvudtaget skickas till klienten. Server Components och liknande mönster som flyttar logik till servern eliminerar hela klasser av INP-problem innan de ens uppstår. Den fullständiga metodiken — inklusive hur du mäter och prioriterar bland interaktioner — går vi igenom i den separata INP-guiden ovan.
CLS — layouten som inte får hoppa
CLS straffar sidor där innehåll hoppar medan användaren tittar på det — en bild som får sina dimensioner efter att den laddat, en banner som skjuts in ovanför innehållet, eller ett typsnitt som byts ut och ändrar radbrytningar. Det är det billigaste måttet att fixa och det som oftast glöms bort.
- Sätt alltid explicit
widthochheight(elleraspect-ratio) på bilder och inbäddat innehåll så att webbläsaren kan reservera utrymme innan det laddat. - Använd
font-display: optionalellerswapmed matchande fallback-typsnitt så att texten inte hoppar när webbtypsnittet landar. - Undvik att injicera innehåll (banners, cookie-notiser, annonser) ovanför befintligt innehåll utan reserverat utrymme.
- Animera med
transformi stället för egenskaper som påverkar layout (top,left,width).
De flesta CLS-problem vi hittar i en audit går att fixa på en eftermiddag — det är den bästa avkastningen per arbetstimme i hela Core Web Vitals-arbetet.
Mät rätt — labb kontra fält
Ett av de vanligaste misstagen är att optimera mot ett labbverktyg och tro att jobbet är klart. Lighthouse och PageSpeed Insights kör syntetiska tester på en simulerad anslutning och en standardiserad enhet — bra för att hitta problem, men de speglar inte vad era faktiska användare upplever. Google rankar baserat på fältdata från Chrome User Experience Report (CrUX), insamlad från riktiga besökares webbläsare.
Vår rekommendation: använd Lighthouse och WebPageTest för att felsöka och verifiera specifika åtgärder, men styr prioriteringen efter fältdata — CrUX i Google Search Console, eller Real User Monitoring (RUM) via till exempel Vercel Speed Insights, SpeedCurve eller ett eget datalager byggt på Web Vitals-biblioteket. Titta särskilt på 75:e percentilen, inte medianen — det är den som avgör betyget, och den fångar de långsammare enheterna och nätverken som medianen döljer.
Åtgärderna som ger mest effekt per timme
När vi kör en optimeringssprint börjar vi nästan alltid med samma lista, ungefär i den här ordningen efter avkastning:
- Bildformat och storlek — konvertera till AVIF/WebP, servera responsiva storlekar, lazy-loada allt utom LCP-elementet.
- Font-strategi — subsetting,
font-display: swap, preload av kritiska typsnitt. - Tredjepartsskript — ladda asynkront eller skjut upp till efter interaktion (chattwidgets, analytics och A/B-testverktyg är vanliga bovar).
- Code splitting — dela upp bundlen per route så att användaren bara laddar det som krävs för sidan de faktiskt är på.
- Edge-caching — flytta statiskt och semi-statiskt innehåll närmare användaren i stället för att rendera om det på varje request.
Sätt gärna prestandabudgetar i CI så att regressioner stoppas innan de når produktion, i stället för att upptäckas i nästa audit:
| 1 | // lighthouserc.json — budget som failar bygget vid regression |
| 2 | { |
| 3 | "ci": { |
| 4 | "assert": { |
| 5 | "assertions": { |
| 6 | "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }], |
| 7 | "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }], |
| 8 | "total-byte-weight": ["error", { "maxNumericValue": 1600000 }] |
| 9 | } |
| 10 | } |
| 11 | } |
| 12 | } |
Vanliga misstag som saboterar annars bra arbete
Även team som gjort rätt på pappret hittar vi ofta tre återkommande fällor i en audit. Den första är karuseller och hero-sektioner som förladdar fem bilder för att "kännas smidiga" när bara en syns initialt — varje overflödig bild konkurrerar om samma bandbredd som LCP-elementet. Den andra är Google Tag Manager-behållare som via ett enda taggnamn drar in tiotals tredjepartsskript synkront, ofta utan att teamet vet exakt vilka verktyg som faktiskt körs längre. Den tredje är typsnitt som laddas i fyra eller fem vikter "för säkerhets skull" när sidan i praktiken bara använder två — varje extra vikt är en extra nätverksresa som kan blockera text från att synas.
Gemensamt för alla tre är att de sällan syns i en snabb kodgranskning — det krävs en trace i webbläsarens nätverksflik eller en Lighthouse-körning med "Coverage"-panelen öppen för att upptäcka dem. Det är också därför en strukturerad audit nästan alltid hittar mer att vinna än vad utvecklingsteamet själva räknat med.
Prioritera med Pareto, inte magkänsla
För de flesta sajter är en förbättring på 30–60 procent av Core Web Vitals realistisk inom fyra veckor, utan att kompromissa med funktionalitet — i worst case-scenarion, där ingen tidigare optimering skett, ser vi ofta 50–70 procent. Men det kräver att arbetet prioriteras efter faktisk påverkan, inte efter vad som är enklast att fixa. Mät baseline, identifiera var 80 procent av smärtan sitter, åtgärda det, mät om. Det är samma metodik vi använder i alla optimeringsuppdrag oavsett om målet är prestanda, molnkostnad eller konvertering.
Vill ni ha en strukturerad genomgång av er sajts Core Web Vitals — med prioriterad åtgärdsplan och mätbart resultat? Läs mer om våra tjänster eller boka ett samtal.
“En sida kan ranka högt och ändå tappa kunder — det är gapet mellan labbdata och vad era riktiga användare faktiskt upplever som avgör.”
- Simon Axelsson
Vanliga frågor
- Vilket Core Web Vitals-mått bör vi prioritera först?
- Börja alltid med det som ligger längst från gränsvärdet i er fältdata, inte det som är enklast att fixa. CLS är oftast billigast att åtgärda (explicit bilddimensioner, rätt font-display) och ger snabb utdelning, medan LCP och INP ofta kräver djupare arkitekturförändringar. Låt CrUX-data i Search Console styra prioriteringen.
- Räcker det att köra Lighthouse för att veta hur vi ligger till?
- Nej. Lighthouse mäter en syntetisk körning på en simulerad anslutning och enhet, vilket är bra för felsökning men inte speglar verkliga användare. Google rankar baserat på fältdata (CrUX) från riktiga besökare. Använd Lighthouse för att verifiera specifika åtgärder, men styr prioriteringen efter fältdata och 75:e percentilen.
- Varför är INP svårare att klara än LCP och CLS?
- INP mäter varje interaktion under hela sessionen och rapporterar den värsta, till skillnad från engångsmått som LCP. En app kan ladda snabbt men ändå ha en blockerad huvudtråd vid klick på grund av tunga beräkningar. Det gör INP särskilt svårt för interaktionstunga appar byggda i React eller liknande ramverk med mycket klientsidesrendering.
- Hur lång tid tar det att se resultat av ett Core Web Vitals-arbete?
- Quick wins som bildoptimering och CLS-fixar syns ofta inom 2–4 veckor. Större strukturella insatser, som att flytta logik till servern eller bygga om render-kedjan, tar 8–16 veckor. Vi rekommenderar att alltid mäta en tydlig baseline innan arbetet startar så att förbättringen går att verifiera.
- Påverkar Core Web Vitals verkligen konvertering, inte bara SEO-ranking?
- Ja, och ofta mer än ranking gör. Vi har sett e-handelssajter höja konverteringen 10–15 procent genom att sänka LCP från 6 till 2 sekunder. Prestanda är en direkt mätare av användarupplevelse — en långsam sida tappar besökare i varje steg av tratten, oavsett var den rankar i Google.
Om författaren
SIAX Technologys teknikteam skriver guiderna utifrån verkliga leveranser inom molninfrastruktur, dataplattformar och AI-automation åt nordiska företag.
Fler artiklar av SIAX