Hur förbättrar man Core Web Vitals
Core Web Vitals är Googles mätvärden för hur en sida upplevs av besökaren: hur snabbt innehållet laddas, hur snabbt sidan reagerar och hur stabil layouten är. I den här guiden går vi igenom konkreta steg och mätmetoder som hjälper dig att förbättra LCP, INP och CLS.
Vad är Core Web Vitals och varför är de viktiga?
Core Web Vitals består av tre mätvärden: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) och Cumulative Layout Shift (CLS). Enligt Googles dokumentation på web.dev bör LCP vara högst 2,5 sekunder, INP högst 200 millisekunder och CLS högst 0,1. INP ersatte First Input Delay (FID) som Core Web Vital den 12 mars 2024 (web.dev).
LCP mäter hur snabbt det största synliga elementet laddas. INP bedömer sidans svarstid genom att titta på alla klick, tryck och tangentbordsinteraktioner under ett besök; det slutliga värdet är den längsta interaktionen som observerats, med outliers borträknade (web.dev). CLS kvantifierar oväntade layoutförskjutningar under sidladdning.
Google rekommenderar att sajtägare uppnår bra Core Web Vitals, och skriver att detta tillsammans med andra delar av sidupplevelsen stämmer med vad deras rankingsystem försöker belöna (Google Search Central). Förbättringar i dessa mått gör också sidan mer användbar för besökarna, vilket i förlängningen kan påverka konverteringen.
Mätning av Core Web Vitals med Googles verktyg
För att kunna förbättra måste du först veta var du står. Googles PageSpeed Insights, Lighthouse i Chrome DevTools och Search Console erbjuder alla rapporter som visar fältdata och labbdata. Titta på både mobila och skrivbordsresultat. Google rekommenderar att du mäter vid 75:e percentilen av sidvisningarna, uppdelat på mobil och desktop (web.dev).
När du kör ett test i PageSpeed Insights får du ett resultat samt konkreta förslag. Ett högt LCP kan till exempel utlösa rekommendationen att optimera stora bilder eller att använda en mer effektiv cache-policy. Det är viktigt att notera att fältdata (som samlas in från riktiga användare) kan skilja sig från labbdata, särskilt om din publik har varierande nätverksförhållanden.
Ett praktiskt tips är att ställa in en månatlig automatisk rapport via Looker Studio (tidigare Google Data Studio) som hämtar data från Search Console. På så sätt får du en kontinuerlig överblick och kan snabbt upptäcka regressioner efter en uppdatering eller ett nytt innehållsblock.
Optimera Largest Contentful Paint (LCP)
LCP påverkas främst av hur snabbt det största synliga elementet, ofta en hero-bild, en video eller ett stort textblock, kan laddas. För att förbättra LCP bör du fokusera på fyra områden: serverresponsstid, resursleverans, bildoptimering och kritisk CSS.
En snabb server är grundläggande. En hög serversvarstid (TTFB, Time to First Byte) gör det svårt att få ett bra LCP, eftersom allt annat väntar på att första svaret kommer. Delad hosting kan bli en flaskhals; en server med bättre konfiguration, cache och rätt placering kan ge en tydlig skillnad.
Bildoptimering är ofta den största vinsten. Använd moderna format som WebP eller AVIF, komprimera bilderna utan synlig kvalitetsförlust och leverera rätt storlek för varje skärm. Ladda inte den största bilden med lazy loading om den syns direkt ovanför vecket.
För att säkerställa att kritisk CSS laddas först kan du lägga den CSS som behövs för att rendera innehållet ovanför vecket direkt i sidan och skjuta upp resterande stilark via rel="preload" eller asynkron laddning. Verktyg som Critical eller PurgeCSS hjälper till att extrahera endast nödvändiga regler.
Förbättra Interaction to Next Paint (INP)
INP ersatte First Input Delay (FID) som Core Web Vital den 12 mars 2024 (web.dev). Medan FID bara mätte fördröjningen före den första interaktionen, bedömer INP svarstiden för alla interaktioner under besöket. Höga INP-värden orsakas ofta av JavaScript som blockerar webbläsarens huvudtråd. Enligt web.dev:s guide för att optimera INP handlar förbättringarna bland annat om att göra så lite arbete som möjligt i event callbacks, dela upp arbetet så att det inte blir en lång uppgift (long task) som blockerar huvudtråden och minska fördröjningen innan callbacks börjar köras (input delay). För tung beräkning kan du även flytta JavaScript till web workers.
En konkret åtgärd är att skjuta upp icke-kritisk JavaScript med attributet defer eller async. Ett analysverktyg som laddas i sidans huvud kan till exempel laddas asynkront efter att huvudinnehållet är renderat.
En annan metod är att dela upp stora JavaScript-paket med kodsplittning. Verktyg som Webpack eller Rollup kan skapa separata chunkar för olika vägar eller funktioner, så att endast nödvändig kod laddas för den aktuella vyn.
Om du använder många tredjepartsbibliotek, överväg att ersätta dem med lättare alternativ eller att ladda dem endast när de verkligen behövs. Till exempel kan ett tungt kartbibliotek ersättas med en statisk bild plus en länk till en interaktiv karta som laddas vid användarinteraktion.
Minska Cumulative Layout Shift (CLS)
CLS uppstår när synliga element förändrar position under sidladdning, vilket kan vara frustrerande för besökaren. Vanliga orsaker är bilder utan angivna dimensioner, dynamiskt infogat innehåll och typsnitt som orsakar FOIT (Flash of Invisible Text) eller FOUT (Flash of Unstyled Text). För att hålla CLS under 0,1 bör du specificera storlek på alla media, reservera utrymme för dynamiskt innehåll och använda font-display: swap för webbtypsnitt.
Ett enkelt exempel: om banner-bilder saknar bredd och höjd i HTML flyttar sig texten nedåt varje gång en bild dyker upp. Genom att lägga till width och height på varje bild reserverar webbläsaren plats i förväg.
För dynamiskt innehåll som annonser eller widgetar kan du reservera ett fast utrymme med hjälp av en placeholder-div som har samma dimensioner som det förväntade elementet. Detta förhindrar att layouten flyttar sig när innehållet laddas in.
Typsnittsrelaterade layoutförskjutningar kan minskas genom att ladda webbtypsnitt med font-display: swap och att använda link rel="preload" för de typsnittsfiler som behövs ovanför vecket.
Tekniska åtgärder på servernivå
Förutom frontend-optimeringar kan du påverka Core Web Vitals genom att justera serverinställningar och infrastruktur. En snabbare server svarar snabbare på förfrågningar, vilket direkt förbättrar TTFB och därmed LCP. Dessutom kan du utnyttja caching, komprimering och HTTP/2 för att minska latens.
Aktivera Gzip eller Brotli-komprimering på servern. Komprimering minskar den överförda datamängden för HTML, CSS och JavaScript och kan förbättra laddningstiden, särskilt på långsamma anslutningar.
Använd HTTP/2 eller HTTP/3 för att möjliggöra multiplexning av flera förfrågningar över en enda anslutning, så att kritiska resurser som CSS och JavaScript kan laddas parallellt. Kontrollera med din leverantör vilket protokoll som är aktiverat.
Implementera en effektiv cache-policy. För statiska tillgångar kan du sätta Cache-Control: max-age=31536000, immutable vilket låter webbläsaren hålla filerna i ett år utan att behöva validera dem igen. För dynamiskt innehåll kan du använda stale-while-revalidate för att leverera en cachad version samtidigt som du hämtar en färsk version i bakgrunden.
Om du har möjlighet, överväg att placera din infrastruktur närmare din huvudsakliga målgrupp. Kortare avstånd minskar nätverksfördröjningen, vilket påverkar TTFB och LCP.
Använda CDN och bildoptimering
En Content Delivery Network (CDN) kopplar ditt innehåll till servrar över hela världen så att användaren hämtar filer från en nod som är geografiskt nära. Detta minskar latens och kan förbättra LCP. Välj en CDN med nodplatser nära din målgrupp.
Prisbilden för CDN-tjänster varierar mellan leverantörer och beror på trafikvolym och funktioner. Jämför aktuella villkor hos leverantörerna.
Bildoptimering i kombination med en CDN kan ge stora vinster. Många CDN-leverantörer har inbyggda funktioner för automatisk formatkonvertering (till exempel WebP eller AVIF) och responsiv beskärning baserat på enhetens skärmstorlek. Genom att aktivera dessa funktioner slipper du hantera flera versioner av varje bild manuellt.
Övervakning och kontinuerlig förbättring
Att förbättra Core Web Vitals är ingen engångsinsats utan ett kontinuerligt arbete. Efter att du har implementerat åtgärder behöver du följa upp resultaten regelbundet och justera vid behov. Använd både labbdata (för att testa nya ändringar) och fältdata (för att se hur riktiga användare upplever sidan).
Följ Core Web Vitals-rapporten i Search Console, som visar hur dina sidor presterar. Använd också Web Vitals-extensionen för Chrome eller biblioteket web-vitals för att samla in egna mätdata direkt från din sajt. Det gör det möjligt att koppla prestanda till affärsmått som konverteringsgrad eller avvisningsfrekvens.
Slutligen, dokumentera alla ändringar och deras effekt i en enkel ändringslogg. Det gör det lättare att återställa en åtgärd om den skulle ha oönskade sidoeffekter och hjälper nya teammedlemmar att förstå varför vissa beslut fattades.
Vad är ett realistiskt mål för LCP på en företagssida?
Googles riktvärde är att LCP ska inträffa inom 2,5 sekunder, mätt vid 75:e percentilen av sidvisningarna (web.dev). Hur nära du kan komma beror på bilder, serverrespons och kritisk CSS.
Påverkar förbättrad CLS direkt min sökmotorranking?
CLS är en av de tre Core Web Vitals. Google skriver att bra Core Web Vitals, tillsammans med övriga delar av sidupplevelsen, stämmer med vad deras rankingsystem försöker belöna, och att sajtägare inte bör fokusera på bara en eller två aspekter av sidupplevelsen (Google Search Central). Förbättrad CLS ger i första hand en bättre upplevelse för besökarna; en högre placering kan inte garanteras.
Om du vill ta ditt arbete med Core Web Vitals till nästa nivå erbjuder Searchboost AI-driven SEO med automatisk optimering varje vecka. Vi analyserar din sajt, identifierar flaskhalsar och hjälper dig att förbättra LCP, INP och CLS.