Optimaliser LCP Resource Load Delay

Optimaliser LCP Resource Load Delay

Largest Contentful Paint (LCP) består av fire faser: TTFB, Resource Load Delay, Resource Load Duration og Element Render Delay. Utviklingsinnsatsen fokuserer ofte på å redusere Load Duration via filkomprimering, men dette overser Resource Load Delay, som ofte er en større kilde til forsinkelse. Denne forsinkelsen før nedlastingen begynner kan legge til hundrevis av millisekunder til LCP-en din, slik at den overskrider terskelen på 2,5 sekunder for «Good». 

Et raskt tips: hvis LCP-elementet ditt er et bilde, vil det nesten alltid være dårligere enn tekst. Du må spore LCP-elementtypene dine i RUM-dataene, ellers navigerer du i blinde.

Presis definisjon: Den kritiske ventetiden før nedlastingen

Resource Load Delay er tiden mellom TTFB og når nettleseren starter nedlastingen av LCP-ressursen. Det er ikke nedlastingstiden; det er oppdagelsesforsinkelsen som oppstår før hentingen begynner. En høy verdi her indikerer et arkitektonisk problem der nettleseren ikke kan finne ressurs-URL-en i den opprinnelige HTML-en.  Denne Resource Load Delay kan sees som tiden nettleseren bruker på å identifisere at LCP-ressursen er nødvendig og bestemme seg for å hente den.

For LCP-elementer som er tekstbaserte og gjengis med en systemskrifttype, er denne Resource Load Delay vanligvis null fordi ingen ekstern ressurs trenger å hentes. Høyere Resource Load Delay-verdier er spesifikke for LCP-elementer som er avhengige av en ekstern nettverksressurs som et bilde eller en videofil.

Oppdagelsesmotoren: Preload Scanner vs. DOM Parser

For å redusere Resource Load Delay må du forstå hvordan nettlesere oppdager ressurser. Effektiviteten i denne oppdagelsesprosessen er den primære faktoren som bestemmer forsinkelsen. Nettlesere bruker to mekanismer: en rask vei og en treg vei.

• Preload Scanner (den raske veien): Preload Scanner (rask vei): Dette er en sekundær parser med høy hastighet som skanner rå HTML for ressurs-URL-er, som de i <img>- eller <link>-tagger. Den legger dem i kø for nedlasting umiddelbart, før CSS er parset eller JavaScript er kjørt. Dette er den optimale veien for enhver kritisk ressurs.
• DOM Parser (treg vei): Dette er hovedparseren som bygger den fullstendige Document Object Model (DOM) og CSS Object Model (CSSOM). Ressurser som ikke finnes i den opprinnelige HTML-en, som et CSS background-image eller et element injisert av JavaScript, oppdages kun av denne parseren. Dette er den trege veien fordi den er avhengig av at andre filer lastes ned og kjøres først, noe som skaper en kjede av avhengigheter som introduserer høy forsinkelse.

Hele strategien for å optimalisere Resource Load Delay er basert på ett prinsipp: sørg for at LCP-ressursens URL er oppdagbar av preload-skanneren. Ethvert mønster som skjuler URL-en fra det opprinnelige HTML-dokumentet tvinger nettleseren til å bruke den trege oppdagelsesveien. Denne venteperioden oversettes direkte til Resource Load Delay. Enhver effektiv optimalisering handler om å arkitekturere HTML-en din for å plassere LCP-ressursen på den raske veien

Hvorfor Load Delay er viktig

En vanlig misforståelse er at en treg LCP er et «filstørrelse»-problem. Dette fører til at team kun fokuserer på bildekomprimering for å redusere Resource Load Duration. Selv om optimalisering av ressurser er en faktor, viser analyse av feltdata fra den virkelige verden at for mange nettsteder med dårlig LCP er Resource Load Delay den primære ytelsesflaskehalsen, ikke Resource Load Duration.

Feltdata viser at mediannettsiden med en dårlig LCP-score har en Resource Load Delay på 1,3 sekunder. Det er over halvparten av hele budsjettet på 2,5 sekunder for en «Good» LCP-score, alt forbrukt før nedlastingen av LCP-ressursen i det hele tatt starter. Dataene indikerer at disse nettstedene bruker nesten fire ganger så lang tid på å vente på at nedlastingen skal begynne som de bruker på selve nedlastingen.

