Vad är Core Web Vitals och vad mäter värdena?
Core Web Vitals är tre mått på användarupplevelse: Largest Contentful Paint för laddning, Interaction to Next Paint för respons och Cumulative Layout Shift för visuell stabilitet. Tillsammans visar de olika typer av friktion. Inget av måtten beskriver ensamt sidans innehållskvalitet, tillgänglighet eller förmåga att hjälpa besökaren slutföra sin uppgift.
LCP beskriver när det största kvalificerade innehållselementet inom den synliga delen av sidan renderas. Ofta är det en huvudbild eller ett större textblock. INP fångar fördröjningen från användarinteraktioner till nästa bildruta. CLS summerar oväntade layoutförskjutningar enligt en sessionsfönstermodell, inte genom att okritiskt addera alla rörelser under hela besöket.
Utgå från ett verkligt användarflöde när ni tolkar värdena. En snabb artikel kan ändå ha en meny som reagerar långsamt, medan en butik kan ladda huvudbilden snabbt men flytta köpknappen när rekommendationer visas. Dokumentera därför både vilket mått som avviker och vilken uppgift besökaren försöker utföra. Förklara problemet som ett konkret hinder snarare än som en abstrakt röd markering i en rapport. Det gör felsökningen begriplig även för den som inte arbetar med webbutveckling.
Vilka gränsvärden gäller vid den 75:e percentilen?
Bra Core Web Vitals innebär LCP högst 2,5 sekunder, INP högst 200 millisekunder och CLS högst 0,1. Bedömningen görs vid den 75:e percentilen i fältdata, separat för mobil och dator. För en godkänd samlad bedömning behöver alla tre mått som ingår i bedömningen ligga inom sina gränser.
Den 75:e percentilen är inte ett medelvärde. Om LCP där är 2,5 sekunder har minst ungefär tre fjärdedelar av observationerna ett lika bra eller bättre värde. Enstaka snabba besök kan därför inte väga upp många långsamma på samma sätt som i ett genomsnitt. Granska även fördelningen när ni har tillgång till egen mätning.
Värden över de goda gränserna behöver förbättras. LCP över 4 sekunder, INP över 500 millisekunder och CLS över 0,25 räknas som dåliga; mellanrummen betecknas som förbättring behövs. Håll isär klassningen och den affärsmässiga prioriteringen. Ett problem strax utanför gränsen på ett viktigt beställningsflöde kan vara mer angeläget än ett sämre värde på en nästan oanvänd sida. Dokumentera enhet, mätperiod och datakälla tillsammans med värdet så att senare jämförelser verkligen avser samma sak.
Hur skiljer sig fältdata från laboratorietester?
Fältdata beskriver upplevelser från verkliga användare med varierande enheter, nätverk och beteenden. Laboratorietester kör en sida under valda, kontrollerade förutsättningar och används främst för diagnos. Ett grönt laboratorietest bevisar därför inte godkända Core Web Vitals i fält, och röda fältvärden försvinner inte genom en enskild snabb testkörning.
Chrome UX Report, CrUX, sammanställer data från en delmängd av kvalificerade Chrome-användare. PageSpeed Insights kan visa både denna fältdata och ett separat Lighthouse-test. Kontrollera om fältvyn gäller den specifika adressen eller hela ursprunget. Om adressdata saknas kan ursprungsdata ge sammanhang, men den får inte beskrivas som ett uppmätt resultat för just sidan.
Lighthouse kör normalt ingen komplett serie verkliga användarinteraktioner och ger därför inte ett direkt fältvärde för INP. Total Blocking Time kan vara diagnostiskt användbart, men är inte samma mått. Använd interaktionsspårning i utvecklarverktygen för menyer, filter och formulär. Om ni installerar egen realtidsmätning behöver implementation, dataskydd och urval dokumenteras. Egen mätning kan ge snabbare återkoppling och rikare segmentering, men behöver inte matcha CrUX eftersom populationer, perioder och mätvillkor kan skilja sig.
Hur hittar ni rätt sidor och en tillförlitlig baslinje?
Börja med representativa sidmallar, affärskritiska flöden och tillgänglig fältdata i stället för att enbart testa startsidan. Spara mätperiod, enhetstyp, verktyg och publicerad version. En användbar baslinje gör det möjligt att skilja en faktisk förbättring från variation som beror på testförhållanden, trafikmix eller förändrat innehåll på webbplatsen.
Välj exempelvis en tjänstesida, en innehållstung guide och en kategori med filtrering. För en butik behövs även produkt och köpflöde. Search Consoles rapport för Core Web Vitals grupperar liknande adresser, vilket hjälper er se mönster men inte ersätter granskning av varje teknisk mall. Säkerställ att ett exempel verkligen representerar sidorna ni planerar att förändra.
Kör laboratorietestet flera gånger med jämförbara inställningar och spara både resultat och spårning. Ange om besöket hade tom cache, om samtycke gavs och vilka externa komponenter som laddades. Testa sedan samma uppgift manuellt på mobil. En ändring som förbättrar laddning men gör att tangentbordsfokus försvinner är inte färdig. Baslinjen ska därför innehålla en kort funktionskontroll, inte bara tre prestandatal. Utse också en ansvarig person för att samla observationerna så att olika team inte arbetar utifrån motstridiga ögonblicksbilder.
Hur förbättrar ni LCP utan att dölja viktigt innehåll?
Förbättra LCP genom att hitta det faktiska LCP-elementet och undersöka väntan på serversvar, resursupptäckt, nedladdning och rendering. Åtgärden beror på vilken del som tar tid. Rätt bildformat hjälper inte mot långsam servergenerering, och en snabb server hjälper inte fullt ut om huvudbilden upptäcks sent av webbläsaren.
Kontrollera att en viktig huvudbild kan upptäckas tidigt och inte laddas först efter onödig JavaScript-körning. Undvik lazy loading för den bild som faktiskt är LCP-kandidat ovanför sidans vikning. Leverera rimliga bilddimensioner och moderna format där stödet passar. Använd responsiva bildkällor så att mobilen inte hämtar en skrivbordsbild som är mycket större än vad visningen kräver.
Granska därefter blockerande stilmallar, typsnitt och serverns svarstid. Cache kan hjälpa, men personligt innehåll och uppdateringskrav måste hanteras korrekt. Prioritera resurser försiktigt; om allt anges som viktigt får webbläsaren sämre vägledning. Verifiera vilken resurs som blev LCP efter ändringen, eftersom kandidaten kan skifta. Ta inte bort ett nödvändigt budskap eller göm huvudbilden enbart för att få ett bättre tal. Förändringen ska bevara sidans uppgift och kontrolleras i både mobil och större vy.
Hur förbättrar ni INP för menyer, filter och formulär?
Förbättra INP genom att mäta verkliga interaktioner och minska väntan före händelsehantering, arbetet i händelsehanteraren och tiden till nästa bildruta. Långa JavaScript-uppgifter, omfattande rendering och onödiga DOM-förändringar är vanliga orsaker. Utgå från den långsamma interaktionen, eftersom en mindre skriptfil inte automatiskt betyder att gränssnittet reagerar snabbare för användaren.
Spela in vad som händer när någon öppnar mobilmenyn, ändrar ett produktfilter eller skickar ett formulär. Kontrollera om huvudtråden redan är upptagen och om en liten handling utlöser omrendering av stora delar av sidan. Dela upp tungt arbete där det är möjligt och flytta lämpliga beräkningar från huvudtråden. Undvik upprepade mätningar och ändringar av layout i samma täta loop.
Visa tidig återkoppling utan att vilseleda användaren om resultatet. En knapp kan markera att en förfrågan behandlas, men får inte visa lyckat köp innan servern har bekräftat det. Granska även tredjepartskod för chatt, analys och personalisering. INP är ett mått över sidbesökets interaktioner, inte bara över det första klicket. Prova därför även ett längre besök där användaren filtrerar, öppnar dialoger och återvänder till tidigare steg innan ni bedömer åtgärden som klar.
Hur minskar ni CLS när innehåll laddas i efterhand?
Minska CLS genom att reservera utrymme för bilder, annonser, inbäddningar och annat innehåll innan det visas. Undvik att oväntat skjuta undan sådant besökaren redan läser eller försöker använda. Undersök också typsnittsbyten och dynamiska komponenter, eftersom en stabil första skärmbild inte garanterar stabilitet under resten av besöket på sidan.
Ange bilddimensioner eller ett korrekt bildförhållande så att webbläsaren kan skapa plats tidigt. För externa moduler behövs en reserverad yta som fungerar vid olika skärmbredder. En alltför liten platshållare skjuter ändå ned innehållet när modulen blir större. En alltför stor yta kan ge onödig tomhet, så testa flera verkliga innehållsvarianter i stället för enbart ett idealiskt exempel.
Följ förskjutningar i webbläsarens prestandaspårning och kontrollera vilket innehåll som orsakar dem, inte bara vilka element som flyttas. Vissa förskjutningar nära en användarinteraktion undantas enligt mätreglerna, men det innebär inte att alla klickutlösta rörelser är oproblematiska. Testa samtyckesdialoger, felmeddelanden och expanderbara sektioner. Använd gärna transformering för lämpliga animationer, men verifiera också fokus och läsordning. Ett lågt CLS-värde får inte bli en ursäkt för en dialog som täcker innehåll eller hindrar besökaren från att fortsätta.
Hur prioriterar ni åtgärder mellan teknik och affär?
Prioritera åtgärder efter användarpåverkan, berörda sidors betydelse, problemets omfattning och genomföranderisk. Samla varje förslag med observation, tänkbar orsak, ansvarig och verifieringsmetod. Börja gärna med ett tydligt problem i en delad mall, eftersom samma rättning då kan hjälpa många viktiga sidor utan att varje adress behöver byggas om separat.
Skilj mellan säker observation och hypotes. Att en chattwidget laddar mycket kod betyder inte i sig att den orsakar den långsamma interaktionen. Jämför kontrollerat med och utan komponenten och kontrollera spårningen. Om verktyget behövs för försäljning kan senare initiering eller en lättare lösning vara bättre än att avveckla funktionen helt. Beslutet behöver både tekniskt och verksamhetsmässigt underlag.
Gör arbetsordern konkret: vilken mall berörs, vilket beteende ska bevaras och hur ska förbättringen kontrolleras? Notera beroenden till leverantörer och krav på samtycke. Undvik löften om ett visst trafiklyft eller ett bestämt antal positioner. Det ni kan avtala om är undersökning, implementation, testning och uppföljning. Avsätt även tid för återställning om en ändring försämrar köp, formulär eller tillgänglighet. En förbättring måste fungera i den publicerade tjänsten, inte bara i ett isolerat testfall.
Hur verifierar ni förbättringen efter publicering?
Verifiera först att ändringen finns i produktion och förbättrar samma testfall utan funktionsfel. Följ därefter fältdata över en tillräcklig period och jämför likvärdiga segment. CrUX bygger normalt på ett rullande fönster om 28 dagar, så en lyckad publicering ger inte omedelbart ett helt nytt fältresultat i rapporterna.
Kontrollera att cache och distributionsnät levererar den nya versionen. Kör om de sparade testerna och jämför resurskedja, långa uppgifter och layoutförskjutningar. Om ni har egen användarmätning kan en versionsmarkör hjälpa till att skilja nya besök från gamla. Små datamängder eller förändrad trafikmix behöver redovisas som osäkerhet, inte döljas bakom en exakt procentsats med svagt underlag.
Följ också felrapportering, formulärslutförande och andra relevanta verksamhetsmått. Om konverteringen förändras samtidigt går det inte automatiskt att tillskriva effekten prestanda, eftersom kampanjer, priser och besökarnas sammansättning kan ha ändrats. Spara en kort logg med datum, hypotes, genomförd ändring och observerat resultat. Bestäm när ni tar nästa beslut och vad som krävs för att återställa förändringen. På så sätt blir uppföljningen en del av leveransen och inte något som glöms när verktygets första indikator blir grön.
Hur hör Core Web Vitals ihop med SEO och löpande ansvar?
Core Web Vitals ingår i Googles bedömning av sidupplevelse, men bra värden garanterar inte högre placeringar. Relevans, innehåll och andra signaler spelar också roll. Behandla därför prestanda som en del av teknisk kvalitet och användbarhet, tillsammans med indexerbarhet, tillgänglighet och innehåll som faktiskt besvarar besökarens fråga på sidan.
En snabb sida utan ett relevant svar löser inte sökbehovet. En långsam sida med viktigt innehåll kan samtidigt ha tydliga förbättringsbehov även om den redan syns i sökresultaten. Håll därför rapporteringen uppdelad: tekniska värden visar upplevelse, Search Console visar söksynlighet och verksamhetssystemet visar vad besöken leder till. Samband mellan dessa serier är underlag för undersökning, inte ett bevis på en enda orsak.
Utse en ägare för prestanda och kontrollera förändringar när nya kampanjmoduler, typsnitt eller mätverktyg införs. Sätt överenskomna resursbudgetar som passar era mallar, men följ även verklig användarupplevelse eftersom filstorlek inte fångar allt. Dokumentera källor för definitionerna, exempelvis web.dev och Google Search Centrals vägledning om sidupplevelse. Revidera arbetsrutinen när webbplatsens teknik eller trafik förändras. Det skapar ett förvaltningsbart arbete där varje ny funktion bedöms utifrån både nytta och kostnad för användaren.
Vill ni ha hjälp att prioritera? Vår SEO-byrå kopplar sökmotoroptimering till er affär.