LCP-optimering: Komplett Guide (2026)

Varför LCP är det svåraste Core Web Vital att klara

Largest Contentful Paint (LCP) mäter hur lång tid det tar innan det största synliga innehållselementet — vanligtvis en hero-bild, videominiatyr eller rubrikblock — renderas i användarens vyport. Google kräver att LCP ska vara under 2,5 sekunder för minst 75 procent av alla sidbesök för att klassas som "bra".

Låter inte så svårt, eller hur?

Jo, det visar sig att LCP är det Core Web Vital som flest webbplatser misslyckas med. Enligt Chrome User Experience Report (CrUX) från december 2025 har bara 67,6 procent av alla webbplatser ett godkänt LCP-värde. Jämför det med CLS där 80,3 procent klarar sig och INP där 85,6 procent passerar. LCP sticker helt enkelt ut som den tydliga flaskhalsen. Totalt klarar bara 54,4 procent av alla webbplatser samtliga tre Core Web Vitals — vilket ärligt talat är ganska nedslående.

Och LCP väger tungt i Lighthouse — hela 25 procent av det totala prestandabetyget. Så om ditt LCP-värde är dåligt dras hela betyget ner, oavsett hur bra du presterar på andra mätvärden.

Fyra delfaser: så byggs LCP-tiden upp

Att optimera LCP kräver att du förstår vad som faktiskt händer under ytan. Google har sedan 2025 publicerat verklig användardata för varje delfas av LCP i CrUX. Dessa fyra faser adderas till den totala LCP-tiden, och att veta vilken fas som tar mest tid på just din sajt är avgörande.

1. Time to First Byte (TTFB)

Tiden från det att webbläsaren skickar förfrågan till dess att den första byten av HTML-svaret anländer. Den här fasen inkluderar DNS-uppslagning, TCP-handskakning, TLS-förhandling och serverbearbetning. Inget — absolut ingenting — kan hända på klientsidan förrän den här fasen är klar. TTFB sätter ett absolut golv för LCP.

2. Resource Load Delay (resursladdningsfördröjning)

Tiden mellan TTFB och det ögonblick webbläsaren börjar ladda LCP-resursen. Om webbläsaren inte upptäcker LCP-bilden tidigt (exempelvis för att den anges i CSS eller laddas via JavaScript) uppstår en onödig fördröjning här. Det här är ofta den fasen som är lättast att fixa.

3. Resource Load Time (resursladdningstid)

Den tid det tar att ladda ner själva resursen. Stora, okomprimerade bilder eller långsamma servrar gör att denna fas drar ut på tiden.

4. Element Render Delay (renderingsfördröjning)

Tiden från det att resursen har laddats ner till dess att elementet faktiskt renderas på skärmen. Renderingsblockerande CSS, tunga JavaScript-uppgifter och fontladdning kan alla bidra till fördröjningar här.

Genom att mäta varje delfas separat kan du rikta dina insatser exakt dit de gör störst skillnad — istället för att gissa.

Identifiera ditt LCP-element och mät delfaser

Innan du börjar optimera måste du veta exakt vilket element som utgör LCP på dina sidor. Det kanske verkar självklart, men jag har sett överraskande många utvecklare som antar att de vet vilket element det är — och har fel. Använd Chrome DevTools Performance-panel eller web-vitals-biblioteket:

import { onLCP } from 'web-vitals/attribution';

onLCP((metric) => {
  console.log('LCP-värde:', metric.value, 'ms');
  console.log('LCP-element:', metric.attribution.lcpEntry?.element);
  console.log('LCP-resurs-URL:', metric.attribution.lcpEntry?.url);

  // Delfaser
  console.log('TTFB:', metric.attribution.timeToFirstByte, 'ms');
  console.log('Resource Load Delay:', metric.attribution.resourceLoadDelay, 'ms');
  console.log('Resource Load Time:', metric.attribution.resourceLoadTime, 'ms');
  console.log('Element Render Delay:', metric.attribution.elementRenderDelay, 'ms');
}, { reportAllChanges: true });

Den här koden ger dig exakt insyn i vilken fas som bidrar mest till ditt LCP. Kör den i produktion med Real User Monitoring (RUM) för att få data från faktiska användare — inte bara laboratorietester. Labbtester är bra för att hitta problem, men det är fältdata som berättar hur det verkligen ser ut för dina besökare.

Fas 1: Minska TTFB under 800 ms

TTFB sätter det absoluta golvet för hur snabbt LCP kan uppnås. Om din TTFB är 1,5 sekunder har du bara en sekund kvar innan du spricker 2,5-sekundergränsen — och det räcker sällan. Sikta på en TTFB under 800 ms, men helst under 200 ms om det går.

Implementera fullständig caching