Disse dataene avslører en hyppig feilretning av utviklingsinnsats. Team kan bruke uker på å fjerne kilobytes fra bilder for å forkorte Load Duration med noen få millisekunder, mens et arkitektonisk problem som forårsaker 1,5 sekunders Load Delay forblir uadressert. LCP er en sekvensiell prosess; en forsinkelse i en tidlig fase kan ikke hentes inn ved å optimalisere en senere fase. Hvis en henting er forsinket med over et sekund, er en forskjell på 100 ms i nedlastingstid irrelevant for den endelige LCP-scoren. Optimaliseringene med størst effekt involverer arkitektoniske endringer, som å forbedre ressursoppdagbarhet, ikke bare komprimering av ressurser. Fokuset må flyttes fra å gjøre ressurser mindre til Disse dataene avslører en hyppig feilretning av utviklingsinnsats. Team kan bruke uker på å fjerne kilobytes fra bilder for å forkorte Load Duration med noen få millisekunder, mens et arkitektonisk problem som forårsaker 1,5 sekunders Load Delay forblir uadressert. LCP er en sekvensiell prosess; en forsinkelse i en tidlig fase kan ikke hentes inn ved å optimalisere en senere fase. Hvis en henting er forsinket med over et sekund, er en forskjell på 100 ms i nedlastingstid irrelevant for den endelige LCP-scoren. Optimaliseringene med størst effekt involverer arkitektoniske endringer, som å forbedre ressursoppdagbarhet, ikke bare komprimering av ressurser. Fokuset må flyttes fra å gjøre ressurser mindre til å sørge for at de oppdages tidligere..

Hvordan oppdage Resource Load Delay

For å fikse Resource Load Delay må du først måle den nøyaktig. Den profesjonelle arbeidsflyten er å først definere problemet med ekte brukerdata (RUM), og deretter gå til Chrome DevTools for dybdeanalyse.

Steg 1: Analyser feltdata (RUM)

Feltdata, eller Real User Monitoring (RUM), samles inn fra faktiske brukerøkter. RUM-verktøy, som den offentlige Chrome User Experience Report (CrUX) eller mitt eget verktøy, CoreDash, svarer på spørsmålet: Hva skjer i den virkelige verden? Et omfattende RUM-verktøy vil også gi en nedbrytning av LCP-delene, som viser deg median Resource Load Delay på tvers av brukerne dine. Disse dataene bekrefter at et LCP-problem eksisterer, viser hvilke URL-er som er berørt, og avslører de vanlige LCP-elementene brukerne dine faktisk ser. Du må starte her for å bekrefte at du løser et reelt problem.

Steg 2: Diagnostiser med DevTools

Når RUM-dataene dine har identifisert en målside og et LCP-element, bruker du Chrome DevTools til å diagnostisere årsaken. Målet her er å reprodusere problemet og måle LCP-delene for å få en presis Resource Load Delay-verdi. DevTools er også der du utfører en hovedtrådsanalyse for å se nøyaktig hvilke oppgaver som kjører og potensielt blokkerer gjengivelsesprosessen.

En trinnvis guide til Chrome DevTools Performance-panelet

Performance-panelet i Chrome DevTools er et uunnværlig verktøy for å dissekere LCP og kvantifisere Load Delay.

1. Oppsett og konfigurasjon:

• Åpne Chrome DevTools ved å høyreklikke på siden og velge «Inspiser» eller bruke hurtigtasten Ctrl+Shift+I (Windows/Linux) eller Cmd+Option+I (Mac).   
• Naviger til Performance-fanen.
• Sørg for at Web Vitals-avkrysningsboksen er aktivert i opptaksinnstillingene. Dette vil legge Core Web Vitals-informasjon over ytelsestidslinjen.   
• For å simulere realistiske brukerforhold, bruk CPU- og nettverksstruping. En «4x slowdown» for CPU og en «Fast 3G»- eller «Slow 4G»-nettverksprofil er vanlige utgangspunkt for mobiltesting.   

2. Ta opp en ytelsesprofil:

• Klikk på «Record and reload page»-knappen (et sirkulært pilikon) i Performance-panelet. Dette vil starte et opptak, laste siden på nytt, og deretter stoppe opptaket når siden er fullstendig lastet.   

