LCP

Largest Contentful Paint, förkortat LCP, mäter hur lång tid det tar innan sidans största synliga innehåll har ritats upp på skärmen. En besökare klickar sig in från sökresultatet på startsidan i mobilen. Under några sekunder syns bara en tom eller halvfärdig yta. Ögonblicket då hjältebilden eller huvudrubriken äntligen dyker upp, det är den tidpunkt som fångas.

Det är den känslan Google försöker sätta siffror på. LCP är ett av tre Core Web Vitals, tillsammans med CLS och INP, och mätvärdet hämtas från riktiga besök i Chrome. Ett enda tal säger aldrig allt om prestanda, och det ersätter varken bra innehåll eller auktoritet. Men LCP kommer nära hur en människa upplever att sidan laddar.

Vad Largest Contentful Paint faktiskt mäter

Namnet är beskrivande om det delas upp. Largest står för det största elementet, Contentful för att det ska vara riktigt innehåll och Paint för ögonblicket då det ritas upp i webbläsaren. Bara det synliga fönstret räknas, alltså ytan ovanför vikningen - samma yta som avgör om besökaren stannar eller backar tillbaka till sökresultatet.

Element som kan bli LCP-kandidat

Webbläsaren utvärderar löpande vilka element som syns och väljer det som täcker störst yta just då. Kandidaten kan byta under laddningen. Först är en rubrik störst, sedan tar en sen bild över.

• Ett img-element, till exempel en produktbild eller hjältebild, ofta samma bild du satt som Open Graph-bild.
• En CSS-bakgrund som laddas via background-image.
• Ett videoelement som visar sin affischbild innan uppspelning.
• Ett stort textblock, som en H1-rubrik eller en ingress.
• En bakgrundsgradient som dominerar den synliga ytan.

Varför LCP väger in i SEO

Core Web Vitals ingår i Googles signaler för sidupplevelse. LCP ensamt avgör sällan en placering i sökresultatet - innehåll som matchar sökintentionen och tolkas av system som RankBrain väger tyngre - men effekten märks på flera plan samtidigt. Klicket kan dessutom komma från en sammanfattning i AI Overviews, och då är förstavyn det första besökaren faktiskt ser av dig.

• Snabbare förstavy ger färre avhopp innan innehållet ens visats.
• Jämngoda konkurrenter skiljs ibland åt av upplevd hastighet, särskilt när titel och metabeskrivning är likvärdiga.
• Mobila besökare på svagt nät drabbas hårdast av en seg sida, inte minst trafik från Google Discover.
• Bättre laddtid brukar följas av fler slutförda köp och kontakter, vilket också gör attributionen lättare att läsa.
• Kunder som väntar på en tom skärm hinner ofta backa tillbaka till sökresultatet, och då spelar det mindre roll att du vann klicket med en stark CTR.
• Värdet är mätbart med vanliga SEO-verktyg, till skillnad från mycket annat inom SEO.

Vad räknas som ett bra LCP-värde?

Gränserna är satta av Google och gäller lika för alla URLs, oavsett om du jobbar med lokal SEO eller nationell e-handel. Värdet mäts på den 75:e percentilen av verkliga besök, alltså den upplevelse som minst 75 % av användarna får eller bättre.

• Betyget bygger på riktiga besök över tid, inte på ett enskilt test i Lighthouse eller Ahrefs.
• Mobil och desktop bedöms var för sig, och mobil brukar vara långsammare.
• Varje sidtyp behöver kontrolleras, även landningssidor och pillar pages, medan sidor som ändå är satta till noindex kan vänta.
• Ett snabbt testresultat bevisar inte att alla besökare har det bra.
• Gränserna gäller oavsett bransch, sajtstorlek eller plattform.
• Ett värde precis under gränsen tål inte många nya skript.

Fältdata från Chrome User Experience Report

Fältdatan bakom betyget kommer från Chrome User Experience Report, oftast förkortat CrUX. Det är en publik datamängd med anonym mätdata från Chrome-användare som valt att dela statistik. Sådan data kallas också RUM-data.

