När en besökare klickar sig in på din webbplats tär varje sekund framför en vit skärm lite till på tålamodet. Ju senare sidans huvudinnehåll dyker upp, alltså den stora rubriken, hjältebilden eller textblocket som får användaren att tänka "okej, nu har sidan laddats", desto större är risken att personen lämnar. Det är just den här upplevelsen som måttet Largest Contentful Paint, eller LCP för kort, sätter siffror på. Arbete med LCP-förbättring är ett av de mest kritiska ämnena inom modern webbprestanda, eftersom detta mått direkt påverkar både den hastighet som användaren upplever och det värde som sökmotorerna tillskriver din sida.
LCP mäter när det största synliga innehållselementet i visningsområdet har målats färdigt. Det elementet är oftast en stor bild, en bakgrundsbild, en posterbild från en video eller ett brett textblock. För användaren är det här ögonblicket då "det riktiga innehållet kom". Därför är LCP en intuitiv och kraftfull indikator som sammanfattar en sidas laddningsupplevelse i en enda siffra. Dessutom är det den mest synliga och ofta den mest utmanande medlemmen i familjen core web vitals.
I den här guiden går vi igenom exakt vad LCP mäter, vilka värden som räknas som "bra", de verkliga orsakerna bakom en långsam LCP och, viktigast av allt, hur du steg för steg förbättrar måttet. Oavsett om du har programmeringskunskaper eller inte ska du efter att ha läst den här texten veta var du ska titta på din egen webbplats och vilken åtgärd du ska göra först. Målet är inte att stapla teoretisk kunskap, utan att erbjuda en praktisk färdplan som ger mätbara resultat när du tillämpar den.
Vad är Largest Contentful Paint egentligen?
Largest Contentful Paint är ett tidsmått som mäter ögonblicket då webbläsaren ritar upp det största innehållselementet i visningsområdet (viewport), räknat från det att sidladdningen påbörjades. Nyckelordet här är "största". Medan sidan laddas utvärderar webbläsaren ständigt kandidatelementen och markerar det element som upptar störst yta i det synliga området som LCP-element. När ett större element målas allteftersom laddningen fortskrider uppdateras markeringen, och när huvudinnehållet är helt på plats fastställs det slutgiltiga LCP-värdet.
De huvudsakliga elementtyperna som kan utvärderas som LCP-element är: <img>-taggar, bildelement inuti <svg>, block med bakgrundsbilder inlästa via url(), <video>-element med en posterbild samt block-element som innehåller stor text. På de flesta innehållstunga sidor är LCP-elementet en hjältebild eller en stor rubrik.
Det finns en punkt som ofta blandas ihop och som behöver redas ut. LCP är inte ögonblicket då hela sidan har laddats. LCP kan vara klart för länge sedan medan dussintals bilder längre ner på sidan fortfarande håller på att läsas in, eftersom LCP bara tar hänsyn till det område som är synligt vid den första visningen. Den här skillnaden är avgörande för korrekt optimering: att snabba upp saker som användaren inte ser på sin skärm sänker inte LCP.
Hur skiljer sig LCP från FCP och andra mått?
Medan First Contentful Paint (FCP) markerar det första valfria innehållet som målas på skärmen, markerar LCP det största och oftast mest meningsfulla innehållet. FCP säger "något har börjat dyka upp", medan LCP säger "det riktiga innehållet kom". Därför ligger LCP närmare användarens verkliga förväntan än vad FCP gör. På samma sätt har de äldre mått som mätte interaktionsfördröjning i dag ersatts av INP, medan LCP enbart handlar om laddningshastighet och inte mäter interaktion.
Vad är ett bra värde för LCP?
Innan du förbättrar ett mått behöver du veta vad målet är. De tröskelvärden som allmänt accepteras för LCP utvärderas utifrån verkliga användardata för sidan på mobil och dator. Tabellen nedan sammanfattar dessa trösklar.
| LCP-värde | Bedömning | Innebörd |
|---|---|---|
| 2,5 sekunder eller mindre | Bra | Användaren ser huvudinnehållet snabbt, upplevelsen är smidig |
| 2,5 – 4,0 sekunder | Behöver förbättras | Det finns en synlig fördröjning, avhoppsfrekvensen börjar stiga |
| Över 4,0 sekunder | Dålig | Allvarlig långsamhet, hög risk för förlorade konverteringar och placeringar |
Det finns ytterligare en finess när dessa värden bedöms: man tar inte hänsyn till ett enda besök, utan till den 75:e percentilen av verkliga användares fördelning. Med andra ord krävs det att LCP är 2,5 sekunder eller mindre i 75 procent av besöken för att du ska räknas som "bra". Det här sättet att räkna avslöjar de dåliga upplevelser som genomsnittet döljer, eftersom en handfull användare med snabba uppkopplingar inte kan maskera problemet som majoriteten på långsamma enheter upplever.
En annan viktig skillnad är den mellan labbdata och fältdata. Labbtester görs i en kontrollerad miljö med en engångsmätning och är idealiska för felsökning. Fältdata samlas däremot in från verkliga användares verkliga enheter och uppkopplingar, och det är detta som är avgörande för placeringen i sökresultaten. Att använda båda tillsammans är det sundaste: fältdatan säger att problemet finns, labbdatan hjälper dig att hitta orsaken.
De fyra grundläggande orsakerna bakom en långsam LCP
Det mest effektiva sättet att förbättra LCP är att förstå vart tiden tar vägen. LCP-tiden delas vanligtvis in i fyra huvudkomponenter, och var och en av dessa är ett eget förbättringsområde:
- Serverns svarstid (TTFB): Hur lång tid det tar för servern att skicka den första byten efter att webbläsaren har skickat sin förfrågan. En långsam server fördröjer allt som kommer efter.
- Fördröjning av resursinläsning: Tiden som förflyter tills LCP-elementet (särskilt en bild) upptäcks och börjar laddas ner. Om webbläsaren upptäcker resursen sent, börjar inläsningen sent.
- Resursinläsningens varaktighet: Hur lång tid själva nedladdningen av LCP-resursen faktiskt tar. Stora och okomprimerade filer slösar bort tid här.
- Fördröjning av elementets rendering: Tiden som förflyter tills webbläsaren ritar upp resursen på skärmen efter att den har laddats ner. Resurser som blockerar renderingen förlänger det här steget.
Den goda nyheten är att summan av dessa fyra komponenter utgör LCP, och därför ger det den snabbaste vinsten att hitta den komponent som tar störst andel och fokusera på den. På de flesta webbplatser orsakas en betydande del av LCP-tiden av att bilden upptäcks sent och av resurser som blockerar renderingen. I avsnitten nedan tar vi upp varje orsak en i taget.
Snabba upp serverns svarstid (TTFB)
Den första länken i Largest Contentful Paint-kedjan är servern. Om den första byten kommer efter 800 millisekunder kan ingen bild- eller CSS-optimering vinna tillbaka den förlorade tiden. Därför är det oftast logiskt att börja förbättringsarbetet här.
- Använd cachning: Cacha sidans utdata eller data som efterfrågas ofta, så att servern slipper göra allt arbete från grunden vid varje förfrågan. På statiska sidor eller sidor som ändras sällan är fullsidescachning mycket effektiv.
- Dra nytta av ett CDN: Ett innehållsleveransnätverk levererar dina filer från servrar som är geografiskt nära användaren. Det minskar både nätverksfördröjningen och belastningen på ursprungsservern.
- Optimera databasen och serverkoden: Långsamma frågor, onödiga externa API-anrop och tunga mallbearbetningar blåser upp TTFB. Minska arbetet som görs innan svaret skapas så mycket det går.
- Etablera anslutningar tidigt: Använd
preconnect-tips för kritiska tredjepartsdomäner så att steg som DNS-uppslag och TLS-handskakning hinner slutföras innan inläsningen börjar.
En annan kraftfull teknik är att servern skickar svaret bit för bit. Om sidans <head>-del skickas till webbläsaren så snart den är klar kan webbläsaren börja upptäcka och ladda ner CSS och viktiga resurser medan den väntar på resten av innehållet. På så sätt står webbläsaren inte och väntar medan servern fortfarande arbetar.
Låt LCP-bilden upptäckas tidigt och prioritera den
På de flesta webbplatser är LCP-elementet en stor bild, och den största fördröjningen orsakas av att webbläsaren upptäcker den här bilden för sent. Webbläsaren läser HTML från början till slut, och om den kritiska bilden är gömd bakom CSS, i ett element som läggs till av JavaScript eller på en sen punkt, börjar nedladdningen sent. Ditt mål är att visa den här bilden för webbläsaren så tidigt och tydligt som möjligt.
Lägg bilden direkt i HTML
Placera LCP-bilden direkt i HTML-dokumentet med en <img>-tagg. Om bilden läggs till i efterhand med JavaScript eller definieras som en CSS-background-image kan webbläsarens förskanner (preload scanner) inte hitta den tidigt. Att bilden ligger direkt i HTML säkerställer att den upptäcks så tidigt som möjligt.
Höj prioriteten med fetchpriority
Attributet fetchpriority="high" talar om för webbläsaren att den här bilden ska laddas ner med högsta prioritet. Webbläsare tenderar som standard att betrakta bilder som lågprioriterade, och det här attributet lyfter fram LCP-bilden. Men tillämpa det bara på ett enda element, det faktiska LCP-elementet. Att ge allt hög prioritet är detsamma som att inte prioritera något alls.
Gå inte i lazy loading-fällan
Lazy loading (lat inläsning) är fantastiskt för bilder utanför skärmen, men ska aldrig tillämpas på LCP-bilden. Om du sätter attributet loading="lazy" på den stora bilden som syns i den första vyn fördröjer webbläsaren den och din LCP försämras rejält. Regeln är enkel: lämna den kritiska bilden som syns i första vyn som eager (standard) och lat-ladda resten.
Använd preload när det behövs
Om bilden inte kan upptäckas omedelbart i HTML, till exempel om det är en CSS-bakgrund, kan du med <link rel="preload"> be webbläsaren att ladda ner resursen tidigt. För responsiva bilder ger en kombination med attributen imagesrcset och imagesizes att filen i rätt storlek förinläses.
Leverera bilden effektivt
Att låta LCP-bilden upptäckas tidigt är halva vägen, den andra halvan är att bilden laddas ner snabbt. Målet här är att dra ner filstorleken till lägsta möjliga nivå samtidigt som du bevarar bildens visuella kvalitet.
- Föredra moderna format: Moderna format som AVIF och WebP erbjuder mycket mindre filstorlek vid samma kvalitet jämfört med gamla JPEG och PNG. Du kan tillhandahålla ett reservformat med
<picture>-taggen beroende på webbläsarstöd. - Leverera i rätt storlek: Att ladda in en bild som ska visas i 600 pixlars bredd på skärmen i 3000 pixlars bredd är rent slöseri. Skicka den storlek som passar enheten med attributen
srcsetochsizes. - Ställ in komprimeringen: Komprimera bilderna till en nivå där kvalitetsförlusten inte märks med blotta ögat. Vanligtvis ger en kvalitet på 75–85 procent en bra balans mellan filstorlek och utseende.
- Ange dimensionsattribut: Att ange värden för
widthochheightpå bilden förhindrar både layoutförskjutning (CLS) och låter webbläsaren reservera utrymmet i förväg.
Om ditt LCP-element inte är en bild utan ett stort textblock bör du rikta uppmärksamheten mot teckensnitten. Att texten förblir osynlig medan webbteckensnitt läses in fördröjer LCP. Genom att använda font-display: swap kan du låta texten visas omedelbart med ett systemteckensnitt först och bytas ut när teckensnittet har laddats in. Att läsa in kritiska teckensnitt tidigt med preload ger också en tydlig vinst för textbaserad LCP.
Eliminera resurser som blockerar renderingen
Webbläsaren utgår från att den behöver bearbeta hela CSS:en för att kunna rita upp sidan. Därför är CSS till sin natur en resurs som blockerar renderingen. JavaScript som läses in synkront stoppar tolkningen på samma sätt. Ju större och fler dessa resurser är, desto mer fördröjs uppritningen av LCP-elementet på skärmen.
Infoga kritisk CSS
Du kan identifiera den minsta CSS som krävs för att rita upp den första vyn och placera den inline direkt i HTML:ens <head>-del. De återstående, icke-kritiska stilarna laddar du in asynkront för att hindra dem från att blockera renderingen. På så sätt börjar webbläsaren måla huvudinnehållet utan att vänta på att en extern CSS-fil ska laddas ner.
Rensa bort oanvänd CSS och JavaScript
Många webbplatser laddar in hundratals kilobyte CSS och JavaScript som sidan i själva verket inte använder. Att upptäcka och ta bort oanvänd kod minskar både nedladdningstiden och tolkningsbördan. Ladda in stora bibliotek bit för bit med koddelning (code splitting), bara när de verkligen behövs.
Skjut upp JavaScript
Lägg till attributet defer eller async på alla skript som inte behövs för sidans första rendering. defer gör att skriptet kan laddas ner utan att blockera HTML-tolkningen och köras när dokumentet är klart. Särskilt tredjepartskod som analys-, chatt- och annonsskript kan nästan alltid skjutas upp.
Tredjepartsskript hör till de element som du har minst kontroll över men som kan försämra LCP mest. Varje externt skript du lägger till kan hålla huvudtråden upptagen och fördröja renderingen. Att ifrågasätta varje tredjepartsverktyg du lägger till på sidan med frågan "behövs det här verkligen i första vyn?" avslöjar oftast onödig belastning.
Påverkan av rendering på klientsidan och fördröjd inläsning
I applikationer som renderas helt på klientsidan (client-side rendered) stöter LCP på ett extra hinder. Webbläsaren får först en tom eller en skelett-HTML, och därefter skapas innehållet efter att JavaScript har laddats ner och körts. I det här fallet existerar LCP-elementet inte ens förrän JavaScript körs, och följaktligen fördröjs LCP naturligt.
För att lindra det här problemet är rendering på serversidan (SSR) eller statisk sidgenerering (SSG) kraftfulla lösningar. När innehållet skapas i förväg på servern och skickas som HTML kan webbläsaren måla LCP-elementet utan att vänta på JavaScript. Moderna ramverk erbjuder hybridansatser där den första inläsningen renderas på servern och sedan får interaktivitet på klienten. Den ansatsen är vanligtvis den sundaste sett till LCP.
Om du måste använda rendering på klientsidan bör du åtminstone hålla huvud-JavaScript-paketet litet, rendera det kritiska innehållet först och ladda in komponenter utanför skärmen med fördröjning. Att dessutom parallellisera datahämtningarna och prioritera kritiska data snabbar upp att huvudinnehållet visas.
Mät och övervaka LCP korrekt
Du kan inte förbättra det du inte kan mäta. Att använda rätt verktyg i LCP-förbättringsprocessen låter dig både hitta källan till problemet och se om de ändringar du gör fungerar eller inte.
För fältdata är de verkliga användarmätningar (RUM) som webbläsare och prestandaplattformar samlar in den mest värdefulla källan, eftersom de speglar verkliga enheter och uppkopplingsförhållanden. För labbdata gör prestandapanelen i webbläsarens utvecklarverktyg och vanliga prestandagranskningsverktyg jobbet. De här verktygen visar exakt vilket element LCP-elementet är och i vilken komponent tiden spenderas.
En praktisk övervakningsansats består av följande steg:
- Titta först på fältdatan för att ta reda på dina verkliga användares LCP-fördelning och 75:e-percentilvärdet.
- Kör de problematiska sidorna i ett labbverktyg för att fastställa LCP-elementet och tidsfördelningen.
- Tillämpa en åtgärd som riktar sig mot den komponent som tar störst andel (server, upptäckt, inläsning eller rendering).
- Bekräfta resultatet i både labb- och fältdata efter att du har publicerat ändringen.
- Sätt förbättringen under kontinuerlig övervakning, eftersom en nyligen tillagd bild eller ett skript kan försämra måttet på nytt.
Det som behöver understrykas här är att LCP inte är ett engångsarbete. I takt med att webbplatsens innehåll växer, nya funktioner läggs till och tredjepartsverktygen blir fler kan LCP försämras med tiden. Regelbunden övervakning är det enda sättet att fånga den här försämringen tidigt.
Vanliga frågor
Är LCP samma sak som att sidan har laddats färdigt?
Nej. LCP mäter bara ögonblicket då det största innehållselementet som syns i den första vyn målas. LCP kan vara klart för länge sedan medan bilder, skript och andra resurser längre ner på sidan fortfarande håller på att laddas. Därför sänker det inte LCP att snabba upp element som användaren inte ser på sin skärm. Ditt fokus ska alltid vara det första synliga området.
Hur tar jag reda på vilket element som är mitt LCP-element?
Prestandapanelen i webbläsarens utvecklarverktyg visar tydligt det element som markeras som LCP medan du spelar in en sidladdning. De flesta prestandagranskningsverktyg anger också det här elementet i sin rapport under rubriken "Largest Contentful Paint-element". Vanligtvis är det elementet en stor hjältebild eller sidans bredaste textblock.
Varför försämrar lazy loading LCP?
Lat inläsning gör att en bild laddas ner först när den närmar sig det synliga området. Men LCP-elementet är redan synligt i den första vyn, och att tillämpa loading="lazy" på det leder till att webbläsaren fördröjer den i onödan. Ladda därför alltid in den kritiska bilden i första vyn ivrigt (eager) och tillämpa lat inläsning bara på bilder utanför skärmen.
Min server är snabb men LCP är fortfarande hög, varför?
I det här fallet ligger fördröjningen med stor sannolikhet i stegen efter servern. De vanligaste orsakerna är: att LCP-bilden upptäcks sent, stora CSS- och JavaScript-filer som blockerar renderingen, stora ooptimerade bilder eller webbteckensnitt som läses in sent. Att titta på LCP-tidsfördelningen i ett labbverktyg för att se vilken komponent som spenderar mest tid klargör grundorsaken.
Varför skiljer sig LCP-värdena på mobil och dator?
Mobila enheter har vanligtvis lägre processorkraft och mer varierande nätverksförhållanden. Samma sida kör JavaScript långsammare och laddar ner resurser senare på mobilen. Därför är mobil LCP nästan alltid högre än på dator, och din optimeringsprioritet bör oftast vara mobilupplevelsen.
Höjer en förbättrad LCP min SEO-placering direkt?
LCP är en del av core web vitals-ramverket och bedöms bland signalerna för sidupplevelse. Men placeringen beror inte på ett enda mått, utan på många faktorer, inklusive innehållskvalitet. En bra LCP ger dig en fördel mellan sidor av likvärdig kvalitet och bidrar indirekt genom att förbättra användarbeteendet, men den kompenserar inte ensam för svagt innehåll.
Slutsats
Largest Contentful Paint är ett av de mått som bäst sammanfattar hur snabbt en sida "öppnas" för användaren, och därför har det en särskild plats inom core web vitals. Kärnan i arbetet med LCP-förbättring handlar om att förstå vart tiden tar vägen: serversvaret, upptäckten av resursen, nedladdningen och uppritningen på skärmen. När du har hittat vilket av dessa fyra steg som spenderar mest tid har du också hittat den åtgärd som ger störst avkastning.
I praktiken är de vanligaste vinsterna tydliga: snabba upp serversvaret med cache och CDN, lägga LCP-bilden direkt i HTML och prioritera den med fetchpriority, undvika lazy loading-fällan, leverera bilder i moderna format och rätt storlek samt förenkla CSS och JavaScript som blockerar renderingen. Vart och ett av dessa steg gör skillnad även på egen hand, och tillämpade tillsammans kan de flytta din LCP från "dåligt"-zonen till "bra"-zonen.
Kom slutligen ihåg att prestanda inte är ett engångsprojekt, utan en ständig disciplin. Övervaka regelbundet verkliga användardata, kontrollera hur LCP påverkas varje gång en ny funktion och bild läggs till och fånga försämringar tidigt. När du har skaffat dig den vanan kommer ett snabbt första intryck att fortsätta sända en stark signal, både till dina besökare och till sökmotorerna.