3. Analyse og tolkning:

• Timings Track: I hovedtidslinje-visningen, finn Timings-sporet. Du vil se en markør merket LCP. Å holde musepekeren over denne markøren vil fremheve det tilsvarende LCP-elementet i hovedvisningsbildet og vise total LCP-tid.   
• LCP etter fasenedbrytning: Klikk på LCP-markøren i Timings-sporet. I Summary-fanen nederst i panelet finner du en detaljert nedbrytning av LCP-timingen. Denne nedbrytningen viser eksplisitt varigheten av hver av de fire delene, inkludert Load delay, målt i millisekunder. Denne verdien er den mest direkte og presise målingen av Resource Load Delay for den spesifikke sidelastingen.   
• Hovedtrådsanalyse: Mens du undersøker tidslinjen, se på Main-sporet for eventuelle lange oppgaver (aktivitetsblokker markert med en rød trekant). Hvis disse lange oppgavene oppstår etter at LCP-ressursen er ferdig lastet, men før LCP-markøren, bidrar de sannsynligvis til Element Render Delay, et relatert men distinkt problem.   

Vanlige årsaker og løsninger med stor effekt

En høy Resource Load Delay skyldes én av to ting: LCP-ressursen oppdages sent, eller den får en lav henteprioritet. Her er de vanligste arkitektoniske feilene og deres løsninger.

Årsak: LCP lastet via CSS

Problemet: Preload-skanneren parser ikke CSS-filer. Når LCP-bildet ditt er definert med et CSS background-image, er URL-en usynlig for denne høyhastighets-skanneren. Nettleseren kan kun oppdage bildet etter å ha lastet ned HTML-en, funnet CSS-fillenken, lastet ned CSS-filen, bygget CSSOM-en, og deretter brukt stilen. Denne avhengighetskjeden forårsaker direkte en høy Resource Load Delay.

Løsningen: Den korrekte implementeringen er å unngå bruk av background-image for ethvert kritisk LCP-element. Bruk en standard <img>-tag i stedet. Dette plasserer bilde-URL-en direkte i HTML-en der preload-skanneren kan finne den umiddelbart. Du kan oppnå det samme visuelle resultatet med CSS.

Implementeringseksempel:

Anti-mønster (ikke gjør dette):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Beste praksis (gjør dette i stedet):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="En beskrivende alt-tekst for hero-bildet"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Sidetittel</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Tilsvarer top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Denne egenskapen etterligner background-size: cover */
      z-index: -1; /* Plasserer bildet bak annet innhold */
    }
    

Denne implementeringen gir det samme visuelle resultatet, men gjør LCP-bildet oppdagbart på det tidligst mulige tidspunktet, noe som minimerer forsinkelsen ved lasting.

Årsak: Klientsidegjengiving og JavaScript-injeksjon

Problemet: Applikasjoner som bruker rammeverk for klientsidegjengiving (CSR) som React eller Vue serverer ofte en minimal HTML-skall. Det faktiske innholdet, inkludert LCP <img>-taggen, settes kun inn i DOM-en av JavaScript etter at store rammeverkspakker er lastet ned, parset og kjørt. Denne prosessen skjuler fundamentalt LCP-ressursen fra preload-skanneren, noe som skaper høy oppdagelsesforsinkelse.

Løsningen: Den mest effektive løsningen er å flytte den første gjengivelsen fra klienten til serveren.

• Server-Side Rendering (SSR) eller Static Site Generation (SSG): Arkitektoniske mønstre som SSR eller SSG genererer den fullstendige HTML-en på serveren. Nettleseren mottar et komplett dokument som inneholder <img>-taggen og dens src-attributt, noe som gjør LCP-ressursen umiddelbart oppdagbar av preload-skanneren. Dette er den påkrevde arkitekturen for enhver ytelseskritisk side.
• Rammeverksspesifikke optimaliseringer: Moderne rammeverk tilbyr også innebygde optimaliseringer. For eksempel har Next.js <Image>-komponenten en priority-egenskap. Å sette denne til true instruerer rammeverket til å automatisk legge til de korrekte <link rel="preload">- og fetchpriority="high"-attributtene, noe som sikrer at bildet oppdages og hentes med riktig prioritet.