• Data samlas in per origin, alltså domänen med sitt protokoll och SSL-certifikat, och för enskilda populära adresser.
• Sidor med för få besök saknar CrUX-data helt.
• Datan uppdateras rullande, så förbättringar syns med fördröjning.
• Både PageSpeed Insights och Google Search Console hämtar den.
• Endast Chrome bidrar med mätpunkter, inte alla webbläsare.
• Saknas data för en enskild adress används värdet för hela origin.

CrUX-data i Google Search Console

Rapporten Core Web Vitals i Google Search Console grupperar liknande sidor och visar hur många som ligger i respektive spann. Det är den snabbaste vägen till en överblick över hela sajten, och din XML sitemap visar vilka mallar som finns att gå igenom.

• Grupperingen gör att en mall bedöms samlat, inte sida för sida.
• Mobil och desktop redovisas i varsin flik.
• En validering startas när problemen är åtgärdade.
• Kurvan över tid avslöjar regressions efter en lansering eller ett webbplatsbyte.

Labbdata i Lighthouse och PageSpeed Insights

Labbdata är ett laboratorietest under samma förutsättningar varje gång. Det gör resultatet upprepningsbart och bra för felsökning, men en testkörning speglar inte alltid en långsam mobil på dåligt nät.

• Lighthouse i Chrome DevTools ger labbdata direkt i webbläsaren, utan något extra SEO-verktyg eller betalkonto.
• PageSpeed Insights kombinerar labbdata med fältdata från CrUX, och svårlästa rekommendationer går att låta ChatGPT översätta till vanlig svenska.
• Panelen Performance visar vattenfallet över hämtade resurser.
• Ett bibliotek som web-vitals loggar värdet till ditt eget API.
• CrUX History API ger äldre versioner av mätdatan för jämförelse.

Skillnaden mellan de två datatyperna är en av de vanligaste missuppfattningarna inom SEO, i samma familj som gamla idéer om Google Sandbox och en optimal keyword density:

• Labbdata är stabil och perfekt när en ändring testas.
• Labbdata beskriver en simulerad enhet, inte din publik.
• Fältdata svänger mer och tar längre tid att uppdateras.
• Fältdata är det Googles algoritm faktiskt betygsätter sidan efter.
• Labbdata pekar ut orsaken, fältdata bekräftar effekten.
• Skiljer sig siffrorna kraftigt ligger felet oftast hos långsamma mobila enheter.

Hur hittar du LCP-elementet på din sida?

Ta reda på vilket element som är kandidaten innan något optimeras, annars läggs tiden på fel sak. I Chrome DevTools spelas en laddning in i Performance, och LCP-markören pekar ut exakt vilken nod i DOM som räknades som störst.

• Öppna DevTools och välj fliken Performance.
• Spela in en laddning med strypt nätverk och cachen tömd.
• Klicka på LCP-markören i tidslinjen för att se elementet.
• Läs av vilken startTime kandidaten fick.
• Kontrollera i vattenfallet när filen började hämtas.

Vill du gräva djupare loggas varje kandidat i konsolen med en PerformanceObserver. Deklarera den med const, be om buffered poster så tidiga händelser fångas, och notera att innehåll i iframes hanteras separat.

• En bildkandidat pekar mot komprimering och laddningsordning.
• En textkandidat pekar mot font och blockerande resurser.
• Byter kandidaten sent finns troligen en fördröjd bild.
• Samma kontroll behövs på mobil och desktop.
• Gapet mellan TTFB och LCP visar hur mycket renderingen kostar.

Vanliga orsaker till långsam LCP

Nästan alltid handlar det om tre saker: servern svarar långsamt, något blockerar renderingen eller den viktigaste bilden hämtas för sent. Ofta samverkar flera orsaker, och det är sällan små kodtillägg som strukturerad data eller din schema markup som väger tyngst.

Långsam TTFB och trög server

