INP Presentation Delay: DOM-størrelse, layoutarbejde og renderingsoptimering

Interaction to Next Paint (INP)-problemer forårsaget af presentation delay

Denne side er en del af vores Interaction to Next Paint (INP)-serie. INP måler den samlede tid fra en brugerinteraktion til den næste visuelle opdatering. Presentation delay er den tredje og sidste fase af INP, efter input delay og processing time. Hvis du er ny til INP, kan du læse vores guide om hvordan du identificerer og løser INP-problemer først.

I denne artikel fokuserer vi på presentation delay: hvad der forårsager det, hvordan det påvirker Interaction to Next Paint, og hvordan du optimerer det for at forbedre dine INP-scores.

Kort sagt: Interaction to Next Paint (INP) måler, hvor lang tid det tager for en bruger at se en visuel ændring på en side efter at have interageret med den. Denne INP kan opdeles i 3 komponenter: "input delay", "processing time" og "presentation delay."

Presentation delay er den største bidragsyder til den samlede INP og udgør i gennemsnit cirka 42% af den samlede INP-tid. Det betyder, at optimering af din renderingspipeline og forenkling af din HTML-struktur kan have en betydelig indvirkning på dit websites INP-score.

Presentation Delay: Har du nogensinde klikket på en knap og undret dig over, hvorfor det tog et splitsekund for længe at se resultatet? Det er Interaction to Next Paint (INP) i aktion. Presentation delay er det sidste trin i interaktionsprocessen, som starter efter dit klik er blevet behandlet, men før du ser nogen visuelle ændringer.

Forståelse af presentation delay

Presentation er den sidste fase af en interaktion. Presentation delay repræsenterer den tid, det tager for browseren at rendere visuelle opdateringer efter interaktionen. Presentation delay begynder, når event handlers for interaktionen er færdige med at køre, og slutter, når den næste frame (der indeholder de visuelle ændringer) er malet. Presentation delay kan påvirkes af forskellige faktorer, herunder layoutets kompleksitet, DOM'ens størrelse og mængden af renderingsarbejde, der kræves.

Interaction to Next Paint (INP) kan opdeles i 3 underdele: "Input Delay", "Processing Time" og "Presentation Delay".

Presentation delay og INP

Presentation delay er den sidste fase af INP. I gennemsnit udgør presentation delay cirka 42% af den samlede INP-tid, hvilket gør det til den enkeltstående største bidragsyder til langsomme interaktioner.

Hos CoreDash indsamler vi millioner af Core Web Vitals-datapunkter hver time. Baseret på disse data udgør presentation delay 42% af Interaction to Next Paint. Det er mere end processing time (40%) og væsentligt mere end input delay (18%). På trods af at være den største bidragsyder er presentation delay ofte den sværeste fase at optimere, fordi den involverer browserens renderingspipeline snarere end din applikationskode.

Eksempel på presentation delay: Forestil dig, at du er på din telefon og browser en e-handelswebsite efter et nyt par sko. Du trykker på et produktbillede for at se flere detaljer. Men din telefon er lidt ældre og har svært ved at følge med. Du trykker på billedet (interaktion). Telefonen bruger noget tid på at behandle anmodningen og opdatere skærmen (Processing Time). Websitet skal rendere den nye side med det større billede og detaljerne. Til sidst tager det mærkbar tid, før de nye produktdetaljer og billedet vises på din skærm (Presentation Delay). Denne forsinkelse i INP kan være frustrerende for brugere, og det er derfor vigtigt at løse det.

Hvad forårsager høj presentation delay?

Presentation delay omfatter alt det arbejde, browseren udfører efter dine event handlers er færdige, og før pixels vises på skærmen. Dette inkluderer stilgenberegning, layoutberegning, maling og compositing. Flere faktorer bidrager til høj presentation delay:

Stor DOM-størrelse

En stor eller dybt indlejret DOM er en af de mest almindelige årsager til høj presentation delay. Hver gang browseren skal opdatere den visuelle tilstand af siden efter en interaktion, skal den genberegne stilarter, beregne layout og male de berørte elementer. Omkostningerne ved hvert af disse trin skalerer med antallet af DOM-noder, der er berørt.

Google anbefaler at holde din DOM under 1.400 elementer, med en maksimal dybde på 32 niveauer og ikke mere end 60 child-elementer per parent-node. Når din DOM overstiger disse tærskler, bruger browseren betydeligt mere tid på stilgenberegning og layoutberegning efter hver interaktion.