Årsak: Bruk av loading="lazy" på LCP-bildet

Problemet: Dette er en hyppig feil med stor innvirkning. Attributtet loading="lazy" er en direkte instruksjon til nettleseren om å utsette henting av et bilde til det er nær visningsområdet. Selv om dette er riktig optimalisering for bilder under folden, er det kontraproduktivt å bruke det på et LCP-element over folden. Nettleserens preload-skanner er designet for å ignorere bilder med loading="lazy", noe som garanterer en sen oppdagelse og en høy Resource Load Delay.

Løsningen: Løsningen krever grundighet.

• Fjern loading="lazy" fra LCP-bildet: Ethvert bilde som sannsynligvis er LCP-elementet må ikke ha attributtet loading="lazy". Nettleserens standardoppførsel er loading="eager", som er riktig innstilling for kritisk innhold over folden. Å utelate loading-attributtet helt har samme effekt.
• Revider og konfigurer tredjepartsverktøy: Du må også revidere tredjepartsverktøy. Mange CMS-plattformer som WordPress og ulike bildeoptimaliserings-plugins bruker automatisk lazy loading på alle bilder. Det er essensielt å konfigurere disse verktøyene til å ekskludere LCP-bildet fra denne oppførselen. Dette innebærer ofte å opprette en unntaksregel for det første eller de to første bildene på siden.

Årsak: Suboptimal HTML-struktur og store dokumenter

Problemet: Preload-skanneren behandler HTML-dokumentet fra topp til bunn. Hvis ikke-kritiske men båndbreddeintensive ressurser, som header-ikoner eller chat-widget-skript, er plassert høyere i <body> enn LCP-elementet, blir de oppdaget og lagt i nedlastingskø først. Dette forbruker initial nettverksbåndbredde og kan forsinke nedlastingen av LCP-ressursen. Et stort HTML-dokument kan også være et problem; hvis LCP-elementet ikke er i den første datapakken nettleseren mottar (rundt 14 KB), forsinkes oppdagelsen med minst én nettverksrundtur.

Løsningen: Optimaliser strukturen og prioriteringen av innhold i HTML-en.

• Omorganiser HTML-en: Når det er mulig, sørg for at <img>-taggen eller tekstblokken for LCP-elementet vises så tidlig som mulig inne i <body>-taggen.
• Nedprioriter ikke-kritiske bilder: For ikke-essensielle bilder som må vises tidlig i HTML-kildekoden (som ikoner i en header), bruk loading="lazy". Dette forteller preload-skanneren å hoppe over dem, og bevarer nedlastingskøen for LCP-elementet.
• Utsett ikke-essensielle skript: Skript for analyse, annonser eller sosiale medier-widgets er sjelden kritiske for den første gjengivelsen. Flytt deres <script>-tagger til slutten av <body> eller bruk defer-attributtet. Dette forhindrer dem fra å blokkere parseren eller konkurrere om nettverksbåndbredde med LCP-ressursen.

Avansert prioritering med ressurshinvisninger

Når LCP-ressursen er oppdagbar i HTML-en, kan du bruke ressurshinvisninger for å gi nettleseren mer eksplisitte instruksjoner om hvordan den skal hentes. Disse hinvisningene gir finkornet kontroll over oppdagelse og prioritering.

Tvinge tidlig oppdagelse med <link rel="preload">

<link rel="preload"> er ikke en hinvisning; det er et direktiv. Det tvinger nettleseren til å laste ned en ressurs med høy prioritet, selv om den ennå ikke er oppdagbar av hovedparseren. Å plassere det i <head> av HTML-en din er den mest direkte måten å fikse problemer med sen oppdagelse for ressurser som fonter, CSS-bakgrunnsbilder eller LCP-bilder plassert dypt i DOM-en.

Mekanisme

Når en preload-lenke er plassert i <head> av HTML-dokumentet, identifiserer preload-skanneren den og legger umiddelbart den spesifiserte ressursen i nedlastingskø. Dette er ideelt for ressurser som fonter lastet via @font-face i et eksternt stilark, CSS background-image LCP-er (selv om bruk av en <img>-tag er foretrukket), eller et LCP-bilde som befinner seg dypt i en kompleks DOM-struktur.[3]

Responsiv forhåndslasting

