Core Web Vitals 20 min læsning

LCP-optimering i 2026: Få din Largest Contentful Paint under kontrol

Kæmper du med langsom LCP? Her er en hands-on guide med alt fra de fire LCP-underdele til fetchpriority, preload, AVIF/WebP og Speculation Rules API — med kodeeksempler du kan bruge med det samme.

Editorial Team

LCP-optimering i 2026: Få din Largest Contentful Paint under kontrol

Largest Contentful Paint (LCP) er den Core Web Vital-metrik, som flest websites kæmper med. Og det er ikke et lille problem — ifølge Chrome User Experience Report (CrUX) opfylder over 40 % af alle websites ikke Googles LCP-tærskelværdi på 2,5 sekunder. Det gør LCP til den sværeste af de tre Core Web Vitals at bestå, og den mest afgørende for, hvordan brugerne oplever din sides indlæsningshastighed.

I denne guide dykker vi ned i alt, hvad du behøver at vide om LCP i 2026: fra de fire underdele, der tilsammen udgør din LCP-score, til avancerede optimeringsteknikker med fetchpriority, preload, moderne billedformater og server-side rendering. Hvert afsnit indeholder konkrete kodeeksempler, du kan implementere med det samme.

Hvad er LCP, og hvorfor skal du bekymre dig?

Largest Contentful Paint måler den tid, det tager fra brugeren navigerer til din side, til det største synlige indholdselement i viewporten er fuldt renderet. Det kan være et hero-billede, en stor tekstblok, en video-poster — eller et andet visuelt dominerende element oven for folden.

Kort sagt: LCP fanger den oplevede indlæsningshastighed. Det øjeblik, hvor brugeren føler, at siden er "klar".

En hurtig LCP signalerer, at siden er nyttig og responsiv. En langsom LCP? Den får brugeren til at tvivle på, om siden overhovedet virker. Og ærligt talt, vi har alle prøvet den følelse.

LCP-tærskelværdier

Google definerer tre kategorier for LCP-scores, målt på 75. percentil af alle sidebesøg:

  • God (Good): Under 2,5 sekunder — siden indlæses hurtigt, og brugeren oplever en glat oplevelse.
  • Behøver forbedring (Needs Improvement): Mellem 2,5 og 4,0 sekunder — brugeren oplever en mærkbar forsinkelse.
  • Dårlig (Poor): Over 4,0 sekunder — indlæsningen føles langsom og frustrerende, og Google vil sandsynligvis nedprioritere siden i søgeresultaterne.

I praksis bør du sigte mod en LCP på under 2,0 sekunder for at have lidt sikkerhedsmargin. Husk, at 75. percentil-kravet betyder, at tre ud af fire brugere skal have en god oplevelse — inklusiv dem på langsomme netværk og ældre enheder.

Stort nyt fra december 2025: LCP er nu cross-browser

En vigtig milepæl blev nået den 12. december 2025, da LCP officielt blev Baseline Newly Available. Med udgivelsen af Safari 26.2 er LCP API nu tilgængelig i alle større browsere — Chrome, Firefox, Safari og Edge.

Det er faktisk ret stort. For første gang kan du måle LCP konsistent på tværs af hele din brugerbase, ikke kun Chrome-brugere.

Der er dog stadig en lille forskel at være opmærksom på: Chrome måler LCP inklusiv presentationTime, mens Firefox og Safari måler til det tidligere paintTime. Fra Chrome 145 eksponeres paintTime også for LCP, så du kan sammenligne på tværs af browsere. I praksis er forskellen typisk kun få millisekunder — ikke noget der holder mig vågen om natten.

De fire LCP-underdele: Find din flaskehals

Okay, her bliver det virkelig interessant. For effektivt at forbedre din LCP skal du forstå, hvilken af de fire faser der er den primære flaskehals. Siden februar 2025 har Google gjort det muligt at se reelle brugerdata for hver underdel via CrUX. De fire underdele er:

1. Time to First Byte (TTFB)

TTFB er tiden fra brugeren navigerer til siden, til browseren modtager den første byte af HTML-dokumentet. Det inkluderer DNS-opslag, TCP/TLS-forbindelse og serverbehandlingstid.