En välkonfigurerad cachestrategi kan sänka TTFB från över 2 sekunder till under 100 ms. Det låter nästan för bra för att vara sant, men det handlar om att kombinera flera lager:

Helsidescache: Servera förrenderad HTML direkt utan att köra serverkod. Verktyg som Varnish, Redis eller ditt ramverks inbyggda cache hanterar detta.
Objektcache: Cacha databasfrågor och API-svar i minnet med Redis eller Memcached för att undvika onödiga databasanrop.
CDN-cache: Cacha statiska resurser och även dynamiskt HTML-innehåll vid CDN-kantnoder nära användarna. Konfigurera lämpliga Cache-Control-headers och använd stale-while-revalidate för att servera cachad data medan nytt innehåll hämtas i bakgrunden.

Använd ett CDN för HTML-leverans

Om din server står i Europa och dina användare finns i Asien tillkommer 200–400 ms nätverkslatens per begäran. Det är latens som du inte kan optimera bort med bättre kod. Ett CDN med edge-noder globalt eliminerar den fördröjningen. Tjänster som Cloudflare, Fastly och AWS CloudFront kan alla cacha och leverera HTML-svar från kantnoder.

Utnyttja HTTP/3 och Early Hints (103)

HTTP/3 med QUIC-protokollet eliminerar head-of-line-blocking och minskar anslutningskostnaden. I kombination med 103 Early Hints kan servern skicka preload-headers för kritiska resurser innan det fullständiga svaret är klart:

HTTP/1.1 103 Early Hints
Link: </styles/critical.css>; rel=preload; as=style
Link: </images/hero.avif>; rel=preload; as=image

HTTP/1.1 200 OK
Content-Type: text/html
...

Early Hints ger webbläsaren ett försprång — den kan börja ladda CSS och hero-bilden medan servern fortfarande genererar HTML-svaret. Det är som att ge webbläsaren en att-göra-lista medan kocken fortfarande lagar maten.

Fas 2: Eliminera Resource Load Delay med fetchpriority och preload

Även med snabb TTFB kan webbläsaren missa LCP-bilden om den inte upptäcks tidigt i HTML-parsningsprocessen. Bilder som laddas via CSS background-image eller som genereras av JavaScript är osynliga för webbläsarens förhandsskanner och upptäcks först efter att CSS har parsats och renderingsträdet byggts.

Det här är ofta den fas där du kan vinna mest med minst ansträngning.

fetchpriority="high" — en enda rad som kan förbättra LCP med hundratals millisekunder

Bilder inom vyporten startar normalt med låg prioritet i Chrome. Först efter layoutberäkningen höjs de till hög prioritet. Genom att sätta fetchpriority="high" på din LCP-bild hoppar den över kön och startar omedelbart med hög prioritet:

<img
  src="/images/hero.webp"
  alt="Hero-bild med produktöversikt"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
>

Google Flights-teamet lade till fetchpriority="high" på sin hero-bild och såg LCP förbättras med 700 millisekunder. Etsy rapporterade en förbättring på 4 procent, och vissa sajter har sett upp till 20–30 procent bättre LCP i labbtester. En enda HTML-attribut — ganska otroligt, faktiskt.

Kombinera preload med fetchpriority för maximalt genomslag

Preload och fetchpriority kompletterar varandra: preload gör att webbläsaren upptäcker resursen tidigt, medan fetchpriority styr med vilken prioritet den hämtas. För bästa resultat, kombinera dem i dokumenthuvudet:

<head>
  <!-- Tidigt i head, före andra resurser -->
  <link
    rel="preload"
    href="/images/hero.avif"
    as="image"
    type="image/avif"
    fetchpriority="high"
  >
</head>

Placera preload-länken så tidigt som möjligt i <head>-elementet — före stilmallar och skript — för att webbläsaren ska agera på den omedelbart. Ordningen i head spelar faktiskt roll.

Preload för CSS-bakgrundsbilder

Bilder som laddas via background-image: url(...) i CSS är helt osynliga för webbläsarens preload-skanner. Webbläsaren kan inte ens börja ladda dem förrän HTML har laddats, CSS har parsats och renderingsträdet har byggts. Det innebär en massa onödig väntan. Lös det med en explicit preload:

<link
  rel="preload"
  href="/images/hero-bg.avif"
  as="image"
  fetchpriority="high"
>

Preconnect till kritiska tredjepartsdomäner

Om din LCP-bild serveras från en separat domän (exempelvis ett bild-CDN) kan DNS-uppslagning, TCP-handskakning och TLS-förhandling lägga till 100–300 ms fördröjning. Använd preconnect för att förbereda anslutningen i förväg:

<link rel="preconnect" href="https://images.example.com">
<link rel="dns-prefetch" href="https://images.example.com">

Använd dns-prefetch som fallback — det stöds i äldre webbläsare där preconnect kanske inte fungerar.

