Fiks og identifiser Largest Contentful Paint (LCP)-problemer

En konsulents guide til diagnostisering og fiksing av LCP

Mitt navn er Arjen Karel, og jeg er en page speed-konsulent. Gjennom årene har jeg revidert hundrevis av nettsteder, og en av de mest vedvarende utfordringene er Largest Contentful Paint (LCP). I denne guiden deler jeg den eksakte metodikken jeg bruker for å diagnostisere og løse LCP-problemer. Du vil se omtaler av CoreDash, et RUM-verktøy jeg har laget for å få de presise dataene som trengs for denne prosessen. Prinsippene her er universelle, men jeg tror på å vise virkelige eksempler fra verktøyene jeg bygger og bruker daglig.

Å forbedre LCP er en systematisk elimineringsprosess. Ved å følge en tydelig metodikk kan du effektivt diagnostisere flaskehalsene i sideinnlastingsprosessen og anvende målrettede fikser for å forbedre nettstedets ytelse og user experience.

Diagnostisk metodikk: Feltdata først, laboratoriedata etterpå

For å optimalisere effektivt må du ta i bruk en to-trinns diagnostisk arbeidsflyt. Dette sikrer at du løser problemer brukerne dine faktisk opplever, ikke bare jager poeng i et laboratoriemiljø.

1. Feltdata (RUM & CrUX) viser deg HVA som skjer. Feltdata samles inn fra virkelige brukere som besøker nettstedet ditt [1]. Det forteller deg om du har et LCP-problem, hvilke sider som er berørt, og hvilke brukere (mobil eller desktop) som opplever det. Du må alltid starte her for å bekrefte at et reelt problem eksisterer.
2. Laboratoriedata (Lighthouse, DevTools) hjelper deg å diagnostisere HVORFOR det skjer. Laboratoriedata samles inn i et kontrollert, simulert miljø [2]. Når feltdataene dine har bekreftet et problem på en spesifikk side, kan du bruke laboratorieverktøy for å konsekvent reprodusere problemet og dissekere innlastingsprosessen for å finne rotårsaken.

Å starte med feltdata sikrer at optimaliseringsinnsatsen din er fokusert på endringer som vil ha en målbar innvirkning på de faktiske brukerne dine.

Trinn 1: Identifiser LCP-problemer med feltdata

Din første oppgave er å bruke data fra virkelige brukere for å bekrefte hvilke sider, om noen, som har en dårlig LCP.

Et tilgjengelig utgangspunkt: Google Search Console

Et godt sted å starte er Core Web Vitals-rapporten i Google Search Console. Logg inn, naviger til rapporten, og gjennomgå diagrammene for mobil og desktop. Hvis Google flagger URL-er med «LCP issue: longer than 2.5s», har du bekreftelse fra Chrome User Experience (CrUX) Report at en andel av brukerne dine har en dårlig opplevelse.

Selv om Search Console er uvurderlig for å bekrefte et problem, er den treg til å oppdatere og grupperer data etter URL-mønstre. For mer umiddelbare og detaljerte innsikter kreves et dedikert RUM-verktøy.

Et dypere blikk: Real User Monitoring (RUM)

For å få det fullstendige bildet kan du spore LCP for hver bruker ved hver sideinnlasting ved hjelp av en Real User Monitoring (RUM)-løsning. Selv om du kan bygge din egen ved å bruke web-vitals-biblioteket for å sende data til analysebackenden din, kan dette kreve betydelig utviklingsinnsats.

Alternativt er dedikerte RUM-verktøy designet for dette formålet. Verktøy som CoreDash er bygget for å levere disse dataene rett ut av boksen. Oppsett innebærer vanligvis å legge til en liten JavaScript-kodesnutt i nettstedets header. Når det er installert, begynner det å samle ytelsesdata fra hver virkelige besøkende.

Et godt RUM-verktøy hjelper deg å gå utover URL-grupper for å forstå:

• Din presise LCP-poengsum for enhver spesifikk URL.
• En oversikt over hvert LCP-element (f.eks. et bilde, en overskrift) og hvilke som oftest er forbundet med en treg LCP.
• Den eksakte tidsmålingen for hver av de fire LCP-fasene for hver sidevisning, som peker ut flaskehalsen.

Under en nylig revisjon for en e-handelsklient så vi høye LCP-verdier på produktsider til tross for et fullt optimalisert hero-bilde. RUM-dataene våre avslørte at forsinkelsen ikke var selve bildet, men et klientside A/B-testskript som dynamisk endret produkttittelen, som var LCP-elementet. Dette skriptet blokkerte rendering lenge nok til å dytte LCP inn i «dårlig»-kategorien. Å pause testen løste umiddelbart problemet, noe som beviser at LCP-optimalisering krever at man ser utover bare selve LCP-elementet.

