Core Web Vitals optimering: så förbättrar du LCP, CLS och INP

Guide till Core Web Vitals optimering: mät och förbättra LCP, CLS och INP steg för steg på vanlig svenska. Mycket fixar du själv med gratisverktyg.

Din sida laddar färdigt på datorn på två sekunder, du är nöjd, och ändå klagar Google Search Console på “dålig” prestanda för Core Web Vitals. Förklaringen är att Google inte mäter din egen upplevelse på en snabb dator med fiber, utan en genomsnittlig besökares upplevelse på en medelmåttig mobil över 4G, och det är där de flesta sajter faller igenom. Den här guiden börjar precis i det glappet mellan vad du ser och vad dina besökare faktiskt får.

Core Web Vitals handlar inte om att jaga en grön siffra för dess egen skull, utan om att en besökare som hittar dig via Google ska se innehållet snabbt, slippa en layout som hoppar runt, och få en sida som svarar direkt när hon trycker. Lyckas du med det blir både besökarna och Google nöjdare, och den goda nyheten är att en stor del av jobbet går att göra själv med gratisverktyg så snart du vet vad du letar efter.

Vad Core Web Vitals är och varför de spelar roll

Core Web Vitals är Googles sätt att sätta siffror på något luddigt, nämligen känslan av att en sida är snabb och behaglig att använda. I stället för att mäta en enda teknisk parameter försöker måtten fånga tre olika delar av den upplevelse som besökaren faktiskt märker. Core Web Vitals är en delmängd av en bredare uppsättning signaler för page experience, men det är de tre kärnmåtten du bör fokusera på först innan du bryr dig om resten.

Poängen är att en sida kan vara tekniskt snabb i meningen att filerna hämtas fort och ändå kännas trög för en människa som använder den. Knappen som flyttar sig precis när du ska klicka, bilden som dyker upp och putar undan texten du läste, fördröjningen mellan tryck och reaktion: allt det är sådant som ett enkelt hastighetstest missar men som Core Web Vitals fångar in i sina siffror.

De tre måtten beskriver var sin sida av samma upplevelse, och det lönar sig att förstå skillnaden mellan dem innan du börjar optimera:

• LCP (Largest Contentful Paint) mäter hur snabbt det största synliga elementet ovanför mitten av skärmen ritas upp, oftast en hjältebild eller en rubrik, och ett bra värde ligger under 2,5 sekunder.
• CLS (Cumulative Layout Shift) mäter hur mycket synligt innehåll oväntat flyttar sig medan sidan laddar, och ett bra värde ligger under 0,1.
• INP (Interaction to Next Paint) mäter svarstiden från användarens första interaktion, till exempel ett klick, till att sidan svarar visuellt, och ett bra värde ligger under 200 millisekunder.
• TTFB och FCP är inte Core Web Vitals i sig men hänger tätt ihop med LCP och är värda att hålla ögonen på.
• TBT (Total Blocking Time) är ett labbmått som speglar samma underliggande problem som dålig INP.

INP ersatte det äldre måttet First Input Delay, som bara tittade på fördröjningen vid den allra första interaktionen. First Input Delay mäter bara en liten del av bilden, så Google gick över till INP som tittar på hela interaktionen genom hela besöket i stället för bara en punkt. Du kommer fortfarande se First Input Delay nämnas i äldre artiklar och i en och annan engelsk genomgång, men det är INP som gäller nu.

En sida som laddar snabbt men hoppar runt är som en bra restaurang där servitören slår omkull glaset på vägen ut: helheten avgör om besökaren stannar och kommer tillbaka, inte det snabbaste enskilda momentet.

Core Web Vitals samspelar med andra delar av Googles bredare bedömning, som att sidan fungerar på mobil och serveras säkert, men du ska inte överdramatisera deras vikt eftersom relevant innehåll fortfarande väger tyngst. Vill du sätta dig in i hur de här signalerna förhåller sig till resten av Googles trovärdighetsbedömning är vår ordlista om E-E-A-T en bra utgångspunkt, och innehållets relevans bygger du i sin tur med en genomtänkt innehållsstrategi som ger måtten något att avgöra mellan.