Fas 3: Minska resursladdningstid med bildoptimering

Bilder utgör i genomsnitt 50 procent av alla byte på en webbsida. Att optimera LCP-bilden är ofta den enskilt mest effektiva åtgärden du kan göra — och den som ger mest synliga resultat snabbast.

Servera AVIF med WebP och JPEG som fallback

AVIF erbjuder 30–50 procent bättre komprimering än JPEG med likvärdig visuell kvalitet. WebP ger 25–34 procent bättre komprimering. Använd <picture>-elementet för att servera det optimala formatet:

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img
    src="/images/hero.jpg"
    alt="Produktöversikt"
    width="1200"
    height="630"
    fetchpriority="high"
    decoding="async"
  >
</picture>

AVIF stöds nu i Chrome, Edge, Firefox, Opera och Safari. WebP har universellt stöd. Den här trippelfallback-strategin — AVIF först, WebP som mellanläge, JPEG som sista utväg — maximerar komprimering utan att offra kompatibilitet. Det finns egentligen ingen anledning att inte göra det.

Responsiva bilder med srcset och sizes

Servera inte en 2400px bred bild till en mobilanvändare med 375px bred skärm. Det är slöseri med bandbredd och det märks direkt i LCP. Använd srcset för att låta webbläsaren välja rätt bildstorlek:

<img
  src="/images/hero-800.webp"
  srcset="
    /images/hero-400.webp 400w,
    /images/hero-800.webp 800w,
    /images/hero-1200.webp 1200w,
    /images/hero-1600.webp 1600w
  "
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 1200px"
  alt="Hero-bild"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
>

Kombinera det gärna med ett bild-CDN som Cloudinary, imgix eller Cloudflare Images för att automatiskt generera optimala bildstorlekar och format baserat på användarens enhet.

Lazy-ladda aldrig din LCP-bild

En av de vanligaste misstagen jag ser är att utvecklare applicerar loading="lazy" på alla bilder — inklusive hero-bilden ovanför the fold. Lazy loading av LCP-bilden lägger garanterat till fördröjning. Regeln är enkel: bilder ovanför the fold ska aldrig vara lazy-laddade. Applicera loading="lazy" enbart på bilder nedanför the fold.

Fas 4: Minimera Element Render Delay

Även om LCP-resursen har laddats ner kan renderingen blockeras av CSS, JavaScript eller fonter som inte har lästs in ännu. Det här är den fasen som kan vara svårast att felsöka, för problemen syns inte alltid direkt.

Inline kritisk CSS

Webbläsaren renderar ingenting förrän all CSS i <head> har laddats ner och parsats. Extrahera den CSS som behövs för innehåll ovanför the fold och infoga den direkt i HTML:

<head>
  <style>
    /* Kritisk CSS för ovanför-the-fold-innehåll */
    .hero { position: relative; overflow: hidden; }
    .hero img { width: 100%; height: auto; display: block; }
    .hero-title { font-size: 2.5rem; font-weight: 700; }
  </style>
  <!-- Ladda resten av CSS asynkront -->
  <link rel="preload" href="/css/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>

Optimera fontladdning

Webbfonter kan orsaka "Flash of Invisible Text" (FOIT) som blockerar textrendering. Om din LCP råkar vara en rubrik (inte en bild) blir det här kritiskt. Förladda dina viktigaste fonter och använd font-display: swap:

<link rel="preload" href="/fonts/main.woff2" as="font"
      type="font/woff2" crossorigin>

<style>
  @font-face {
    font-family: 'MainFont';
    src: url('/fonts/main.woff2') format('woff2');
    font-display: swap;
  }
</style>

Med font-display: swap visar webbläsaren texten omedelbart i en systemfont och byter sedan till den anpassade fonten när den har laddats. Användaren ser innehåll direkt istället för en tom sida.

Skjut upp icke-kritisk JavaScript

Tunga JavaScript-filer som laddas synkront i <head> blockerar parsning och rendering. Märk icke-kritiska skript med defer eller async, och ladda tredjepartsskript sent:

<!-- Kritiska skript -- defer behåller ordning -->
<script src="/js/app.js" defer></script>

<!-- Tredjepartsskript -- ladda efter att sidan renderats -->
<script>
  window.addEventListener('load', () => {
    const script = document.createElement('script');
    script.src = 'https://analytics.example.com/tracker.js';
    document.body.appendChild(script);
  });
</script>

Avancerat: Speculation Rules API för nära-omedelbar LCP

Okej, nu till något riktigt intressant. Speculation Rules API är ett relativt nytt webbläsar-API som låter dig berätta för webbläsaren vilka sidor den ska förladda eller förrendera i bakgrunden. När användaren sedan navigerar till den sidan visas den nästan omedelbart — inklusive LCP-elementet.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/cart/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