En kritisk implementeringsdetalj er nødvendig ved forhåndslasting av responsive bilder. For å sikre at nettleseren forhåndslaster bildet med riktig størrelse for brukerens visningsområde og unngår en bortkastet dobbeltnedlasting, må <link rel="preload">-taggen inkludere imagesrcset- og imagesizes-attributter som perfekt speiler attributtene på den tilsvarende <img>-taggen.[4]

Eksempel på responsiv forhåndslasting:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="En beskrivende alt-tekst"
     fetchpriority="high"
     width="1200" height="675">
    

Potensiell fallgruve

Forhåndslasting løser hentetidspunktet (Load Delay og Load Duration), men ikke *gjengivelsestidspunktet*. Hvis hovedtråden er blokkert av tung JavaScript eller gjengivelsesblokkerende CSS når det forhåndslastede bildet ankommer, må bildet likevel vente på å bli gjengitt, noe som kan flytte flaskehalsen fra Load Delay til Element Render Delay.[5, 6]

Finjustering med fetchpriority="high": Vinne båndbreddekampen

fetchpriority-attributtet er en hinvisning som signaliserer den relative viktigheten av en ressurs sin nedlasting. Det lar deg påvirke en ressurs sin prioritet i nettleserens nedlastingskø.[7]

preload vs. fetchpriority

Disse to hinvisningene tjener forskjellige, men komplementære formål. preload påvirker når en ressurs oppdages og legges i køen. fetchpriority påvirker prioritetsnivået når den er i køen.

Beste praksis for LCP

For LCP-bildet er den optimale strategien å bruke dem sammen. Først, sørg for tidlig oppdagelse enten ved å plassere <img>-taggen tidlig i HTML-en eller ved å bruke preload. Deretter, legg til fetchpriority="high" direkte på <img>-taggen (og preload-lenken, hvis den brukes). Denne kombinasjonen sikrer at ressursen ikke bare oppdages tidlig, men også får høyest mulig prioritet for å vinne konkurransen om nettverksbåndbredde mot andre ressurser som stilark eller fonter.[3, 1, 7]

Eksempel:

<img src="lcp-image.jpg" fetchpriority="high" alt="Et kritisk hero-bilde">

Bevist effekt

I en casestudie som involverte Google Flights, var det å legge til fetchpriority="high" på LCP-bakgrunnsbildet avgjørende for å forbedre LCP-tiden fra 2,6 sekunder til 1,9 sekunder, en forbedring på 700 ms.[8]

Optimalisere tredjepartsforbindelser: preconnect og dns-prefetch

Problemet

Hvis LCP-ressursen din er hostet på et tredjepartsdomene, som et bilde-CDN eller en fonttilbyder som Google Fonts, må nettleseren etablere en ny nettverksforbindelse til det domenet. Denne prosessen innebærer et DNS-oppslag, et TCP-håndtrykk og en TLS-forhandling, som alle må fullføres før den første byten av ressursen kan lastes ned. Denne forbindelsesoppsettiden er en direkte bidragsyter til Resource Load Delay for ressurser fra andre domener.[9, 2, 10, 11]

Løsningene

• preconnect: Denne hinvisningen instruerer nettleseren til å utføre det fullstendige forbindelsesoppsettet (DNS, TCP og TLS) for et spesifisert tredjepartsdomene i bakgrunnen, på forhånd. Når ressursen faktisk blir forespurt, er forbindelsen allerede varm, noe som eliminerer oppsettforsinkelsen. Dette er svært effektivt og anbefalt for de én eller to mest kritiske tredjepartsdomenene som serverer LCP-ressurser.[2]
• dns-prefetch: Dette er en lettere hinvisning som kun utfører DNS-oppslaget for et domene. Den sparer mindre tid enn preconnect, men har bredere nettleserstøtte og er nyttig som fallback eller for mindre kritiske tredjepartsdomener.[2, 12]

Beste praksis for implementering

For å sikre maksimal kompatibilitet, oppgi begge hinvisningene. Nettleseren vil bruke preconnect hvis det støttes og falle tilbake til dns-prefetch hvis ikke. crossorigin-attributtet er essensielt for ressurser som hentes med CORS, som fonter.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabell: Sammenligning av ressurshinvisninger for LCP-optimalisering