TTFB er fundamentet. Hvis din server er langsom, kan resten af optimeringsarbejdet ikke redde din LCP.

Og tallene taler for sig selv: mindst halvdelen af alle websites med dårlig LCP har en TTFB på over 2.270 millisekunder alene. Det betyder, at TTFB alene næsten garanterer, at LCP ikke kan komme under 2,5-sekunders-tærsklen.

2. Resource Load Delay (Ressourceindlæsningsforsinkelse)

Resource Load Delay er tiden mellem TTFB og det tidspunkt, hvor browseren begynder at downloade LCP-ressourcen (typisk et billede). Det er ikke selve downloadtiden — det er den tid, browseren bruger på at opdage, at ressourcen overhovedet eksisterer.

Det her er den mest oversete flaskehals, og den overrasker mange.

Den typiske site med dårlig LCP bruger næsten fire gange så lang tid på at vente med at starte download af LCP-billedet, som den faktisk bruger på at downloade det. I gennemsnit 1,3 sekunder mellem TTFB og billedanmodning — mere end halvdelen af hele 2,5-sekunders-budgettet spildt på ren ventetid. Det er vanvittigt, når man tænker over det.

Høj Resource Load Delay skyldes typisk, at LCP-billedet er gemt som CSS-baggrundsbillede (som preload-scanneren ikke kan opdage), at billedet først indsættes via JavaScript efter rendering, eller at client-side rendering forsinker hele HTML-strukturen.

3. Resource Load Duration (Ressourceindlæsningstid)

Resource Load Duration er den faktiske tid, det tager at downloade LCP-ressourcen. Denne fase afhænger primært af filstørrelse, netværkshastighed og serverinfrastruktur.

Her er en udbredt misforståelse: mange tror, at langsom LCP primært er et filstørrelsesproblem. Teams fokuserer udelukkende på billedkomprimering, men analyser af feltdata viser gang på gang, at Resource Load Delay ofte er den primære synder — ikke Resource Load Duration. Det betyder ikke, at filstørrelse er ligegyldig, men det er sjældent det eneste eller vigtigste problem.

4. Render Delay (Renderingsforsinkelse)

Render Delay er tiden fra LCP-ressourcen er fuldt indlæst, til den faktisk vises på skærmen. Typiske årsager er render-blokerende stylesheets, JavaScript der skal udføres før rendering, eller layout-beregninger der forsinker det visuelle resultat.

Google anbefaler, at Render Delay bør udgøre cirka 10 % af det samlede LCP-budget. Overstiger den det væsentligt, er der typisk render-blokerende ressourcer, du kan gøre noget ved.

Den samlede LCP er altså summen af alle fire dele:

LCP = TTFB + Resource Load Delay + Resource Load Duration + Render Delay

Måling og diagnosticering af LCP

Før du begynder at optimere, skal du vide, hvad du har med at gøre. Her er de vigtigste værktøjer til at identificere, hvilken underdel der er din primære flaskehals.

Chrome DevTools

Åbn Performance-panelet i Chrome DevTools, og optag en sideindlæsning. LCP-elementet markeres direkte i tidslinjen, og du kan se præcis, hvornår det blev renderet. I 2026 viser DevTools desuden LCP-underdele som farvekodede segmenter, så du hurtigt kan se, om det er TTFB, Resource Load Delay eller noget andet, der dominerer.

PageSpeed Insights og CrUX

PageSpeed Insights kombinerer Lighthouse lab-data med CrUX feltdata. Det er nok den hurtigste måde at tjekke, om dine rigtige brugere oplever dårlig LCP. Siden februar 2025 viser CrUX også data for de individuelle LCP-underdele, hvilket gør diagnosticering langt mere præcis.

web-vitals biblioteket

For at indsamle granulær LCP-data fra dine egne brugere kan du bruge Googles web-vitals-bibliotek med attribution build. Her er et praktisk eksempel:

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