TTFB, Time To First Byte, mäter tiden innan webbläsaren får första byten svar. Är den hög har allt annat redan tappat värdefull tid. En besökare i Sverige som hämtar innehåll från en server i USA betalar för avståndet i millisekunder, precis som varje extra omdirigering och varje handskakning mot ditt SSL-certifikat kostar tid på vägen fram.

• Underdimensionerad hosting eller delad server med hög belastning, vilket också sänker Googlebots hämtningstakt och äter av din crawl budget.
• Tunga anrop mot databasen vid varje sidladdning.
• Ett externt API som hinner svara långsamt före renderingen.
• Ingen cachning, så varje sida byggs upp från grunden.
• Geografiskt avstånd utan något CDN emellan.

Det som brukar hjälpa:

• Sidcache på servern eller i plattformen.
• Snabbare hosting hos en leverantör som Kinsta.
• Färre tunga plugins och tillägg på kritiska mallar i WordPress.
• Statisk HTML där innehållet ändå sällan ändras.
• Databasfrågor som cachas i stället för att köras vid varje besök.
• En server placerad i samma världsdel som majoriteten av besökarna, eller flera noder om du kör flera språkversioner.

Renderingsblockerande CSS och JavaScript

Innan något ritas upp behöver webbläsaren hämta och tolka CSS och en del JavaScript. Resurser som stoppar processen kallas renderingsblockerande och skjuter upp den punkt då LCP-elementet blir synligt.

• Stora CSS-filer som laddas innan första uppritningen.
• JavaScript i sidhuvudet som körs före innehållet.
• Webbtypsnitt som håller tillbaka text tills fonten laddats.
• Tredjepartsskript för cookies, chatt, analys och spårning av Google Ads.
• Tunga tasks på huvudtråden som även driver upp TBT.

Så minskar blockeringen:

• Kritisk CSS inlines och resten laddas senare.
• Skript märks upp med defer eller async.
• Typsnitt får font-display: swap.
• Skript som inte behövs i förstavyn laddas on demand.
• Oanvänd CSS rensas bort ur de största filerna.
• Inbäddade iframes flyttas nedanför vikningen.

Tunga bilder och sena img-element

Är kandidaten en bild avgörs värdet av hur snabbt just den filen kommer fram. En vanlig miss är att bilden upptäcks sent eller hämtas i fel ordning.

• Bilden ligger djupt i markup och upptäcks sent.
• Filen är stor och saknar komprimering.
• Ett gammalt format används i stället för WebP eller AVIF.
• Bilden sätts in med JavaScript i stället för ett img-element.
• Lazy-loading är påslagen på just LCP-bilden.

Åtgärder som ger snabb effekt:

• Skala bilden till den storlek den faktiskt visas i.
• Sätt bredd och höjd så layouten inte hoppar.
• Servera olika storlekar med srcset.
• Lyft ut bilden ur karuseller och slidrar i förstavyn, särskilt på landningssidor.
• Byt en tung CSS-bakgrund mot ett vanligt img-element.
• Låt bilden hämtas från samma origin som sidan när det går.

Så förbättrar du LCP steg för steg

Det finns ingen enda knapp att trycka på, men en logisk ordning att följa, precis som i en vanlig SEO-checklista. Arbeta från servern mot bilderna och mät om efter varje ändring.

1. Mät nuläget med både labbdata och fältdata.
2. Identifiera vilket element som är LCP-kandidat.
3. Sänk TTFB med cachning och bättre hosting.
4. Aktivera textkomprimering med Brotli eller Gzip.
5. Lägg en CDN framför sajten.
6. Minska renderingsblockerande CSS ovanför vikningen.
7. Skjut upp icke-kritisk JavaScript.
8. Förladda LCP-bilden och stäng av lazy-loading på den.
9. Mät igen och bevaka värdet över tid i rapporten Core Web Vitals.

Snabbare leverans med CDN, Brotli och Gzip