Så påverkar Core Web Vitals din SEO

Det här är frågan alla ställer, och det ärliga svaret är att de påverkar lagom mycket. Core Web Vitals är en bekräftad rankningssignal i SEO, men den fungerar mest som en avgörare mellan jämbördiga sidor snarare än som en raket. Har du tunt innehåll hjälper det inte att sidan laddar på en halv sekund, men har du starkt innehåll i nivå med en konkurrent kan en bättre upplevelse vara det som tippar över till din fördel.

Den verkliga vinsten är ofta indirekt och syns på flera ställen i din egen statistik snarare än bara i rankningen:

• Bättre upplevd prestanda ger i regel lägre studsfrekvens, eftersom färre besökare tröttnar och stänger fliken.
• Nöjda besökare stannar längre och bläddrar vidare, vilket Google i sin tur tenderar att tolka positivt.
• En snabb sida konverterar i regel bättre, vilket är poängen även helt bortsett från rankningseffekten.
• Konkurrenter med svagare prestanda blir lättare att passera när allt annat är lika starkt.
• Den verksamhet som tjänar mest är den med många besökare på svaga mobilnät, eftersom det är där dålig prestanda gör mest skada.

Vill du förstå hur du står dig mot dina rivaler på just det här är en strukturerad konkurrentanalys en bra start, eftersom du då ser om dina rivaler redan ligger i grönt eller om hela branschen släpar efter. Tävlar du dessutom om lokala sökningar märks prestandaskillnaden tydligt i mobilen, något vi går igenom i guiden om lokal SEO i Göteborg men som gäller lika mycket om du slåss om kunderna i Stockholm eller Västerås.

Verktygen du använder för att mäta

Innan du rör en enda rad kod måste du mäta, annars gissar du, och gissningar är dyra i både tid och pengar. Som tur är är de bästa verktygen gratis och tillgängliga direkt i webbläsaren utan att du behöver logga in eller skapa konton. Det här är verktygen du behöver för att se var du faktiskt står, och var och en fyller sin egen funktion.

PageSpeed Insights är förstahandsvalet för en enskild URL. Du klistrar in adressen och får tillbaka både labbdata, alltså ett simulerat test, och fältdata, alltså verklig besökardata om sidan har nog med trafik. Läs resultatet uppifrån och ner: fältdatan högst upp är det Google faktiskt bedömer, labbdatan under är till för felsökning. Tänk på följande när du läser rapporten:

• Ange en URL i taget och titta först på fältdatans LCP, CLS och INP innan du dyker ner i detaljerna.
• Notera om fältdata saknas, för då har sidan för lite trafik och du får luta dig mot labbdata.
• Läs diagnostiklistan längst ner, eftersom den pekar ut konkreta saker du kan förbättra i prioriterad ordning.
• Kör samma URL några gånger, då ser du hur mycket labbresultatet varierar mellan körningarna.

Google Search Console ger dig i stället fågelperspektivet över hela sajten. Rapporten för Core Web Vitals grupperar URL:er med samma problem så att du ser mönster över hela din sajt i stället för en sida i taget, och det sparar enormt med tid eftersom en fixad mall ofta fixar hundratals URL:er på en gång. Lighthouse körs lokalt i Chrome via DevTools och är ditt arbetsbordsverktyg medan du optimerar, eftersom det är repeterbart och bra för att se om en åtgärd hjälpte. Chrome User Experience Report, ofta förkortat Chrome UX Report eller CrUX, är källan till själva fältdatan. Chrome User Experience Report samlar anonymiserade mätningar från riktiga Chrome-användare som valt att dela sin data, och det är härifrån Google hämtar de siffror som faktiskt påverkar bedömningen.

En kort jämförelse av de fyra verktygen och vad de är bäst på:

• PageSpeed Insights är bäst för djupdyk i en enskild URL med både labb och fält i samma vy.
• Google Search Console är bäst för överblick och för att hitta mönster över hela sajten.
• Lighthouse är bäst medan du jobbar, eftersom du kan testa om direkt efter varje ändring.
• Chrome User Experience Report är bäst när du vill gräva i rådata från verkliga besökare.

Lita på fältdata för det stora beslutet och på labbdata för felsökningen. När de pekar åt olika håll är det fältet som har rätt om verkligheten, eftersom det är dina riktiga besökare som blir bedömda.

Så tolkar du resultaten rätt

Ett vanligt misstag är att stirra sig blind på en enda siffra utan att förstå vad den representerar. Utifrån din fältdata, inte ett enstaka test, fattar du besluten, eftersom ett labbtest kan visa rött bara för att just det testet råkade på en långsam stund medan fältdatan över tusen besökare visar grönt. Två saker är särskilt lätta att missa när du läser siffrorna.

Det första är skillnaden mellan fält och labb, som du redan stött på men som är värd att hålla rak hela vägen:

• Labbdata är ett kontrollerat test, repeterbart och bra för felsökning, men det är bara en ögonblicksbild.
• Fältdata är många riktiga besökare, bullrigt men sant, och det är den Google bedömer din sida på.
• Skiljer de sig åt litar du på fältet för beslutet och använder labbet för att hitta orsaken.

Det andra är att Google bedömer Core Web Vitals på 75:e percentilen, vilket betyder att 75 procent av din data, alltså dina besökare, ska ha en bra upplevelse. En enda väldigt långsam besökare drar inte ner snittet på samma sätt som ett medelvärde skulle göra, men en hel fjärdedel långsamma besökare gör det. Sikta därför på att den breda massan har det bra och inte bara genomsnittet, för det är massan som avgör om du hamnar i grönt.

Optimera LCP så att innehållet syns snabbt

Att optimera Largest Contentful Paint handlar om att få det viktigaste, oftast en bild eller en rubrik, att ritas upp så fort som möjligt. LCP påverkas i grunden av tre saker: hur snabbt servern svarar, hur snabbt webbläsaren upptäcker resursen, och hur snabbt resursen sedan hämtas och ritas upp på skärmen. Det första du bör titta på är TTFB (Time To First Byte), alltså tiden från att besökaren ber om sidan till att första byten kommer tillbaka, eftersom en seg TTFB försenar allt annat. FCP (First Contentful Paint), när de allra första pixlarna ritas, kommer strax efter och hänger ihop med samma orsaker.

På serversidan finns ofta de snabbaste vinsterna, och de kräver sällan att du rör innehållet:

• Använd en cache så att servern slipper bygga om sidan från grunden vid varje besök.
• Välj ett webbhotell som klarar din trafik utan att kvävas vid toppar.
• Sätt en CDN framför sajten så att innehållet serveras geografiskt närmare besökaren.
• Mät TTFB separat, eftersom en seg server gör all annan optimering meningslös.

Ett Content Delivery Network, ofta kallat CDN, lagrar kopior av dina filer på servrar runt om i världen, så att en besökare i New York hämtar från en server i USA i stället för från Sverige, vilket kapar restiden för datan. Content Delivery Networks är särskilt värdefulla om du har internationella besökare, men de sänker latensen även nationellt eftersom avståndet alltid kostar lite tid.

När servern väl är i ordning är det nästan alltid hjältebilden du behöver ta tag i, eftersom det ofta är den största enskilda filen ovanför mitten av skärmen:

• Servera bilden i ett modernt format som WebP eller AVIF i stället för tung JPEG.
• Komprimera så att filen blir liten utan synlig kvalitetsförlust.
• Ange korrekt bredd och höjd så att rätt storlek levereras till mobil.
• Förladda LCP-bilden så att webbläsaren hittar den tidigt i laddningen.
• Undvik att lazy-loada just den bild som är LCP, eftersom den tvärtom ska prioriteras.