For å forhindre feilbruk og klargjøre de distinkte rollene til disse kraftige hinvisningene, gir følgende tabell en sammenlignende oppsummering.

Helhetlige og fremtidsrettede strategier

Utover målrettede hinvisninger kan bredere arkitektoniske beslutninger og fremvoksende webplattformfunksjoner gi helhetlige og kraftige løsninger på Resource Load Delay.

Rollen til et moderne CDN

Et Content Delivery Network (CDN) er en grunnleggende teknologi for webytelse som indirekte, men betydelig, reduserer Resource Load Delay, spesielt for LCP-ressurser.

• Redusere forbindelseoverhead: Ved å distribuere ressurser over et globalt nettverk av servere plasserer et CDN innhold geografisk nærmere brukeren. Dette reduserer iboende rundturstiden (RTT) som kreves for DNS-oppslag, TCP-håndtrykk og TLS-forhandling, som alle er komponenter i forbindelsesoppsettiden.[13, 14, 15] For et LCP-bilde hostet på et CDN reduserer dette direkte forsinkelsen ved lasting.
• Bilde-CDN-er: Spesialiserte bilde-CDN-er tilbyr en dobbel fordel. De gir nærhetsfordelen til et standard CDN samtidig som de automatiserer mange komplekse optimaliseringer som reduserer Resource Load Duration, som bildeskalering i sanntid, komprimering og konvertering til moderne formater som AVIF og WebP.[9, 1]
• Avanserte protokoller: Mange moderne CDN-er bruker overlegne nettverksprotokoller som HTTP/3, som bruker QUIC i stedet for TCP. HTTP/3 reduserer forbindelsesoppsettiden og reduserer head-of-line-blokkering, noe som fører til raskere og mer effektiv ressurslevering totalt sett.[16]

Eliminere forsinkelse helt med Speculation Rules

Speculation Rules API er en banebrytende webplattformfunksjon som tilbyr potensialet til å eliminere LCP-forsinkelse helt for påfølgende navigasjoner.

Mekanisme

Denne API-en lar utviklere deklarativt informere nettleseren om hvilke URL-er en bruker sannsynligvis vil navigere til neste. Basert på disse reglene kan nettleseren velge å forhåndsgjengive en målside i en skjult bakgrunnsfane før brukeren i det hele tatt klikker på lenken.[3, 1, 16]

Effekt på LCP

Når brukeren klikker på en lenke til en forhåndsgjengitt side, er navigasjonen praktisk talt øyeblikkelig. Siden er allerede fullstendig lastet og gjengitt i bakgrunnen. For denne navigasjonen er TTFB, Resource Load Delay, Resource Load Duration og Element Render Delay alle effektivt redusert til nær null fra brukerens perspektiv.[3, 1, 16]

Eksempel på brukstilfelle

På en e-handels kategoriside kan speculation rules brukes til å forhåndsgjengive produktdetaljsidene for de første elementene i listen. Når en bruker klikker på et av disse produktene, vises siden øyeblikkelig, og gir en sømløs og eksepsjonelt rask opplevelse.

Casestudiesyntese: Fra teori til praksis

Effektiviteten av disse optimaliseringsstrategiene er ikke bare teoretisk; den demonstreres av data fra virkelige tester og scenarier.

• Case 1: Den transformative kraften til forhåndslasting: Et eksperiment utført av DebugBear på en side med høy Load Delay gir et dramatisk eksempel. LCP-bildet var skjult i en forespørselskjede, noe som førte til at Resource Load Delay utgjorde hele 75 % av den totale LCP-tiden. Ved å implementere en enkelt <link rel="preload">-hinvisning for å gjøre bildet oppdagbart tidlig, ble Resource Load Delay redusert til bare 2 % av LCP-tiden.[17] Dette viser hvordan en enkel arkitektonisk endring kan løse en massiv ytelsesflaskehals.
• Case 2: Anti-mønsteret loading="lazy" i den virkelige verden: En utvikler på Stack Overflow rapporterte en desktop-LCP med en forvirrende 1 430 ms Load Delay til tross for et raskt nettverk. Årsaken ble sporet til en bildeoptimaliserings-plugin som feilaktig brukte lazy loading på LCP-bildet ved å erstatte src-attributtet med en transparent plassholder-SVG. Den definitive løsningen var å deaktivere denne oppførselen for LCP-elementet, slik at det kunne oppdages og lastes ivrig.[18] Dette illustrerer hvordan tredjepartsverktøy utilsiktet kan introdusere alvorlige forsinkelser ved lasting.
• Case 3: Ytelsesforbedringen med fetchpriority: Google Flights-casestudien gir tydelig bevis for effekten av eksplisitt prioritering. Ved ganske enkelt å legge til fetchpriority="high" på sidens LCP-bakgrunnsbilde, forbedret LCP-scoren seg med 700 ms, fra 2,6 sekunder til 1,9 sekunder.[8] Dette demonstrerer at selv når en ressurs er oppdagbar, er det å signalisere dens høye viktighet til nettleseren et kritisk steg for å vinne kampen om nettverksbåndbredde.