onLCP((metric) => {
  const attribution = metric.attribution;

  console.log('LCP:', metric.value, 'ms');
  console.log('LCP element:', attribution.lcpEntry?.element);

  // Nedbryd i underdele
  const subparts = {
    ttfb: attribution.timeToFirstByte,
    resourceLoadDelay: attribution.resourceLoadDelay,
    resourceLoadDuration: attribution.resourceLoadDuration,
    renderDelay: attribution.elementRenderDelay,
  };

  console.table(subparts);

  // Send til analytics
  navigator.sendBeacon('/analytics/lcp', JSON.stringify({
    value: metric.value,
    rating: metric.rating,
    url: location.href,
    ...subparts
  }));
});

Med denne attribution-data kan du bygge dashboards, der viser præcis, hvilken underdel der er flaskehalsen for dine brugere — og det gør en kæmpe forskel for at prioritere dit optimeringsarbejde rigtigt.

Optimeringsteknik 1: Reducer TTFB

TTFB er fundamentet for god LCP. Uden en hurtig serverrespons er alt det andet lidt ligegyldigt. Så lad os starte her.

Brug et CDN

Et Content Delivery Network (CDN) serverer dit indhold fra servere tæt på brugeren. Tænk over det: hvis en bruger i København indlæser en side fra en server i USA, tilføjer den fysiske afstand hundreder af millisekunder i latens. Et CDN reducerer denne afstand drastisk.

Konfigurer dit CDN til at cache ikke bare statiske assets, men også hele HTML-sider, hvor det er muligt. Full-page caching med en stale-while-revalidate-strategi kan reducere TTFB fra over 2 sekunder til under 100 millisekunder. Den forskel kan mærkes.

Optimer serverside-logik

Hvis din backend bruger lang tid på databaseforespørgsler, API-kald eller template-rendering, påvirker det direkte TTFB. Her er hvad du bør overveje:

  • Database query caching: Brug Redis eller Memcached til at cache hyppige forespørgsler.
  • Reduktion af redirects: Hver redirect tilføjer en fuld roundtrip. Eliminér unødvendige redirects — især kæder af redirects (dem ser vi desværre stadig alt for ofte).
  • HTTP/3: Websites der bruger HTTP/3 ser 20-30 % forbedringer i LCP, især på mobile netværk, fordi protokollen reducerer forbindelsestid og håndterer pakketab bedre.

Server-side rendering (SSR) og Static Site Generation (SSG)

Client-side rendering (CSR) er en af de mest udbredte årsager til langsom LCP. Med CSR sender serveren en minimal HTML-skal, og det synlige indhold genereres først, når JavaScript er downloadet, parset og eksekveret. Det kan nemt tilføje 2-4 sekunder til LCP.

Ved at skifte til SSR eller SSG kan du typisk reducere LCP med 40-60 %. Det er ikke et lille tal.

Med streaming SSR (understøttet af Next.js og React Server Components) kan du endda begynde at sende HTML til browseren, før hele siden er klar:

// Next.js App Router med streaming SSR
// app/page.tsx
import { Suspense } from 'react';
import HeroSection from './HeroSection';
import DynamicContent from './DynamicContent';

export default function Page() {
  return (
    <>
      {/* Hero-sektionen renderes med det samme */}
      <HeroSection />

      {/* Dynamisk indhold streames, når det er klar */}
      <Suspense fallback={<LoadingSkeleton />}>
        <DynamicContent />
      </Suspense>
    </>
  );
}

Det sikrer, at LCP-elementet (typisk hero-billedet eller den primære overskrift) sendes tidligt i HTML-strømmen, mens resten af indholdet streames bagefter. Smart, ikke?

Optimeringsteknik 2: Eliminér Resource Load Delay med fetchpriority og preload

Resource Load Delay er den mest oversete — og ofte den største — flaskehals. Hele strategien koger ned til ét princip: sørg for, at LCP-ressourcens URL er synlig for browserens preload-scanner, så den opdages og downloades så tidligt som muligt.

fetchpriority="high" på LCP-billedet

Når browseren opdager billeder under sideindlæsning, tildeler den dem som standard lav prioritet. Først efter layout-beregning, når browseren bekræfter, at billedet er i viewporten, opgraderes prioriteten til høj. Denne opgradering kræver, at CSS først er downloadet og parset — hvilket skaber en forsinkelse.