Resultat från produktionsmiljöer visar att Speculation Rules API kan förbättra LCP vid P75 med cirka 170 ms och vid P95 med hela 500 ms. Det är siffror som är svåra att ignorera. I januari 2026 uppdaterade Chrome dessutom mobilbeteendet så att "eager" speculation utlöses 50 ms efter att en länk scrollas in i vyporten.

API:et stöds i Chrome och Edge. Webbläsare som inte stödjer det ignorerar helt enkelt <script type="speculationrules">-taggen utan att orsaka fel, vilket gör det helt säkert att implementera progressivt. Ingen risk, bara potentiell vinst.

Server-Side Rendering: minska LCP med 40–60 procent

Om du använder ett JavaScript-ramverk som React, Vue eller Angular med ren klientrendering (CSR) innebär det att webbläsaren först laddar ner JavaScript-paketet, exekverar det och sedan börjar hämta data innan LCP-elementet kan renderas. Det är en lång kedja av beroenden. Med Server-Side Rendering (SSR) levererar servern komplett HTML direkt:

Next.js: Använd getServerSideProps eller App Router med React Server Components för att rendera sidor på servern.
Nuxt 3: Aktivera SSR som standard och använd useAsyncData för datahämtning på serversidan.
Astro: Renderar till statisk HTML som standard med noll JavaScript — idealiskt för innehållstunga sajter.

Att byta från CSR till SSR minskar typiskt LCP med 40–60 procent. Anledningen är enkel: HTML med fullt renderat innehåll levereras direkt istället för att vänta på JavaScript-exekvering.

Checklista: LCP-optimering i praktiken

Här är en sammanställning av alla optimeringar ordnade efter vilken LCP-delfas de påverkar. Använd den som referens när du går igenom din egen sajt:

TTFB: Aktivera helsidescache, använd CDN för HTML-leverans, implementera HTTP/3 och Early Hints, optimera databasfrågor
Resource Load Delay: Lägg till fetchpriority="high" på LCP-bilden, preloada LCP-resursen i <head>, preconnecta till bild-CDN-domäner, undvik att dölja LCP-bilden i CSS eller JavaScript
Resource Load Time: Konvertera till AVIF/WebP, servera responsiva bilder med srcset, komprimera aggressivt, använd bild-CDN
Element Render Delay: Inline kritisk CSS, använd font-display: swap, skjut upp icke-kritisk JavaScript, eliminera renderingsblockerande tredjepartsskript

Vanliga frågor om LCP-optimering

Vad är ett bra LCP-värde 2026?

Google definierar tre nivåer: under 2,5 sekunder är "bra", mellan 2,5 och 4 sekunder "behöver förbättras", och över 4 sekunder är "dåligt". Sikta på under 2,5 sekunder vid 75:e percentilen av riktiga användarbesök. Enligt CrUX-data från december 2025 klarar bara 67,6 procent av webbplatser den gränsen, så det finns stort förbättringsutrymme.

Hur hittar jag vilket element som är mitt LCP-element?

Använd Chrome DevTools Performance-panel och kör en sidladdningsinspelning. LCP-elementet markeras automatiskt i tidslinjen. Du kan också använda PageSpeed Insights som visar LCP-elementet direkt, eller Googles web-vitals JavaScript-bibliotek med attribution för att logga det i produktion.

Varför hjälper det inte att bara komprimera bilder?

Bildkomprimering påverkar bara en av fyra LCP-delfaser — resursladdningstiden. Om ditt problem ligger i hög TTFB (servern svarar långsamt), sen resursupptäckt (webbläsaren hittar inte bilden tidigt) eller renderingsfördröjning (CSS/JS blockerar) hjälper komprimering inte alls. Du måste identifiera vilken delfas som bidrar mest och angripa den specifikt.

Ska jag använda fetchpriority="high" på alla bilder?

Nej, absolut inte. Använd fetchpriority="high" enbart på din LCP-bild — vanligtvis hero-bilden. Om du ger alla bilder hög prioritet konkurrerar de om bandbredd och ingen av dem får ett verkligt försprång. Tänk på det som en motorväg: om alla bilar kör i förbipasseringsfältet fungerar det inte längre som ett förbipasseringsfält. Du kan däremot använda fetchpriority="low" på bilder under the fold för att minska bandbreddskonkurrens.

Fungerar Speculation Rules API i alla webbläsare?

Speculation Rules API stöds i Chromium-baserade webbläsare — Chrome och Edge. Firefox och Safari stödjer det inte ännu. Men webbläsare som inte stödjer API:et ignorerar helt enkelt <script type="speculationrules">-taggen utan att orsaka fel, så det är säkert att implementera som en progressiv förbättring. Ingen nackdel, bara uppsida.