Nettverksinspeksjon i Chrome DevTools: Bruk hurtigtasten Ctrl + Shift + I for å åpne Chromes Developer Tools, velg deretter «Network»-fanen og last siden på nytt. Se på lasterekkefølgen. LCP-ressursen din bør være blant de første elementene i nedlastingskøen. Hvis den ligger bak andre elementer, har du et Resource Load Delay-problem. Nedenfor er et eksempel på et nettsted der Resource Load Delay ikke er optimalisert.

Bruk Real User Monitoring (RUM)-data: Real User Monitoring-verktøy logger ofte LCP-attribusjonsdata. Med RUM kan du visualisere nedbrytningen av LCP-deler (over tid eller per side), noe som gir deg et tydelig bilde av Load Delay for LCP-elementer på tvers av hele nettstedet ditt eller per side. Eksempelet nedenfor viser en global LCP-nedbrytning sammen med den tilsvarende forsinkelsen ved lasting.

Hvordan forbedre Load Delay

En Resource Load Delay oppstår når nedlastingsrekkefølgen og timingen av ressurser ikke er optimal. Det er i essens to enkle måter å fikse dette på: prioriter LCP-ressursen eller nedprioriter ikke-LCP-ressurser. La oss utforske noen vanlige mønstre:

LCP-tips: Forstå Preload Scanner: Moderne nettlesere bruker en mekanisme kalt preload scanner, som raskt skanner HTML-en og legger ressurser i nedlastingskø. Hvis en ressurs ikke kan legges i kø av preload-skanneren, må den vente på den tregere DOM-parseren, noe som resulterer i forsinkelser. Å sørge for at LCP-ressursene dine er oppdagbare av preload-skanneren kan utgjøre en stor forskjell i å redusere Load Delay.

1. Optimaliser HTML-strukturen

Nettleseren (eller preload-skanneren) behandler HTML-en din fra topp til bunn, og legger ressurser i kø i rekkefølgen de vises. Dette betyr at jo høyere LCP-ressursen vises i HTML-en, desto raskere blir den lagt i kø. For å optimalisere dette, fjern eller utsett unødvendige ressurser fra toppen av HTML-en:

• Lazy-load uviktige eller skjulte bilder: Noen ganger finnes bilder (for eksempel flagg for språkspesifikke versjoner av nettstedet ditt eller bilder i menyen) helt øverst i nettstedets HTML. Disse bildene er langt fra like viktige som LCP-elementet. Ved å lazy-loade disse bildene hoppes de over av preload-skanneren og legges i kø litt senere i lasteprosessen.
  
• Flytt uviktige skript til bunnen av siden: Flytt skript som er helt uviktige for den innledende lastingen til bunnen av siden for å forhindre at de forsinker kritiske ressurser. For eksempel en chat-widget. Ingen i internettets historie har noensinne trengt å chatte før siden var synlig!

2. Unngå bakgrunnsbilder.

Bakgrunnsbilder er usynlige for preload-skanneren, noe som betyr at de alltid vil bli lagt i kø av den mye tregere DOM-parseren. For å unngå denne forsinkelsen, bruk en vanlig <img>-tag i stedet, kombinert med CSS-egenskapen object-fit: cover for å etterligne utseendet til et bakgrunnsbilde. På denne måten kan preload-skanneren oppdage og legge bildet i kø umiddelbart.

3. Bruk Fetch Priority