Slutligen kan CSS och stora JavaScript-filer som laddas i sidhuvudet blockera renderingen tills de hämtats och körts. Du vill att den CSS som behövs för det synliga ovanför mitten levereras direkt och att resten skjuts upp, och att tunga script som inte behövs för första vyn laddas senare så att de inte står i vägen för LCP. Tar du ett bredare grepp om servertid och resurser går arbetet hand i hand med sidhastighetsoptimering i stort.

Optimera CLS så att layouten står stilla

Cumulative Layout Shift är ofta det enklaste måttet att förbättra och samtidigt det mest irriterande för besökaren när det är dåligt. Du känner igen problemet: du börjar läsa, en annons eller bild laddar in ovanför, och hela texten hoppar nedåt mitt i meningen. LCP, CLS och INP är de mätvärden som tillsammans beskriver upplevelsen, och CLS är just den som handlar om visuell stabilitet medan sidan byggs upp.

Det vanligaste tipset är också det viktigaste, nämligen att reservera plats för allt som laddar in, för anger du bredd och höjd på en bild vet webbläsaren hur mycket plats den ska hålla och inget hoppar när bilden väl kommer. Webbteckensnitt som laddar sent kan dessutom byta ut ett standardteckensnitt mot ditt valda och flytta texten, och en av de saker du lättast missar är just typsnittsbytet eftersom det inte syns på din egen snabba uppkoppling där typsnittet redan är cachat. Här är de åtgärder som tar hand om merparten av problemet:

• Sätt alltid width och height på bilder, eller använd CSS aspect-ratio för samma effekt.
• Reservera plats för annonser och inbäddningar med en container i fast storlek.
• Undvik att skjuta in banners högst upp efter att sidan redan börjat ritas.
• Förladda dina viktigaste typsnitt så att texten inte flyttar sig när de byts in.
• Välj en typsnittshantering som minimerar omflödet medan sidan laddar.

De återkommande bovarna bakom dålig CLS är förvånansvärt få till antalet, vilket är goda nyheter eftersom det betyder att du kan beta av dem systematiskt:

• Bilder utan angivna mått, så att webbläsaren inte vet hur mycket plats de tar.
• Annonser och iframes utan reserverad container i fast storlek.
• Innehåll som injiceras med JavaScript efter att sidan redan ritats upp.
• Typsnitt som byts ut sent under laddningen och knuffar texten.

Optimera INP så att sidan känns responsiv

INP (Interaction to Next Paint) mäter hur snabbt sidan svarar när besökaren gör något, som att klicka på en knapp, öppna en meny eller fylla i ett fält. CLS och INP hänger ihop som upplevelsemått, men INP handlar specifikt om svarstiden efter en handling som ett klick eller att trycka på skärmen, alltså hur levande sidan känns. Den vanligaste orsaken till dålig INP är för mycket JavaScript som blockerar huvudtråden, för när webbläsaren är upptagen med att köra script hinner den inte reagera på besökarens första interaktion direkt och då känns sidan trög. Total Blocking Time (TBT) är ett besläktat labbmått som fångar samma underliggande problem, nämligen att huvudtråden är blockerad.

De flesta INP-problem löser du genom att helt enkelt skicka mindre och smartare JavaScript till webbläsaren:

• Ta bort script du inte längre använder, eftersom varje kilobyte räknas på mobilen.
• Skjut upp JavaScript som inte behövs för den allra första interaktionen.
• Dela upp stora buntar så att webbläsaren slipper svälja allt på en gång.
• Granska tredjepartsskript, ads och spårningskoder som ofta är överraskande tunga.
• Mät INP på riktiga interaktioner, inte bara på själva sidladdningen.

Sidbyggare som Divi gör det enkelt att bygga vackra sidor men lägger ofta till mycket JavaScript och CSS, och det betyder inte att du måste byta men väl att du måste städa: avaktivera moduler du inte använder och håll antalet plugins nere. Innehåll som genereras dynamiskt på klienten kostar i regel mer än innehåll som levereras färdigt från servern, vilket är värt att tänka på när du väljer hur sidan ska byggas.