Overvej dette scenarie: en bruger klikker på en knap, der skifter en CSS-klasse på et container-element. Hvis den container har 5.000 underordnede noder, skal browseren potentielt genberegne stilarter for dem alle, selvom kun få elementer faktisk ændrer sig visuelt. Denne stilgenberegning sker synkront før næste maling og øger dermed direkte presentation delay.

For specifikke teknikker til at reducere din DOM kan du læse vores guide om at løse problemer med for stor DOM-størrelse.

Overdrevent layoutarbejde

Layout (også kaldet "reflow") er den proces, hvor browseren beregner positionen og dimensionerne af hvert synligt element på siden. Efter en interaktion, der ændrer DOM'en eller ændrer CSS-egenskaber, der påvirker geometri (width, height, margin, padding, top, left), skal browseren udføre layout, før den kan male den opdaterede frame.

To mønstre er særligt skadelige for presentation delay:

Tvungen synkron layout opstår, når JavaScript læser en layout-egenskab (som offsetHeight eller getBoundingClientRect()) efter at have foretaget en DOM-ændring, der ugyldiggør layoutet. Browseren tvinges til at udføre layout synkront inden for din event handler for at returnere en nøjagtig værdi. Dette layoutarbejde bliver så en del af processing time, men eventuel efterfølgende layout udløst af yderligere DOM-ændringer bliver en del af presentation delay.

Layout thrashing er det gentagne mønster med at skrive til DOM'en og derefter læse layout-egenskaber i en løkke. Hver læsning tvinger browseren til at genberegne layout, og hver skrivning ugyldiggør layoutet igen. Dette kan forårsage snesevis eller endda hundredvis af unødvendige layoutberegninger per interaktion. Her er et eksempel på layout thrashing, og hvordan det løses:

// BAD: Layout thrashing inside a loop
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Read (forces layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Write (invalidates layout)
    item.style.width = parentWidth + 'px';
  });
}

// GOOD: Batch reads, then batch writes
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Read all values first
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Then write all values
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Client-side rendering i Single Page Applications