For eksempel, i CoreDash kan du navigere til LCP-siden og se en datatabell som viser dine tregest LCP-elementer. Ved å klikke på et spesifikt element (som en bestemt CSS-klasse for et hero-bilde), kan du filtrere alle målingene for å se ytelsesdataene kun for sider der det elementet var LCP.

Enten du bruker en egendefinert løsning eller et verktøy som CoreDash, er målet det samme: bruk feltdata for å finne din tregest side og identifisere det vanligste LCP-elementet. Når du har det målet, er du klar til å diagnostisere.

Trinn 2: Diagnostiser flaskehalsen med laboratorieverktøy

Nå som du vet hvilken side du skal fikse, er det på tide å finne ut hvorfor den er treg. Det er her et laboratorieverktøy som PageSpeed Insights eller Lighthouse-panelet i Chrome DevTools blir essensielt [3].

Kjør en test på mål-URL-en din. I rapporten, bla ned til «Diagnostics»-seksjonen og finn «Largest Contentful Paint element»-revisjonen. Dette fossefallsdiagrammet bryter ned LCP-tiden din i fire deler. RUM-verktøyet ditt bør vise en lignende fordeling basert på feltdataene dine.

Målet ditt er å finne den lengste fasen i denne fordelingen. Det er din primære flaskehals, og det er der du bør fokusere optimaliseringsinnsatsen din først.

Trinn 3: Forstå den virkelige flaskehalsen

I de fleste virkelige scenarioer kommer de mest betydelige og vedvarende LCP-problemene fra en av de tre andre fasene.

• Time to First Byte (TTFB): Dette er det uunngåelige fundamentet. Et tregt serversvar er et direkte, millisekund-for-millisekund tillegg til LCP-en din. Før du optimaliserer et eneste bilde, må du sørge for at serveren din svarer raskt.
• Resource Load Delay: Dette er «oppdagelsesproblemet» og et av de vanligste problemene. Nettleseren kan ikke laste ned en ressurs den ikke vet om. Hvis LCP-bildet ditt er skjult i en CSS- eller JavaScript-fil, eller selv om det er i HTML-en men andre ressurser blir forespurt først, finner nettleseren det for sent, noe som sløser verdifull tid.
• Element Render Delay: Dette er «for opptatt til å tegne»-problemet. LCP-bildefilen kan være fullstendig nedlastet, men hvis nettleserens hovedtråd er blokkert av tung JavaScript-kjøring, kommer den rett og slett ikke til å tegne bildet på skjermen.

Den følgende guiden er strukturert for å takle disse fasene i en logisk rekkefølge. Start alltid med å sørge for at TTFB er rask og at LCP-ressursen din er oppdagbar, før du går videre til filstørrelse- og renderingsoptimaliseringer.

Trinn 4: Utfør fiksen

Med flaskehalsen identifisert kan du anvende målrettede optimaliseringer. Måten du implementerer disse fiksene på vil i stor grad avhenge av nettstedets arkitektur. Vi dekker først de universelle prinsippene for hver fase, deretter gir vi spesifikke råd for WordPress og moderne JavaScript-rammeverk.

1. Optimalisering av Time to First Byte (TTFB)

Hvis TTFB er treg (et godt mål er under 800ms [4]), setter det et høyt gulv for LCP-en din. Å forbedre TTFB vil forbedre alle andre innlastingsmålinger. Dette er tiden det tar for nettleseren å motta den første byten av HTML fra serveren din.

Universelle TTFB-løsninger

• Aktiver hurtigbufring: Dette er en av de mest effektive måtene å forbedre TTFB på. Hurtigbufring genererer og lagrer en kopi av siden slik at den kan serveres umiddelbart uten å vente på at serveren bygger den fra bunnen av ved hvert besøk.
• Bruk et CDN: Et Content Delivery Network serverer innholdet ditt fra en server fysisk nær brukeren din, noe som reduserer nettverksforsinkelse [5]. Å hurtigbufre fullstendige HTML-sider på CDN-ens edge er en kraftig strategi for en rask, global TTFB.
• Bruk Brotli- eller Gzip-komprimering: Sørg for at serveren din komprimerer tekstbaserte ressurser som HTML, CSS og JavaScript. Brotli tilbyr bedre komprimering enn Gzip og bør foretrekkes.
• Bruk HTTP/3 med 0-RTT: Sørg for at serveren din er konfigurert til å bruke HTTP/3. Det tilbyr betydelige ytelsesfordeler, inkludert bedre multipleksing. Avgjørende er at det støtter 0-RTT (Zero Round Trip Time Resumption), som eliminerer tilkoblingsoppsettstiden for gjenbesøkende, og gir en umiddelbar TTFB-forbedring [6].
• Bruk 103 Early Hints: For en avansert forbedring, bruk 103 Early Hints-statuskoden. Dette lar serveren eller CDN-en din sende hint om kritiske CSS- og JS-filer til nettleseren mens den fortsatt forbereder det fullstendige HTML-dokumentet, slik at nedlastinger kan starte enda tidligere [7]. Dette er en kraftig funksjon på servernivå som kan komme enhver plattform til gode.

