Neuraweb

En kund vidarebefordrade nyligen ett mejl från Google Search Console med ämnesraden "Problem med Core Web Vitals upptäckta" och en enda rad text: "Är det här allvarligt? Ska jag oroa mig?" Det är en fråga vi får ofta, och den är helt rimlig. Det korta svaret är nej, du behöver inte gå i panik – men du bör inte heller strunta i det, för Core Web Vitals ligger precis i skärningspunkten mellan två saker du faktiskt bryr dig om: om besökare stannar kvar tillräckligt länge för att köpa något, och om Google överhuvudtaget visar din sida för dem som söker efter det du säljer.

Core Web Vitals är tre specifika, mätbara signaler som Google använder för att bedöma hur en sida känns att använda – inte hur den ser ut på en skärmdump, utan hur den beter sig i händerna på en riktig besökare. De ingår i en bredare uppsättning "sidupplevelse-signaler" som Google väger in i sökrankningen, och helt oberoende av SEO är de dessutom ett genuint användbart diagnosverktyg för att förstå varför besökare studsar innan de konverterar. Den här guiden går igenom varje mått i klartext, vad som orsakar dåliga resultat i praktiken, hur du kollar dina egna siffror, och vad du faktiskt bör be en utvecklare åtgärda – ungefär i den ordning det ger mest effekt.

Vad Core Web Vitals faktiskt mäter

Det handlar om tre mått, och vart och ett svarar på en egen fråga om besökarens upplevelse:

Largest Contentful Paint (LCP) – hur lång tid det tar innan det största synliga elementet på skärmen (oftast en hero-bild, en banner eller ett större textblock) är färdigladdat. Frågan den besvarar är: "Hur länge stirrade jag på en tom eller halvladdad sida innan jag såg huvudinnehållet?"
Interaction to Next Paint (INP) – hur lång tid sidan tar på sig att synligt reagera efter att någon klickar på en knapp, öppnar en meny eller fyller i ett formulärfält. Frågan den besvarar är: "När jag försökte göra något, svarade sidan direkt, eller kändes det som att den hakade upp sig?"
Cumulative Layout Shift (CLS) – hur mycket innehållet på sidan oväntat hoppar runt medan den laddas. Frågan den besvarar är: "Låg sidan still, eller flyttade sig en knapp precis när jag skulle trycka på den?"

En notering om INP: om du läst om Core Web Vitals tidigare och minns ett mått som hette First Input Delay (FID), är det just det INP ersatte som officiellt Core Web Vital-mått i mars 2024. FID mätte bara fördröjningen innan webbläsaren började hantera det allra första klicket eller tappet på en sida. INP är strängare och mer heltäckande – det spårar responsivitet för varje interaktion under hela besöket, inte bara den första, vilket gör det till ett betydligt bättre mått på om en sida känns trög eller hackig.

Vad "bra" betyder för respektive mått

Google publicerar ungefärliga tröskelvärden för varje mått, uppmätta vid 75:e percentilen av verklig besökstrafik (det vill säga: minst 75 % av besöken på din sida behöver hamna i det "bra" spannet för att sidan ska godkännas):

Mått	Bra	Behöver förbättras	Dåligt
LCP (laddningstid)	2,5 sekunder eller mindre	2,5–4 sekunder	Över 4 sekunder
INP (responsivitet)	200 millisekunder eller mindre	200–500 ms	Över 500 ms
CLS (visuell stabilitet)	0,1 eller lägre	0,1–0,25	Över 0,25

CLS är ett enhetslöst värde baserat på hur mycket synligt innehåll som flyttar sig och hur långt, inte en tidsmätning – ett värde på 0,1 eller lägre betyder att förskjutningarna är så små att de flesta besökare inte ens märker dem.

Varför det handlar om mer än en teknisk bock i en ruta

Det är lätt att se Core Web Vitals som en SEO-syssla – något man fixar för att Google säger åt en att göra det. Det synsättet underskattar den faktiska affärsnyttan. De här tre måtten är Googles försök att sätta siffror på något varje företagare redan förstår intuitivt: långsamma, hoppiga, tröga webbplatser tappar kunder. En besökare som landar på en produktsida och stirrar på en tom skärm i fyra sekunder har redan fingret på tillbaka-knappen. En besökare som trycker på "Lägg i kundvagn" och inget händer på en hel sekund trycker ofta igen, eller ger upp och lämnar sidan i tron att den är trasig. En besökare som är på väg att trycka på "Till kassan" och plötsligt får knappen att hoppa längre ner för att en annons eller bild just blev klar att ladda kan råka trycka helt fel – och det är inte bara irriterande UX, det är en förlorad affär och på vissa sidor även ett tillgänglighetsproblem.

På SEO-sidan är Core Web Vitals en av flera rankningssignaler som Google väger in under det man kallar "sidupplevelse". De trollar inte bort en konkurrent med betydligt bättre innehåll eller fler bakåtlänkar på egen hand, men bland sidor med liknande relevans och kvalitet är bättre Core Web Vitals-resultat en verklig knivig fördel – och Google har varit tydliga med att den vägningen inte försvinner. Kombinerat med den direkta effekten på konvertering gör det Core Web Vitals till ett av de få tekniska måtten som faktiskt förtjänar en egen post i webbplatsbudgeten, snarare än att hamna längst ner på en "någon gång"-lista.