Client-side rendering af HTML kan have en betydelig indvirkning på presentation delay, især i Single Page Applications (SPA'er). Når en brugerinteraktion udløser en ruteskift eller en stor UI-opdatering, skal SPA-frameworket:

1. Køre virtual DOM diffing-algoritmen for at afgøre, hvad der er ændret
2. Anvende de resulterende DOM-mutationer på den rigtige DOM
3. Udløse stilgenberegning og layout for alle berørte elementer
4. Male den opdaterede frame

I React-applikationer er virtual DOM-afstemningsprocessen en del af processing time, men de resulterende DOM-mutationer og deres renderingsomkostninger falder ind under presentation delay. Jo flere DOM-noder dit komponenttræ producerer, desto dyrere er afstemningen og det efterfølgende renderingsarbejde.

For at afhjælpe dette i React- og Next.js-applikationer:

• Brug React.memo() for at forhindre unødvendige genrenderinger af child-komponenter, der modtager de samme props.
• Brug useDeferredValue() for værdier, der udløser dyre genrenderinger, så React kan prioritere mere presserende opdateringer.
• Hold komponenttræer flade. Dybt indlejrede komponenthierarkier producerer dybt indlejret DOM, hvilket øger omkostningerne ved både afstemning og browserrendering.
• Brug virtualiseringsbiblioteker (som react-window eller @tanstack/react-virtual) til lange lister, så DOM'en kun indeholder de synlige elementer.

Reduktion af presentation delay

Nu hvor vi forstår årsagerne, er her de mest effektive strategier til at minimere presentation delay.

Minimer DOM-størrelsen

Den mest virkningsfulde optimering for presentation delay er at holde din DOM lille. Her er praktiske teknikker:

• Fjern ubrugte HTML-elementer, især dybt indlejrede wrapper-div'er.
• Brug listevirtualisering til lange lister (render kun synlige elementer plus en lille buffer).
• Fladgør dybt indlejrede strukturer, hvor det er muligt.
• Brug CSS Grid og Flexbox i stedet for indlejrede div'er til layout.

// Virtualize long lists to reduce DOM size
// Before: 10,000 items in the DOM
<ul>
  {allItems.map(item => <li key={item.id}>{item.name}</li>)}
</ul>

// After: only visible items in the DOM (using react-window)
import { FixedSizeList } from 'react-window';

<FixedSizeList
  height={600}
  itemCount={allItems.length}
  itemSize={50}
  width="100%"
>
  {({ index, style }) => (
    <div style={style}>{allItems[index].name}</div>
  )}
</FixedSizeList>

Brug content-visibility til at lazy-rendere indhold uden for skærmen

CSS-egenskaben content-visibility fortæller browseren at springe rendering af indhold uden for skærmen over, indtil brugeren scroller hen mod det. Dette reducerer mængden af renderingsarbejde under interaktioner ved at begrænse omfanget af stilgenberegning og layout til den synlige del af siden.

/* Apply content-visibility to sections below the fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Apply to individual items in long lists */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

Egenskaben contain-intrinsic-size angiver en estimeret højde, så browseren kan beregne scrollbarens størrelse korrekt uden at rendere indholdet. Dette forhindrer layout shifts, når brugeren scroller, og indholdet bliver synligt.

For flere CSS-optimeringsstrategier, der reducerer renderingsomkostninger, se vores guide om at fjerne ubrugt CSS.

Minimer layoutarbejde udløst af interaktioner

Når du designer interaktioner, bør du foretrække CSS-egenskaber, der ikke udløser layout. Egenskaber som transform og opacity kan håndteres af GPU-compositoren uden at udløse layout eller maling. I stedet for at animere top, left, width eller height, brug transform: translate() og transform: scale().

Brug CSS-egenskaben will-change til at give browseren et hint om, at et element vil blive animeret. Dette gør det muligt for browseren at oprette et separat compositor-lag for elementet, der isolerer dets rendering fra resten af siden:

/* Promote elements to their own compositor layer */
.animated-element {
  will-change: transform, opacity;
}

/* Toggle visibility with opacity instead of display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identificering af lange presentation delays

For at identificere lange presentation delays kan du bruge Chromes performance-profiler. Åbn DevTools (Ctrl+Shift+I), naviger til fanen Performance, tryk på optag, og interager med siden.

Du kan derefter analysere tidslinjen for en interaktion og visualisere de forskellige faser, herunder presentation delay. Ved at undersøge de renderingsopdateringer, der sker efter event handlers er færdige, kan du lokalisere eventuelle flaskehalse, der bidrager til en lang presentation delay. Kig efter store "Recalculate Style"-, "Layout"- og "Paint"-poster i tidslinjen. Disse repræsenterer det arbejde, browseren udfører under presentation delay-fasen.

Identificering af presentation delay med RUM-data

Måling af presentation delay med Long Animation Frames (LoAF)

Long Animation Frames (LoAF) API'en giver detaljerede indsigter i årsagerne til renderingsforsinkelser, herunder dem der opstår under bruger- interaktioner. API'en leverer tidsdata, der hjælper dig med at adskille processing time fra presentation delay og identificere, hvilke scripts der bidrager til renderingsflaskehalse.

De vigtigste LoAF-egenskaber til at forstå presentation delay er:

• renderStart: hvornår browseren begyndte renderingsfasen (stilgenberegning, layout, maling)
• styleAndLayoutStart: hvornår stil- og layoutberegning begyndte
• duration: den samlede varighed af den lange animationsframe
• blockingDuration: hvor meget af framen der var blokeret af scripts

Forskellen mellem afslutningen af script-eksekvering og afslutningen af framen repræsenterer den rene renderingsomkostning, som er presentation delay. Her er hvordan du kan observere og logge disse data:

// Measure presentation delay using LoAF API
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

RUM-værktøjer som CoreDash integrerer LoAF-data og giver yderligere indsigter i lange animationsframes, såsom script-attributionsdata. Disse værktøjer hjælper dig med at forstå, hvilke scripts og DOM-ændringer der bidrager til renderingsforsinkelser, så du kan optimere din kodebase for bedre responsivitet.

Udforsk de andre INP-faser

Presentation delay er kun en del af Interaction to Next Paint. For fuldt ud at optimere dine INP-scores bør du også adressere de to andre faser:

• Input Delay: Minimer ventetiden, før event handlers begynder at køre. Input delay udgør cirka 18% af den samlede INP-tid.
• Processing Time: Optimer event handler-eksekveringen, der udgør cirka 40% af den samlede INP-tid.

For en komplet diagnostisk arbejdsgang, se vores guide om hvordan du finder og løser INP-problemer. For yderligere renderingsoptimeringsstrategier kan du udforske vores guides om at løse problemer med for stor DOM-størrelse og fjerne ubrugt CSS. Gå tilbage til INP-hubsiden for det fulde overblik.