En CDN, alltså ett Content Delivery Network, är ett nät av servrar som lagrar kopior av sajtens filer. Innehållet hämtas från närmaste nod i stället för från ursprungsservern.

• Kortare avstånd mellan innehåll och besökare.
• Avlastning av ursprungsservern vid trafiktoppar.
• Snabbare leverans av bilder, CSS och JavaScript.
• Inbyggd i många plattformar, från enkla paket till Magento.
• Bilder kan optimeras automatiskt i noden på vägen ut.
• Trafiktoppar från kampanjer i till exempel Google Ads klaras utan att TTFB stiger.

Textfiler komprimeras hårt innan de skickas. Brotli ger i regel något mindre filer än Gzip, medan GZIP är det äldre och mest spridda alternativet.

• Slå på Brotli om servern stöder det, annars Gzip.
• Komprimera HTML, CSS, JavaScript och SVG.
• Låt bildformaten sköta komprimeringen av Images.
• Kontrollera att komprimeringen verkligen är aktiv i svarshuvudena.

Prioritera LCP-bilden i Chrome

När kandidaten är en bild handlar arbetet om att få webbläsaren att upptäcka filen tidigt. En preload-tagg i sidhuvudet talar om att bilden är viktig långt innan den annars skulle hittats i markup.

• Lägg en <link rel="preload" as="image"> för hjältebilden.
• Undvik lazy-loading på allt ovanför vikningen.
• Sätt storleksattribut, vilket också hjälper CLS och övriga Core Web Vitals.
• Servera rätt bildstorlek för mobil respektive desktop.
• Kontrollera resultatet i vattenfallet efteråt.

Är server-side rendering värt besväret?

För de flesta klassiska sajter är svaret nej. Server-Side Rendering är främst intressant när sidan i dag byggs upp av ett tungt JavaScript-ramverk och besökaren möts av en tom yta som fylls senare.

• Levereras innehållet redan som HTML finns större vinster i helheten på annat håll.
• En tom sida som fylls av skript vinner ofta flera sekunder och blir dessutom lättare att indexera.
• Komplexiteten ökar i både bygge och drift.
• Väg alltid vinsten mot vad den kostar att förvalta, och servera aldrig en avskalad version bara till Googlebot - det är cloaking.
• Statisk förrendering räcker långt för sidor som sällan ändras.
• Mät före och efter i stället för att lita på magkänslan.

LCP, CLS och INP i Core Web Vitals

De tre måtten beskriver olika delar av upplevelsen. INP ersatte det äldre FID, First Input Delay, som bara fångade fördröjningen vid första interaktionen.

• LCP: hur snabbt sidans största innehåll blir synligt.
• CLS: hur mycket innehållet hoppar runt under laddning.
• INP: hur snabbt sidan svarar på interaktion.
• TBT: labbmåttet som visar hur länge huvudtråden är upptagen.
• TTFB: stödmåttet som avslöjar om servern är flaskhalsen.
• FID: det gamla måttet på Input Delay, numera ersatt av INP.

Hur hänger LCP, CLS och INP ihop?

Samma åtgärder drar ofta åt rätt håll för flera mått. Storleksattribut på bilder hjälper både LCP och CLS. Bantad JavaScript hjälper både LCP och INP. En sida med perfekt LCP men usel CLS känns ändå trasig, och det märks ofta i konverteringsgraden.

Arbetet med LCP är sällan ett engångsjobb. Sajter förändras, nya bilder och skript smyger sig in, och ett tidigare grönt värde kan glida tillbaka. En enkel rutin där rapporten i Search Console kontrolleras med jämna mellanrum fångar regressions innan besökarna hinner märka dem. Kom också ihåg proportionerna: en snabb sida stöttar din innehållsstrategi, ditt content marketing-arbete och den ämnesauktoritet du bygger, men den ersätter aldrig trovärdigt innehåll och E-E-A-T. Det som händer utanför sajten, som länkbygge och annat off-page-arbete, rör inte laddtiden alls - och laddtiden rör inte dem.