Legg til fetchpriority="high"-attributtet på LCP-elementet ditt for å signalisere til nettleseren at den bør prioritere denne ressursen helt fra starten. Normalt lastes bilder med en standard lav eller medium prioritet. Under layoutfasen oppgraderer nettleseren synlige elementer til høy prioritet. Ved å sette fetchpriority="high" begynner nedlastingen umiddelbart med høy prioritet, noe som sikrer raskere LCP. 

Fetchpriority er vanligvis mindre inngripende (og mindre effektiv) enn forhåndslasting fordi den setter den relative prioriteten til et element (i dette tilfellet er bildet relativt viktigere enn andre bilder), men den gjør det ikke viktigere enn for eksempel stilark eller ikke-blokkerende skript

<img src="hero-image.jpg" alt="Hero-bilde" fetchpriority="high">

4. Implementer forhåndslasting

Forhåndslasting endrer rekkefølgen preload-skanneren legger filer i kø. Plasser <link rel="preload">-taggen i head på siden for å instruere nettleseren til å hente kritiske ressurser, som LCP-bildet, så tidlig som mulig. Preloads kan brukes til å forhåndslaste ressurser som refereres senere i HTML-en (og derfor legges i kø senere) eller til og med for å forhåndslaste ressurser som ennå ikke er referert i HTML-en (som med noen slidere). For maksimal effektivitet anbefales det å plassere preloads etter stilark og før skript i head på siden 

<link rel="preload" as="image" href="hero-image.jpg">

5. Optimaliser stilark

Stilark legges normalt i kø før LCP-ressursen, og det er med god grunn. Uten stilark vil ikke nettleseren vite hvordan siden skal se ut og kan ikke starte gjengivelsesfasen. Men overdreven CSS-størrelse og et overdrevent antall stilark vil konkurrere med LCP-ressursen om tidlig båndbredde.

6. Implementer effektiv Lazy-Loading

Loading-attributtet kan være et tveegget sverd. Bruk loading="eager" (eller utelat attributtet helt siden «eager» er nettleserens standard) for LCP-ressursen din, mens du bruker loading="lazy" for bilder utenfor skjermen.

• Eager-last LCP-elementet: Hvis LCP-elementet er lazy-loadet, vil det ikke bli lagt i kø av preload-skanneren og vil laste mye senere, noe som påvirker ytelsen negativt.
• Lazy-load visningsområdebilder: For bilder som er i det synlige visningsområdet men ikke er LCP-ressurser, bruk loading="lazy" for å legge dem i nedlastingskø litt senere. Dette reduserer båndbreddekonkurransen med LCP-ressursen.
• Unngå Lazy Loading av bilder utenfor skjermen: Bilder som ikke er i det synlige visningsområdet vil ikke utløse en nedlasting i det hele tatt, noe som fullstendig eliminerer båndbreddekonkurranse.

7. Nettleserbufring

Nettleserbufring lar deg hoppe over nettverksforespørsler for ressurser som allerede er lagret lokalt på brukerens enhet. Selv om det ikke vil øke hastigheten på den første sidevisningen, vil det forbedre lastetidene for påfølgende sidevisninger og tilbakevendende besøkende. Slik hjelper nettleserbufring med Resource Load Delay:

• Bufre konkurrerende ressurser: Selv om bufring av selve LCP-ressursen er en god strategi, forbedrer nettleserbufring LCP Resource Load Delay ved å lagre nettverksressurser som kan konkurrere med eller forsinke LCP-ressursen, som skript, stilark og bilder.
  
• Reduser serverbelastning: Bufring reduserer antall forespørsler sendt til serveren din, noe som kan forbedre ytelsen til andre ressurser ved å frigjøre båndbredde og redusere server-CPU-sykluser.
  

8. Bruk Speculation Rules

Speculation Rules gjør det mulig for nettlesere å forhåndshente eller forhåndsgjengive nettsider basert på forutsagt brukernavigasjon. Forhåndshenting eliminerer effektivt Time to First Byte-delen av LCP og har ingen innvirkning på Resource Load Delay. Forhåndsgjengiving gjengir neste side i en skjult fane og laster ned alle sideressursene.  Dette eliminerer alle forsinkelser ved lasting for LCP-elementet som vist i dette eksempelet på LCP-nedbrytning av en forhåndsgjengitt side.

9. Unngå klientsidegjengiving