Vanliga orsaker till dåliga resultat i verkligheten

I vårt arbete med att granska webbplatser åt små och medelstora företag är orsakerna ganska förutsägbara, och de återkommer i nästan alla branscher.

Varför LCP blir långsamt

Dåligt optimerade hero-bilder. Det här är den absolut vanligaste orsaken vi ser. En vacker bild på 6 MB rakt från marknadsavdelningens kamera, uppladdad utan komprimering eller storleksanpassning, placerad högst upp på startsidan. Webbläsaren måste ladda ner hela filen innan den kan rita upp den.
Fel bildformat. Äldre format som JPEG och PNG är mycket större än moderna format som WebP eller AVIF, för samma visuella kvalitet.
Långsam serversvarstid. Billigt eller överbelastat webbhotell, eller en sida som måste fråga en trög databas innan den ens kan börja skicka HTML, fördröjer allt som kommer efteråt.
Renderingsblockerande resurser. CSS- eller JavaScript-filer som webbläsaren måste ladda ner och tolka innan den kan visa något alls, även om koden inte behövs för det synliga innehållet ännu.
Inget CDN (content delivery network). Om servern finns på en plats och besökaren på en annan kontinent, ger det rena fysiska avståndet i sig en märkbar fördröjning.

Varför INP blir långsamt

Tung JavaScript. Stora, dåligt optimerade skript som körs vid varje sidladdning – ofta från sidbyggare, animationsbibliotek eller uppsvällda teman – håller webbläsarens huvudtråd upptagen, så att den inte kan svara på klick direkt.
För många tredjepartsskript. Det här är den stora boven för marknadsföringstunga sajter: analysverktyg, chattwidgetar, annonspixlar, A/B-testverktyg, heatmap-spårare, inbäddade sociala medier-flöden. Varje skript konkurrerar om samma bearbetningstråd, och vi har sett sajter köra femton eller fler samtidigt, där knappt någon längre minns varför de en gång lades till.
Stora, dåligt optimerade händelsehanterare. Egen kod som gör alldeles för mycket arbete varje gång någon klickar på något, till exempel genom att rita om en hel sektion av sidan för en liten UI-ändring.
Onödigt komplex DOM. Sidor med orimligt många nästlade HTML-element gör alla beräkningar i webbläsaren långsammare, inklusive de som utlöses av en interaktion.

Varför CLS blir högt

Bilder och annonser utan reserverat utrymme. Om webbläsaren inte känner till en bilds bredd och höjd i förväg ritar den upp texten runtomkring först, och skjuter sedan ner allt när bilden väl kommer på plats. Annonsplatser är särskilt problematiska eftersom annonsens storlek ofta inte är känd förrän den laddats.
Webbteckensnitt som orsakar textomflöde. Anpassade typsnitt som laddas in efter att sidans reserv-typsnitt redan ritats upp kan ge ett synligt "hopp" där texten flödar om till en annan storlek eller ett annat antal rader när det riktiga typsnittet väl byts in.
Dynamiskt inklistrat innehåll. Kakbanners, kampanjrader eller "prenumerera"-popuper som knuffar ner innehållet efter att sidan redan lagt sig till ro.
Animationer som använder fel CSS-egenskaper. Att animera egenskaper som påverkar layouten, istället för sådana webbläsaren kan hantera billigare, ger synliga hack när element ändrar storlek under animationen.

Så kollar du dina egna siffror

Du behöver varken specialverktyg eller en utvecklare på stå-by för att få en första bild av läget. Två gratisverktyg, båda från Google, täcker nästan allt:

Google PageSpeed Insights (pagespeed.web.dev) – klistra in vilken URL som helst och verktyget ger dig både labbdata (en simulerad testkörning) och, om sidan får tillräckligt med trafik, fältdata från riktiga besökare de senaste 28 dagarna. Det listar också konkreta problem det hittat, som "Anpassa bildstorlek korrekt" eller "Minska oanvänd JavaScript", tillsammans med en uppskattning av vad det kostar dig.
Core Web Vitals-rapporten i Google Search Console – om du har Search Console kopplat till din domän (och om du inte har det är detta i sig ett skäl att sätta upp det) grupperar rapporten dina faktiska sidor efter URL-mönster och visar hur många som är "Bra", "Behöver förbättras" eller "Dåliga" för respektive mått, baserat på riktig besöksdata snarare än en simulering. Det är det närmaste du kommer det Google själv ser när det bedömer din sajt.

En praktisk vana: kolla PageSpeed Insights för startsidan och dina två eller tre mest trafikerade sidor (oftast en central produkt- eller tjänstesida) med några månaders mellanrum, och håll ett öga på trenderna i Search Console-rapporten efter varje omdesign, temauppdatering eller ny plugin/app-installation – det är just de tillfällena resultaten oftast tyst blir sämre.