fetchpriority="high" springer hele denne proces over. Billedet får høj prioritet fra det øjeblik, det opdages, uden at vente på layout.

Og resultaterne taler for sig selv: Google Flights-teamet tilføjede fetchpriority="high" til deres hero-billede og så LCP forbedre sig med hele 700 millisekunder. Fra en enkelt HTML-attribut. Lad det lige synke ind.

<!-- LCP hero-billede med fetchpriority -->
<img
  src="/images/hero.webp"
  alt="Hero-billede"
  width="1200"
  height="600"
  fetchpriority="high"
>

Vigtigt: Brug kun fetchpriority="high" på 1-2 billeder. Hvis alt har høj prioritet, har intet det.

Preload til tidlig opdagelse

fetchpriority og preload løser faktisk forskellige problemer: preload handler om hvornår ressourcen opdages, mens fetchpriority handler om dens prioritet i downloadkøen. For LCP-billeder, der ikke er direkte synlige i HTML (f.eks. CSS-baggrundsbilleder eller billeder, der sættes dynamisk), er preload afgørende:

<!-- I <head>: Preload LCP-billedet med høj prioritet -->
<link
  rel="preload"
  as="image"
  href="/images/hero.avif"
  type="image/avif"
  fetchpriority="high"
>

<!-- For responsive billeder med srcset -->
<link
  rel="preload"
  as="image"
  imagesrcset="/images/hero-400.avif 400w,
               /images/hero-800.avif 800w,
               /images/hero-1200.avif 1200w"
  imagesizes="100vw"
  fetchpriority="high"
>

Undgå CSS-baggrundsbilleder til LCP

CSS-baggrundsbilleder er usynlige for preload-scanneren. Browseren opdager dem først, når CSS er downloadet, parset, og DOM er bygget — hvilket skaber en betydelig Resource Load Delay.

Brug i stedet et regulært <img>-tag med object-fit: cover for at opnå samme visuelle effekt:

<!-- I stedet for CSS background-image -->
<div class="hero">
  <img
    src="/images/hero.avif"
    alt="Hero-baggrund"
    class="hero-bg"
    fetchpriority="high"
    width="1920"
    height="1080"
  >
  <div class="hero-content">
    <h1>Din overskrift her</h1>
  </div>
</div>

<style>
.hero {
  position: relative;
  overflow: hidden;
}
.hero-bg {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  z-index: -1;
}
</style>

Jeg har selv set dette skifte alene forbedre LCP med over et sekund på et par projekter. Det er en af de ændringer, der bare virker.

Preconnect til eksterne domæner

Hvis dit LCP-billede hostes på et andet domæne (f.eks. et CDN eller billedservice), kan du spare tid ved at etablere forbindelsen tidligt med preconnect:

<link rel="preconnect" href="https://cdn.ditsite.dk">
<link rel="dns-prefetch" href="https://cdn.ditsite.dk">

Ideelt set bør du dog hoste LCP-billedet på samme domæne som dit HTML-dokument for at undgå ekstra DNS-opslag og TLS-handshakes helt.

Optimeringsteknik 3: Reducer Resource Load Duration med moderne billedformater

Selvom Resource Load Duration sjældent er den primære flaskehals, kan mindre billedfiler stadig gøre en mærkbar forskel — især for brugere på langsomme netværk. Og det er trods alt en stor del af verden.

AVIF vs. WebP: Hvilket format bør du vælge?

I 2026 er de to vigtigste moderne billedformater AVIF og WebP. Begge er markant bedre end JPEG, men de har forskellige styrker:

  • AVIF: Opnår de mindste filstørrelser — typisk 50 % mindre end JPEG og 20-30 % mindre end WebP. Understøtter HDR og wide-gamut farver. Dog lidt langsommere at afkode i browseren (men det er forbedret markant i 2025).
  • WebP: Hurtigere afkodning end AVIF, stærk komprimering (ca. 30 % mindre end JPEG), og bredest browserunderstøttelse med 95,3 % dækning.

Den optimale strategi er at servere AVIF som primært format med WebP som fallback og JPEG som sidste sikkerhedsnet:

<picture>
  <source
    srcset="/images/hero-400.avif 400w,
            /images/hero-800.avif 800w,
            /images/hero-1200.avif 1200w"
    sizes="100vw"
    type="image/avif"
  >
  <source
    srcset="/images/hero-400.webp 400w,
            /images/hero-800.webp 800w,
            /images/hero-1200.webp 1200w"
    sizes="100vw"
    type="image/webp"
  >
  <img
    src="/images/hero-800.jpg"
    srcset="/images/hero-400.jpg 400w,
            /images/hero-800.jpg 800w,
            /images/hero-1200.jpg 1200w"
    sizes="100vw"
    alt="Hero-billede"
    width="1200"
    height="600"
    fetchpriority="high"
  >
</picture>

Konvertering fra JPEG til WebP forbedrer typisk sideindlæsningstiden med 15-30 %. For billedtunge sider som e-handel og portfolier kan forbedringen overstige 40 %. De besparelser oversættes direkte til bedre LCP.

Responsive billeder med srcset og sizes

Server altid billeder i den rigtige størrelse til brugerens enhed. En mobiltelefon behøver ikke at downloade et 1920px bredt billede — det er simpelthen spild af båndbredde, der direkte forværrer LCP:

<img
  srcset="/images/hero-400.avif 400w,
          /images/hero-800.avif 800w,
          /images/hero-1200.avif 1200w,
          /images/hero-1920.avif 1920w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 80vw,
         1200px"
  src="/images/hero-800.avif"
  alt="Hero-billede"
  width="1200"
  height="600"
  fetchpriority="high"
>

Lazy loading: Kun under folden

En Chrome UX Report-analyse viste, at websites der lazy-loader deres LCP-element har 35 % langsommere LCP. Lad mig gentage det: 35 %.

Lazy loading bør aldrig bruges på LCP-billedet eller andet above-the-fold indhold. Brug det kun på billeder, der er under folden:

<!-- LCP-billede: ALDRIG lazy load -->
<img src="/hero.avif" fetchpriority="high" alt="Hero">

<!-- Billeder under folden: Brug lazy loading -->
<img src="/artikel-thumb.avif" loading="lazy" alt="Thumbnail">

Optimeringsteknik 4: Reducer Render Delay

Render Delay er tiden fra LCP-ressourcen er fuldt indlæst, til den vises på skærmen. Det virker måske overraskende, at der overhovedet er en forsinkelse her — men render-blokerende CSS og JavaScript er de sædvanlige syndere.

Inline kritisk CSS

Render-blokerende CSS er en af de mest udbredte årsager til Render Delay. Browseren kan simpelthen ikke rendere noget, før al CSS i <head> er downloadet og parset.

Løsningen er at inline den kritiske CSS (den CSS, der er nødvendig for above-the-fold indhold) direkte i HTML og defer resten:

<head>
  <!-- Inline kritisk CSS -->
  <style>
    .hero { position: relative; min-height: 60vh; }
    .hero-bg { position: absolute; inset: 0; width: 100%;
               height: 100%; object-fit: cover; }
    h1 { font-size: 2.5rem; color: #fff; }
    /* ... kun above-the-fold styles ... */
  </style>

  <!-- Defer resten af CSS -->
  <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>

Optimer webfonte

Webfonte kan forsinke rendering overraskende meget, fordi browseren som standard venter på fonten, før tekst vises. Brug font-display: swap for at vise tekst med en system-font, indtil den rigtige webfont er indlæst. Og husk at preloade kritiske fonte:

<!-- Preload kritisk font -->
<link rel="preload" href="/fonts/primary.woff2"
      as="font" type="font/woff2" crossorigin>

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

Hvis dit LCP-element er en tekstblok (f.eks. en stor overskrift), er font-optimering direkte afgørende for din LCP-score. font-display: swap sikrer, at teksten vises øjeblikkeligt med en fallback-font og dermed registrerer en hurtig LCP.

Defer ikke-kritisk JavaScript

JavaScript der blokerer rendering, bør enten defers eller flyttes til bunden af <body>. Her er den grundlæggende strategi:

<!-- Kritisk: Inline eller sync i head kun hvis nødvendigt -->
<script>/* Minimal kritisk JS */</script>

<!-- Ikke-kritisk: defer for at undgå render-blocking -->
<script src="/js/app.js" defer></script>

<!-- Uafhængigt: async for analytics etc. -->
<script src="/js/analytics.js" async></script>

<!-- Tredjepartsscripts: Indlæs efter LCP -->
<script>
  // Indlæs ikke-kritiske tredjepartsscripts efter LCP
  if ('PerformanceObserver' in window) {
    new PerformanceObserver((list) => {
      const lcpEntry = list.getEntries().at(-1);
      if (lcpEntry) {
        loadThirdPartyScripts();
      }
    }).observe({ type: 'largest-contentful-paint', buffered: true });
  }
</script>

Det der trick med at indlæse tredjepartsscripts efter LCP er i øvrigt noget af det mest effektive, du kan gøre, hvis du har mange third-party scripts på din side.

Optimeringsteknik 5: Deprioritér ikke-kritiske ressourcer

fetchpriority handler ikke kun om at booste LCP-billedets prioritet. Du kan også sænke prioriteten af ressourcer, der konkurrerer om båndbredde med LCP-elementet:

<!-- LCP-billede: Høj prioritet -->
<img src="/hero.avif" fetchpriority="high" alt="Hero">

<!-- Header-ikon: Lavere prioritet -->
<img src="/logo-small.svg" fetchpriority="low" alt="Logo">

<!-- Avatar i navigation: Lavere prioritet -->
<img src="/avatar.webp" fetchpriority="low" alt="Profil">

<!-- Ikke-kritisk third-party script -->
<script src="/js/chat-widget.js" fetchpriority="low" defer></script>

Det sikrer, at LCP-billedet vinder kampen om netværksressourcer. Tænk på det som en VIP-bane i lufthavnen — dit hero-billede skal igennem først.

Optimeringsteknik 6: Speculation Rules API til instant navigationer

Speculation Rules API er en nyere web platform-feature, der kan eliminere LCP-forsinkelse fuldstændigt for efterfølgende sidenavigationer. Ja, du læste rigtigt — fuldstændigt. API'en giver dig mulighed for at fortælle browseren, hvilke URL'er brugeren sandsynligvis navigerer til, så browseren kan prerendere dem i baggrunden:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "href_matches": "/*"
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "selector_matches": "a[href]"
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Med prerendering er den næste side allerede fuldt renderet, når brugeren klikker. Det giver en oplevelse af instant navigation med en LCP tæt på nul. API'en understøttes i Chromium-baserede browsere og bruges allerede på store websites som Google Search.

Mobile enheder: Hvor LCP virkelig testes

Her er en ubehagelig sandhed: en side, der indlæses på 1,5 sekunder på din MacBook, kan nemt tage 5 sekunder på en middelklasse Android-telefon. Mobile enheder har langsommere CPU'er, mindre hukommelse og ofte langsommere netværk.

Specifikke mobiloptimeringer du bør overveje:

  • Server mindre billeder: Brug responsive images med srcset og sizes til at servere passende billedstørrelser til mobile enheder.
  • Reducer JavaScript: Mobile CPU'er tager 3-5 gange længere om at parse og eksekvere JavaScript sammenlignet med desktop. Hver kilobyte tæller mere på mobil.
  • Test på rigtige enheder: Chrome DevTools' throttling simulerer ikke realistisk mobile CPU-begrænsninger. Brug CrUX feltdata til at forstå dine mobile brugeres faktiske oplevelse.
  • Overvej Content-Visibility: content-visibility: auto kan reducere renderingsarbejdet for indhold under folden, hvilket frigør CPU-ressourcer til at rendere LCP-elementet hurtigere.

Almindelige LCP-fejl du bør undgå

Selvom principperne er klare nok, falder mange teams stadig i de samme fælder. Her er de mest almindelige fejl — og jeg har set dem alle i praksis.

Fejl 1: Optimering af det forkerte element

Mange optimerer tilfældige billeder uden at tjekke, hvilket element der faktisk er LCP. Brug Lighthouse, DevTools eller web-vitals-biblioteket til at identificere dit LCP-element først. Det kan overraske — måske er LCP-elementet en stor tekstblok og slet ikke det billede, du antog.

Fejl 2: Lazy loading af LCP-billedet

Det her sker overraskende ofte — især med CMS-systemer og frameworks, der automatisk tilføjer loading="lazy" til alle billeder. Lazy loading af LCP-billedet vil altid føre til unødvendig Resource Load Delay. Sørg for, at dit LCP-billede ikke har loading="lazy".

Fejl 3: For mange preload-hints

Preload er kraftfuldt, men hvis du preloader for mange ressourcer, konkurrerer de alle om den samme båndbredde. Og så indlæses ingen af dem hurtigt. Begræns dig til 2-3 preloads — og sørg for, at LCP-ressourcen er én af dem.

Fejl 4: Fokus på lab-scores i stedet for feltdata

Din Lighthouse LCP kan se fantastisk ud, men hvis dine rigtige brugere på langsomme forbindelser oplever 5-sekunders LCP, vil din CrUX-data stadig vise en dårlig score. Lab-værktøjer er til diagnosticering; feltdata er sandheden. Monitorer altid begge dele.

Fejl 5: Manglende width og height på billeder

Billeder uden eksplicitte width- og height-attributter kan forsinke rendering, fordi browseren ikke kender billedets dimensioner, før det er indlæst. Det kan også forårsage layout shifts (CLS). Angiv altid dimensioner:

<!-- Altid angiv width og height -->
<img
  src="/hero.avif"
  width="1200"
  height="600"
  alt="Hero"
  fetchpriority="high"
>

En komplet LCP-optimeringscheckliste

Her er en samlet checkliste, du kan bogmærke og bruge som reference:

  1. Identificér dit LCP-element med DevTools eller web-vitals.
  2. Mål de fire underdele (TTFB, Resource Load Delay, Resource Load Duration, Render Delay) for at finde flaskehalsen.
  3. Optimer TTFB: CDN, serverside-caching, HTTP/3, eliminér redirects.
  4. Eliminér Resource Load Delay: Sørg for, at LCP-billedet er synligt i HTML for preload-scanneren. Tilføj fetchpriority="high". Preload om nødvendigt.
  5. Reducer Resource Load Duration: Konverter til AVIF/WebP, brug responsive images, komprimer med passende kvalitet.
  6. Minimer Render Delay: Inline kritisk CSS, defer ikke-kritisk CSS og JS, optimer webfonte med font-display: swap.
  7. Fjern loading="lazy" fra LCP-billedet.
  8. Sæt fetchpriority="low" på ikke-kritiske above-the-fold billeder.
  9. Angiv altid width og height på alle billeder.
  10. Test med CrUX feltdata — ikke kun Lighthouse lab-scores.
  11. Overvej SSR/SSG i stedet for client-side rendering.
  12. Implementér Speculation Rules for instant efterfølgende navigationer.

Konklusion: LCP er fundamentet for brugeroplevelsen

LCP er den Core Web Vital, der mest direkte afspejler, om din side føles hurtig for brugeren. Og tallene bekræfter det: websites der opfylder alle tre Core Web Vitals-tærskelværdier ser 24 % lavere bounce rates og målbart bedre organiske placeringer.

Med LCP's nye cross-browser tilgængelighed fra december 2025 og de detaljerede underdelsdata, Google nu stiller til rådighed, har du aldrig haft bedre værktøjer til at diagnosticere og løse LCP-problemer.

Nøglen er en systematisk tilgang: identificér dit LCP-element, mål de fire underdele, og optimer den flaskehals, der giver størst effekt. Start dér — ikke med tilfældige optimeringer.

Husk også, at LCP-optimering ikke er en engangsopgave. Nye features, tredjepartsscripts og indholdsændringer kan gradvist forværre din LCP over tid. Sæt monitorering op med web-vitals-biblioteket, og hold øje med dine CrUX-data, så du kan reagere, før problemerne bliver synlige for brugerne.

Start med at identificere dit LCP-element i dag, og brug teknikkerne fra denne guide til at bringe din side under 2,5-sekunders-tærsklen. Dine brugere — og dine søgemaskineplaceringer — vil takke dig for det.

Om Forfatteren Editorial Team

Our team of expert writers and editors.

Relaterede Artikler