Plattformspesifikke TTFB-fikser

På WordPress:

• Invester i kvalitetshosting: På WordPress er treg TTFB ofte relatert til hostingmiljøet. Billig, delt hosting kan være en flaskehals. Vurder en administrert WordPress-host som er optimalisert for ytelse.
• Bruk en hurtigbufringsplugin: En hurtigbufringsplugin av høy kvalitet (f.eks. WP Rocket, W3 Total Cache) er uunnværlig. Den håndterer genereringen av statiske HTML-filer for deg, som er kjernen i effektiv hurtigbufring på denne plattformen.

På et JS-rammeverk:

• Velg riktig hostingplattform: For Node.js-applikasjoner er plattformer som Vercel eller Netlify svært optimaliserte for SSR/SSG-rammeverk og tilbyr intelligent hurtigbufring og serverløs funksjonskjøring rett ut av boksen.
• Implementer SSR-hurtigbufring: Hvis du bruker Server-Side Rendering, hurtigbufre de rendrede sidene på serveren (f.eks. ved å bruke Redis eller en in-memory-hurtigbuffer) for å unngå re-rendering ved hver forespørsel.
• Vær oppmerksom på serverløse kaldstarter: Hvis du bruker serverløse funksjoner for rendering, vær klar over at en «kaldstart» (den første forespørselen etter en periode med inaktivitet) kan ha en høy TTFB. Bruk forhåndstildelt samtidskapasitet eller keep-alive-strategier for å redusere dette.

2. Redusering av Resource Load Delay

Dette er ofte den største flaskehalsen. Det betyr at nettleseren var klar til å jobbe, men den kunne ikke finne hovedbildet eller skriftfilen din med en gang. Denne forsinkelsen er vanligvis forårsaket av ett av to problemer: ressursen oppdages sent, eller den får lav nedlastingsprioritet.

Universelle Load Delay-løsninger

Den universelle løsningen på Resource Load Delay er å sørge for at LCP-ressursen din både er oppdagbar i den opprinnelige HTML-markeringen og gis høy prioritet av nettleseren. Slik oppnår du det:

• Gjør LCP-ressursen oppdagbar: Det viktigste trinnet er å sørge for at LCP-elementet ditt er til stede i HTML-en serveren sender. Nettlesere bruker en høyhastighets «preload scanner» for å se fremover i rå HTML etter ressurser som bilder og skript å laste ned. Hvis LCP-bildet ditt lastes via en CSS background-image eller injiseres med JavaScript, er det usynlig for denne skanneren, noe som forårsaker en betydelig forsinkelse. Den mest robuste løsningen er alltid å bruke en standard <img>-tagg med et src-attributt i den serverrendrede HTML-en din.
• Kontroller innlastingsrekkefølgen med preload: Hvis du ikke kan gjøre LCP-ressursen direkte oppdagbar (et vanlig problem med skrifttyper eller CSS-bakgrunnsbilder), er den nest beste løsningen å bruke <link rel="preload">. Denne taggen fungerer som en eksplisitt instruksjon i HTML-ens <head>, som forteller nettleseren å begynne å laste ned en kritisk ressurs mye tidligere enn den ville ha funnet den naturlig. Dette er essensielt for å endre den absolutte innlastingsrekkefølgen, og sikre at LCP-bildet eller skrifttypen din settes i kø før mindre kritiske ressurser som asynkrone JavaScript-filer.
• Sikre høy prioritet med fetchpriority: Selv når en ressurs er oppdagbar, gir nettleseren den kanskje ikke høyeste nedlastingsprioritet. Å legge til fetchpriority="high" på <img>-taggen din eller <link rel="preload">-taggen din er et kraftig hint til nettleseren om at denne spesifikke ressursen er den viktigste for user experience, og hjelper den å vinne kampen om båndbredde mot andre ressurser [8].

Plattformspesifikke Load Delay-fikser

På WordPress:

• Unngå Page Builder-bakgrunnsbilder: Mange sidbyggere gjør det enkelt å sette et hero-bilde som en CSS background-image på en div. Dette gjør det usynlig for nettleserens preload scanner. Hvis mulig, bruk en standard <img>-blokk i stedet. Hvis ikke, kan du trenge en plugin eller egendefinert kode for å bruke preload på det spesifikke bildet.
• Deaktiver lazy-loading for LCP-bildet: Mange optimaliseringsplugins vil automatisk lazy-loade alle bilder. Du må finne innstillingen i pluginen din for å ekskludere LCP-bildet (og ofte de første bildene på siden) fra å bli lazy-loadet.

På et JS-rammeverk:

• Bruk Server-Side Rendering (SSR): Dette er ofte den mest virkningsfulle fiksen. En standard Client-Side Rendered (CSR) React-app sender minimal HTML, og LCP-elementet eksisterer kun etter at en stor JS-pakke er lastet ned og kjørt. SSR-rammeverk som Next.js eller Remix leverer den fullstendige HTML-en, inkludert <img>-taggen, slik at nettleseren kan oppdage den umiddelbart.
• Bruk rammeverksspesifikke bildekomponenter: Rammeverk som Next.js tilbyr en <img>-komponent med en priority-prop. Ved å bruke <img ...="" priority=""> brukes automatisk fetchpriority="high" og andre optimaliseringer på LCP-bildet ditt.

3. Redusering av Resource Load Time

Å sørge for at LCP-ressursen din er så liten som mulig er fortsatt en avgjørende del av prosessen. Denne fasen handler om hvor lang tid det tar å laste ned LCP-ressursfilen over nettverket.

Universelle Load Time-løsninger

• Reduser filstørrelse med moderne formater og responsive bilder: Den mest direkte måten å forkorte nedlastingstiden er å gjøre filen mindre. For bilder betyr dette å bruke moderne, svært effektive formater som AVIF eller WebP [9]. Det er avgjørende at du også serverer responsive bilder ved hjelp av <picture>-elementet eller srcset- og sizes-attributtene. Dette sikrer at en bruker på en mobilenhet mottar et bilde med passende størrelse for den mindre skjermen, i stedet for å bli tvunget til å laste ned et massivt bilde i desktopstørrelse. En 400 piksler bred mobilskjerm trenger rett og slett ikke en 2000 piksler bred bildefil. For tekstbaserte LCP-er, sørg for at skrifttypene dine er i det effektive WOFF2-formatet og er subsettede for å fjerne ubrukte tegn.
• Reduser nettverkskonkurranse: LCP-ressursen må konkurrere om brukerens begrensede nettverksbåndbredde. Å utsette ikke-kritiske ressurser, som analyseskript eller CSS for innhold under folden, frigjør båndbredde slik at nettleseren kan fokusere på å laste ned LCP-ressursen raskere.
• Host kritiske ressurser på hoveddomenet ditt: Unngå å laste LCP-ressursen fra et annet domene hvis mulig. Å sette opp en ny tilkobling til en annen server legger til tidkrevende DNS-oppslag og handshakes.

Plattformspesifikke Load Time-fikser

På WordPress:

• Bruk en bildeoptimaliseringsplugin: Verktøy som ShortPixel eller Smush kan automatisk komprimere bilder ved opplasting, konvertere dem til moderne formater som WebP/AVIF, og generere responsive srcset-størrelser.
• Endre størrelse på bilder manuelt: Før opplasting, endre størrelsen på bildene dine til å ikke være større enn de trenger å være. Ikke last opp et 4000px bredt bilde for et område som bare er 1200px bredt på de største skjermene.

På et JS-rammeverk:

• Bruk et bilde-CDN: Dette er en kraftig løsning. Tjenester som Cloudinary, Imgix, eller Akamai Image & Video Manager kan automatisere hele optimaliseringsprosessen. Du laster opp ett bilde i høy kvalitet, og de leverer en perfekt tilpasset, komprimert og formatert versjon til hver bruker via et raskt CDN.
• Utnytt byggeverktøy: Når du importerer et bilde (import) inn i en komponent i et moderne rammeverk, kan byggeverktøyet (som Webpack eller Vite) automatisk hashe og optimalisere filen som en del av byggeprosessen.

4. Forkorting av Element Render Delay

Ressursen er ferdig nedlastet, men den er ikke på skjermen ennå. Dette betyr at nettleserens hovedtråd er opptatt med andre oppgaver og ikke kan tegne elementet. Dette er en annen svært vanlig og betydelig flaskehals.

Universelle Render Delay-løsninger