Vad du faktiskt ska ta med till en utvecklare

Du behöver inte bli prestandaingenjör för att lösa det här – det är specialiserat och ofta petigt arbete, och egna DIY-försök (att installera fem olika "hastighets"-plugins på en WordPress-sajt, till exempel) gör tyvärr ofta saken värre genom att lägga ännu fler skript ovanpå problemet. Det som är värdefullt är att veta tillräckligt för att kunna föra ett fokuserat samtal och prioritera rätt. Här är ungefär i vilken ordning vi själva skulle ta oss an det, sorterat efter typisk effekt i förhållande till insats:

Komprimera och storleksanpassa bilder, och byt till moderna format. Oftast den åtgärd som ger mest effekt för minst risk, särskilt för LCP. Den här punkten ensam har löst majoriteten av de LCP-problem vi diagnostiserat.
Granska tredjepartsskripten och ta bort det som inte gör nytta. Fråga specifikt: vilka analysverktyg, chattwidgetar och marknadsföringspixlar är faktiskt installerade, och fyller var och en fortfarande ett syfte? Det är vanligt att hitta dubbletter av analysverktyg eller ett övergivet A/B-testskript som fortfarande laddas in på varenda sida.
Reservera utrymme för bilder och annonser. En utvecklare kan lägga till explicita bredd/höjd-attribut eller CSS-regler för aspect-ratio, så att webbläsaren avsätter utrymme innan innehållet anländer – oftast en snabb, lågrisk-åtgärd för CLS.
Se över hur webbteckensnitt laddas. Att använda systemtypsnitt, förladda kritiska typsnitt, eller använda CSS-egenskapen font-display: swap kan eliminera det mesta av typsnittsrelaterade layoutförskjutningar och flimmer.
Skjut upp eller lazy-loada icke-kritisk JavaScript. Skript som inte behövs för den första vyn (chattwidgetar, interaktiva element längre ner på sidan) kan laddas in efter huvudinnehållet, så att de inte konkurrerar om webbläsarens uppmärksamhet under de där kritiska första sekunderna.
Utvärdera webbhotell och cachning. Om serversvarstiden är en återkommande flaskhals kan bättre webbhotell, server-side-cachning eller ett CDN hjälpa på hela sajten samtidigt, istället för en åtgärd i taget.
Fundera på om själva plattformen håller er tillbaka. Om en sajt är byggd på en tung sidbyggare, ett föråldrat tema eller år av ihopsamlade plugins, når stegvisa fixar förr eller senare en punkt av avtagande avkastning – och en mer grundlig ombyggnad blir då det mer kostnadseffektiva alternativet.

Den sista punkten förtjänar ett extra ögonblicks eftertanke. Vi har haft uppdrag som började som en enkel fråga om "kan ni fixa vår sidhastighet" och slutade i ett bredare samtal om sajtens grundläggande uppbyggnad, eftersom själva temat genererade så uppsvälld kod att ingen mängd bildkomprimering fullt ut kunde kompensera för det. Om du redan misstänker att er sajts problem sträcker sig djupare än Core Web Vitals, går vår artikel om tio tecken på att er hemsida behöver en redesign igenom de bredare varningssignalerna, inklusive hur långsam sidhastighet ofta dyker upp tillsammans med föråldrad design och dålig mobilanpassning.

Ett realistiskt sätt att se på det hela

Core Web Vitals är inget prov man antingen klarar med glans eller stryker rejält i. De är ett diagnosverktyg, och som med de flesta diagnosverktyg är målet stadig förbättring, inte perfektion. En sajt som går från "Dåligt" till "Behöver förbättras" på LCP genom att komprimera sina hero-bilder har redan fångat merparten av den praktiska nyttan, både i besökarupplevelse och i vad det nu finns för rankningsfördel att hämta. Att jaga de sista tiondelarna av en sekund mot teoretisk perfektion är sällan värt ingenjörsarbetet för en typisk småföretagssajt – den energin gör oftast mer nytta i innehåll, erbjudanden och konverteringsflöden.

Det som är värt att göra är att kolla dina siffror nu, förstå ungefär varför de ser ut som de gör, och betrakta varje ny omdesign, plugin eller marknadsföringsskript som något som kan flytta de siffrorna åt endera hållet. Core Web Vitals belönar samma disciplin som gör att en webbplats fungerar bra för riktiga kunder: håll det slimmat, ladda bara det som behövs, och se till att sidan beter sig som besökaren förväntar sig i samma ögonblick de rör vid den.

Om en rapport från PageSpeed Insights eller ett mejl från Search Console har fått dig att undra hur er sajt egentligen ligger till, eller vad en åtgärd skulle innebära i praktiken, ingår en fullständig prestandagranskning i vår tjänst för webbdesign och omdesign. Hör gärna av dig så kontaktar vi dig och går igenom vad vi hittar, i klartext, med en tydlig bild av vad som är värt att fixa och vad som inte är det.

Nyhetsrum

Core Web Vitals förklarat: en praktisk guide för företagare