En optimeringsrunda steg för steg

Nu till det praktiska. Här är ordningen jag rekommenderar för en första genomgång, och tanken är att du jobbar uppifrån och ner, mäter innan och efter, och åtgärdar en sak i taget så att du faktiskt vet vad som gav effekt. Vill du ha ett enkelt sätt att hålla ordning bockar du av stegen nedan medan du går.

Det sista steget är det som kräver tålamod, eftersom fältdatan rör sig långsamt och bygger på ett rullande fönster av riktiga besök. Du får inte facit samma dag, utan först när tillräckligt många besökare hunnit uppleva den nya och snabbare sidan, och det är värt att påminna sig om när siffrorna inte rör sig lika fort som du hoppades.

Vanliga missförstånd om mätning och tolkning

Innan du ger dig på själva åtgärderna är det värt att reda ut några återkommande missförstånd så att du inte jagar fel siffra och slösar tid. Den här guiden återkommer gärna till temat att fältdata styr, och det är ett tema som tål att upprepas i just det här sammanhanget eftersom det är där så många går vilse. Två frågor dyker upp om och om igen:

• Varför skiljer sig labb och fält åt? Labbtestet körs en gång på en simulerad enhet och uppkoppling, medan fältet är tusen besökare med olika telefoner, nät och platser, så att de skiljer sig är väntat och inte ett fel i sig.
• Varför saknas fältdata för min sida? Chrome User Experience Report behöver tillräckligt många besök för att kunna rapportera, så har en URL för lite trafik visas ingen fältdata och du får luta dig mot labbdata och sajtens samlade siffror i stället.

Den röda tråden är att skillnaderna sällan är fel i sig, utan information om att din verklighet är mer varierad än ett enda test någonsin kan vara. Att förstå det sparar dig från att jaga gröna labbsiffror som ändå inte är de Google bryr sig om. Värt att hålla isär från det här är att prestandan inte påverkar indexering i sig, utan handlar om hur en redan registrerad sida upplevs.

Optimera särskilt på WordPress

Driver du en WordPress-sajt har du både en fördel och en risk. Fördelen är att mycket går att lösa med plugins utan att du behöver koda, medan risken är att samma plugins, om de staplas på varandra utan eftertanke, snabbt blir en del av själva problemet. Vill du ha en djupare genomgång av plattformen finns vår guide för SEO på WordPress som komplement till det här avsnittet.

Börja med cache och bildhantering, eftersom det är där de stora och enkla vinsterna brukar finnas:

• Installera en seriös cache-plugin och aktivera sidcache så att servern slipper bygga om sidan.
• Lägg till automatisk bildkomprimering och WebP-konvertering för att skära ner på filstorlekarna.
• Aktivera lazy loading för bilder under första vyn, men aldrig för själva LCP-bilden.

Håll därefter temat och dina plugins under kontroll, för det är ofta där prestandan smyger iväg utan att du märker det:

• Välj ett lätt tema, eller städa ett tungt tema som Divi noga genom att stänga av oanvända moduler.
• Avinstallera plugins du inte använder, eftersom de ofta laddar script även när de ligger inaktiva.
• Testa om efter varje större ändring så att du genast ser vilken effekt den fick.

Bilder, CDN och leverans

Bilder är den enskilt vanligaste orsaken till seg LCP, och leverans är den näst vanligaste, så reder du ut de två har du tagit hand om en stor del av jobbet på en gång. Ett Content Delivery Network framför sajten gör skillnad så fort du har besökare på avstånd från din server, och vinsten växer ju längre bort de sitter. Börja med formaten och storlekarna:

• Använd WebP eller AVIF i stället för tunga JPEG och PNG där det går.
• Servera olika storlekar till mobil och desktop med responsiva bilder.
• Komprimera hårt men kontrollera alltid att kvaliteten fortfarande håller.

Lägg sedan leveransen ovanpå, för ett Content Delivery Network avlastar din server och kortar avståndet till besökaren:

• Content Delivery Networks hanterar statiska filer och, hos vissa leverantörer, även hela sidcachen.
• Hör av dig till ditt webbhotell om du är osäker, eftersom många erbjuder ett CDN du inte aktiverat.
• Kontrollera om bildoptimering redan ingår i ditt CDN innan du betalar för en separat tjänst.

Tillsammans tar bildhantering och leverans hand om huvuddelen av en typisk sajts LCP-problem, och de är dessutom bland de minst riskabla ändringarna du kan göra eftersom de sällan rör innehåll eller funktion.

Mät kontinuerligt och inte bara en gång

Core Web Vitals är inte ett engångsprojekt, för varje gång du lägger till ett nytt plugin, byter tema eller publicerar en tung kampanjsida kan siffrorna röra sig åt fel håll. Bygg därför in mätning i din vanliga rutin så att du upptäcker tapp innan Google hinner göra det åt dig:

• Kontrollera Search Console-rapporten ungefär en gång i månaden för att fånga långsamma tapp.
• Testa nya mallar i Lighthouse innan de går live, medan det fortfarande är lätt att ändra.
• Håll ett extra öga på fältdatan veckorna efter större lanseringar och kampanjer.
• Spara dina mätvärden över tid så att du ser trender och inte bara enskilda ögonblicksbilder.

Det du inte mäter kan du inte förbättra, och det du mäter en gång och sedan glömmer förfaller långsamt tillbaka. Gör mätningen till en återkommande vana i stället för ett enstaka projekt, så håller resultatet över tid.

En realistisk prioriteringsordning

Du behöver inte göra allt på en gång, och du bör faktiskt inte ens försöka, utan prioritera efter förhållandet mellan effekt och ansträngning. Du bygger bättre resultat genom att ta de stora och enkla vinsterna först och spara finliret till sist, så att din tid hamnar där den gör mest nytta. En grov prioritering brukar se ut så här:

• Störst effekt, minst ansträngning: bildkomprimering, cache och bildmått som stoppar CLS.
• Stor effekt, mer arbete: CDN, uppskjuten JavaScript och en ordentlig städning av plugins.
• Finlir att spara till sist: förladdning av typsnitt, kritisk CSS och optimering av enskilda script.

Det här är platsen där det är som lättast att överarbeta, för en sida behöver inte vara perfekt utan bara bra nog för 75 procent av besökarna. Når du dit på dina viktigaste mallar har du redan gjort det som betyder mest, och de sista procentenheterna kostar ofta oproportionerligt mycket arbete i förhållande till vad de ger.

Så vet du när du är klar nog

Du är klar nog när dina viktigaste sidor visar grönt i fältdatan på alla tre måtten, och när du har en rutin för att fånga upp framtida tapp innan de hinner skada. Helt färdig blir du aldrig eftersom sajten lever och förändras, men du kan absolut nå en punkt där prestanda inte längre är det som håller dig tillbaka. Konkret betyder grönt i fältdatan följande:

• LCP under 2,5 sekunder i fältdatan på dina mest besökta mallar.
• CLS under 0,1, alltså ingen layout som hoppar märkbart medan sidan laddar.
• INP under 200 millisekunder, så att sidan svarar direkt på interaktion.

Når du dit är vinsten inte bara teoretisk, för besökaren får en sida som känns snabb och pålitlig, och du har byggt ett försprång som håller även när konkurrenterna kommer ikapp dig på innehållet.

Nästa steg

Börja smått och konkret genom att köra dina tre viktigaste sidor genom PageSpeed Insights idag, skriva ner LCP, CLS och INP, och ta den enklaste vinsten först. Är det bilder som drar ner siffrorna fixar du bilderna, och är det script börjar du skjuta upp dem. Vill du bredda greppet kring teknisk prestanda är vår guide om sidhastighetsoptimering en naturlig fortsättning, och funderar du på hur prestandan samspelar med att synas i AI-svar är vår ordlista om GEO en kort men nyttig vidareläsning. Kör en mätning, åtgärda en sak, mät om, och låt fältdatan visa vägen vidare.