• Utsett eller fjern ubrukt JavaScript: All JavaScript som ikke er essensiell for å rendere den opprinnelige, synlige delen av siden bør utsettes ved hjelp av defer- eller async-attributtene.
• Bruk kritisk CSS: Et stort, renderingsblokkerende stilark kan forsinke rendering. Kritisk CSS-teknikken innebærer å trekke ut minimum CSS som trengs for å style innholdet over folden, inline det i <head>, og laste resten av stilene asynkront [10].
• Del opp lange oppgaver: Et langvarig skript kan blokkere hovedtråden i en lengre periode og forhindre rendering. Dette er også en primær årsak til dårlig Interaction to Next Paint (INP). Del opp koden din i mindre, asynkrone biter som gir tilbake (yield) til hovedtråden.

Plattformspesifikke Render Delay-fikser

På WordPress:

• Revider pluginene dine: For mange plugins, spesielt tunge som skyveknapper eller komplekse sidebyggere, kan legge til betydelig CSS og JavaScript som blokkerer hovedtråden. Deaktiver plugins én etter én for å identifisere ytelsestyver.
• Bruk et lettvektstema: Et oppblåst tema med dusinvis av funksjoner du ikke bruker kan være en stor kilde til renderingsblokkerende kode. Velg et ytelsesfokusert tema.
• Bruk plugin-ressursforvaltere: Verktøy som Asset CleanUp eller Perfmatters lar deg betinget deaktivere CSS og JavaScript fra spesifikke plugins på sider der de ikke trengs.

På et JS-rammeverk:

• Kodedeling er nøkkelen: Ikke send all appens JavaScript i én gigantisk pakke. Del koden din etter rute (slik at brukere bare laster ned koden for siden de besøker) og etter komponent.
• Lazy-load komponenter: Bruk React.lazy og Suspense for å lazy-loade komponenter som ikke er umiddelbart synlige (f.eks. komponenter under folden eller i modaler). Dette holder dem utenfor den opprinnelige pakken.

Avansert: Optimalisering av LCP for påfølgende navigasjoner

Å fikse den opprinnelige LCP er avgjørende, men du kan skape en dramatisk raskere opplevelse for brukere når de surfer på nettstedet ditt ved å optimalisere for påfølgende sideinnlastinger.

Sørg for at sider er kvalifisert for Back/Forward Cache (bfcache)

bfcache er en nettleseroptimalisering som lagrer et fullstendig øyeblikksbilde av en side i minnet når en bruker navigerer bort. Hvis de klikker tilbakeknappen, kan siden gjenopprettes umiddelbart, noe som resulterer i en nesten-null LCP. Mange sider er ikke kvalifisert for denne hurtigbufferen på grunn av ting som unload-hendelseslyttere. Bruk Lighthouse «bfcache»-revisjonen for å teste sidene dine og fjerne eventuelle blokkerende funksjoner [11].

Bruk Speculation Rules API for forhåndsrendering

Speculation Rules API er et nytt, kraftig verktøy som lar deg deklarativt fortelle nettleseren hvilke sider en bruker sannsynligvis vil navigere til neste. Nettleseren kan deretter hente og forhåndsrendere disse sidene i bakgrunnen. Når brukeren klikker en lenke til en forhåndsrendret side, er navigasjonen umiddelbar, noe som gir en fenomenal user experience og en nesten-null LCP [12]. Du kan definere disse reglene i en <script type="speculationrules">-tagg i HTML-en din.

<script type="speculationrules"> 
 { 
  "prerender": [{ 
   "source": "document", 
   "where": { 
    "href_matches": "/products/*" 
   }, 
   "eagerness": "moderate" 
  }] 
 } 
 </script>  

Dette eksemplet forteller nettleseren å lete etter lenker på gjeldende side som går til produktsider og å begynne å forhåndsrendre dem når en bruker holder musepekeren over lenken.

Ved å metodisk jobbe gjennom disse fire fasene og vurdere avanserte navigasjonsoptimaliseringer, kan du finne den eksakte årsaken til LCP-problemene dine og anvende den korrekte, høyeffektive fiksen.

Referanser

1. web.dev: Lab and field data
2. Chrome for Developers: Debug Web Vitals in the field
3. web.dev: Optimize Largest Contentful Paint
4. web.dev: Optimize for a good TTFB
5. Cloudflare: What is a CDN?
6. web.dev: HTTP/3
7. web.dev: Slower is faster? Sending an HTTP 103 response to speed up your site
8. web.dev: Optimize LCP with fetchpriority
9. web.dev: Use modern image formats
10. web.dev: Extract critical CSS
11. web.dev: Back/forward cache
12. web.dev: Speculation Rules API