INP Presentation Delay: DOM-grootte, Layout Work en Rendering-optimalisatie

Interaction to Next Paint (INP) problemen veroorzaakt door presentation delay

Deze pagina maakt deel uit van onze Interaction to Next Paint (INP) serie. INP meet de totale tijd van een gebruikersinteractie tot de volgende visuele update. Presentation delay is de derde en laatste fase van de INP, na input delay en processing time. Als je nieuw bent met INP, lees dan eerst onze gids over hoe je INP-problemen kunt identificeren en oplossen.

Kort samengevat: De Interaction to Next Paint (INP) meet hoe lang het duurt voordat een gebruiker een visuele verandering op een pagina ziet na interactie ermee. Deze INP kan worden opgedeeld in 3 componenten: "input delay", "processing time" en "presentation delay."

Presentation delay is de grootste bijdrager aan de totale INP en is verantwoordelijk voor gemiddeld ongeveer 42% van de totale INP-tijd. Het optimaliseren van je rendering-pipeline en het vereenvoudigen van je HTML-structuur is de belangrijkste hefboom voor het verbeteren van INP.

Presentation Delay: Heb je ooit op een knop geklikt en je afgevraagd waarom het een fractie van een seconde te lang duurde om het resultaat te zien? Dat is Interaction to Next Paint (INP) in actie. Presentation delay is de laatste stap in het interactieproces, die begint nadat je klik is verwerkt maar voordat je visuele veranderingen ziet.

Presentation delay begrijpen

De presentation is de laatste fase van een interactie. Presentation delay vertegenwoordigt de tijd die de browser nodig heeft om visuele updates te renderen die volgen op de interactie. Presentation delay begint wanneer de event handlers voor de interactie klaar zijn met uitvoeren en eindigt wanneer het volgende frame (met de visuele veranderingen) wordt geschilderd. De presentation delay kan worden beïnvloed door verschillende factoren, waaronder de complexiteit van de layout, de grootte van de DOM en de hoeveelheid rendering work die nodig is.

De Interaction to Next Paint (INP) kan worden opgedeeld in 3 subdelen: "Input Delay", "Processing Time" en "Presentation Delay".

Presentation delay en de INP

Presentation delay is de laatste fase van de INP. Gemiddeld vormt presentation delay ongeveer 42% van de totale INP-tijd, waardoor het de grootste individuele bijdrager is aan trage interacties.

Bij CoreDash verzamelen we miljoenen Core Web Vitals datapunten per uur. Op basis van die data is presentation delay verantwoordelijk voor 42% van de Interaction to Next Paint. Dit is meer dan processing time (40%) en aanzienlijk meer dan input delay (18%). Ondanks dat het de grootste bijdrager is, is presentation delay vaak de moeilijkste fase om te optimaliseren omdat het de rendering-pipeline van de browser betreft in plaats van je applicatiecode.

Voorbeeld van presentation delay: Stel je voor dat je op je telefoon door een e-commercewebsite bladert op zoek naar een nieuw paar schoenen. Je tikt op een productafbeelding om meer details te zien. Echter, je telefoon is wat ouder en heeft moeite om bij te blijven. Je tikt op de afbeelding (Interactie). De telefoon heeft wat tijd nodig om het verzoek te verwerken en het scherm bij te werken (Processing Time). De website moet de nieuwe pagina renderen met de grotere afbeelding en details. Uiteindelijk duurt het merkbaar lang voordat de nieuwe productdetails en afbeelding op je scherm verschijnen (Presentation Delay). Deze vertraging in de INP kan frustrerend zijn voor gebruikers en daarom is het belangrijk om dit op te lossen.

Wat veroorzaakt hoge presentation delay?

Presentation delay omvat al het werk dat de browser doet nadat je event handlers klaar zijn en voordat pixels op het scherm verschijnen. Dit omvat stijlherberekening, layout-berekening, schilderen en compositing. Verschillende factoren dragen bij aan hoge presentation delay:

Grote DOM-grootte

Een grote of diep geneste DOM is een van de meest voorkomende oorzaken van hoge presentation delay. Elke keer dat de browser de visuele status van de pagina moet bijwerken na een interactie, moet het stijlen herberekenen, layout berekenen en de betreffende elementen opnieuw schilderen. De kosten van elk van deze stappen schalen met het aantal DOM-nodes dat wordt beïnvloed.

Google raadt aan om je DOM onder de 1.400 elementen te houden, met een maximale diepte van 32 niveaus en niet meer dan 60 child-elementen per parent-node (zie de Lighthouse DOM size audit). Wanneer je DOM deze drempels overschrijdt, besteedt de browser veel meer tijd aan stijlherberekening en layout-berekening na elke interactie.

Beschouw dit scenario: een gebruiker klikt op een knop die een CSS-klasse schakelt op een container-element. Als die container 5.000 onderliggende nodes heeft, moet de browser potentieel voor allemaal stijlen herberekenen, zelfs als slechts enkele elementen visueel veranderen. Deze stijlherberekening gebeurt synchroon vóór de volgende paint, wat de presentation delay direct verhoogt.

Voor specifieke technieken om je DOM te verkleinen, lees onze gids over het oplossen van overmatige DOM-grootte.

Overmatig layout work

Layout (ook wel "reflow" genoemd) is het proces waarbij de browser de positie en afmetingen berekent van elk zichtbaar element op de pagina. Na een interactie die de DOM wijzigt of CSS-eigenschappen verandert die de geometrie beïnvloeden (width, height, margin, padding, top, left), moet de browser layout uitvoeren voordat het het bijgewerkte frame kan schilderen.

Twee patronen zijn bijzonder schadelijk voor presentation delay:

Geforceerde synchrone layout treedt op wanneer JavaScript een layout-eigenschap leest (zoals offsetHeight of getBoundingClientRect()) na het maken van een DOM-wijziging die de layout ongeldig maakt. De browser wordt gedwongen layout synchroon uit te voeren, binnen je event handler, om een accurate waarde te retourneren. Dit layout work wordt dan onderdeel van processing time, maar eventuele volgende layout die wordt getriggerd door verdere DOM-wijzigingen wordt onderdeel van presentation delay.

Layout thrashing is het herhaalde patroon van schrijven naar de DOM en vervolgens layout-eigenschappen lezen in een lus. Elke leesbewerking dwingt de browser om layout opnieuw te berekenen, en elke schrijfbewerking maakt de layout weer ongeldig. Dit kan tientallen of zelfs honderden onnodige layout-berekeningen per interactie veroorzaken. Hier is een voorbeeld van layout thrashing en hoe je het oplost:

// FOUT: Layout thrashing in een lus
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Lezen (forceert layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Schrijven (maakt layout ongeldig)
    item.style.width = parentWidth + 'px';
  });
}

// GOED: Eerst alle leesbewerkingen, dan alle schrijfbewerkingen
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Lees eerst alle waarden
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Schrijf dan alle waarden
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Client-side rendering in Single Page Applications

Client-side rendering van HTML kan aanzienlijke impact hebben op presentation delay, vooral in Single Page Applications (SPA's). Wanneer een gebruikersinteractie een routewijziging of een grote UI-update triggert, moet het SPA-framework:

1. Het virtual DOM diffing-algoritme uitvoeren om te bepalen wat er is veranderd
2. De resulterende DOM-mutaties toepassen op de echte DOM
3. Stijlherberekening en layout triggeren voor alle betreffende elementen
4. Het bijgewerkte frame schilderen

In React-applicaties is het virtual DOM-reconciliatieproces onderdeel van processing time, maar de resulterende DOM-mutaties en hun renderingkosten vallen onder presentation delay. Hoe meer DOM-nodes je componentboom produceert, hoe duurder de reconciliatie en het daaropvolgende rendering work.

Om dit te verminderen in React- en Next.js-applicaties:

• Gebruik React.memo() om onnodige re-renders te voorkomen van child-componenten die dezelfde props ontvangen.
• Gebruik useDeferredValue() voor waarden die dure re-renders triggeren, zodat React urgentere updates kan prioriteren.
• Houd componentbomen ondiep. Diep geneste componenthiërarchieën produceren diep geneste DOM, wat de kosten van zowel reconciliatie als browserrendering verhoogt.
• Gebruik virtualisatiebibliotheken (zoals react-window of @tanstack/react-virtual) voor lange lijsten zodat de DOM alleen de zichtbare items bevat.

Presentation delay verminderen

Minimaliseer de DOM-grootte

De grootste winst voor presentation delay is het klein houden van je DOM:

• Verwijder ongebruikte HTML-elementen, vooral diep geneste wrapper-divs.
• Gebruik lijstvirtualisatie voor lange lijsten (render alleen zichtbare items plus een kleine buffer).
• Maak diep geneste structuren platter waar mogelijk.
• Gebruik CSS Grid en Flexbox in plaats van geneste divs voor layout.

// Virtualiseer lange lijsten om de DOM-grootte te verkleinen
// Vóór: 10.000 items in de DOM

<ul>
  {allItems.map(item => 
     <li key="{item.id}">{item.name}</li>)
   }
</ul>

// Na: alleen zichtbare items in de DOM (met 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>

Gebruik content-visibility om off-screen content lazy te renderen

De CSS content-visibility eigenschap vertelt de browser om het renderen van off-screen content over te slaan totdat de gebruiker er naartoe scrollt. Dit vermindert de hoeveelheid rendering work tijdens interacties door het bereik van stijlherberekening en layout te beperken tot het zichtbare gedeelte van de pagina.

/* Pas content-visibility toe op secties onder de vouw */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Pas toe op individuele items in lange lijsten */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

De contain-intrinsic-size eigenschap biedt een geschatte hoogte zodat de browser de scrollbalkgrootte correct kan berekenen zonder de content te renderen. Dit voorkomt layout shifts wanneer de gebruiker scrollt en de content zichtbaar wordt.

Voor meer CSS-optimalisatiestrategieën die de renderingkosten verlagen, zie onze gids over het verwijderen van ongebruikte CSS.

Minimaliseer layout work getriggerd door interacties

Bij het ontwerpen van interacties, geef de voorkeur aan CSS-eigenschappen die geen layout triggeren. Eigenschappen zoals transform en opacity kunnen worden afgehandeld door de GPU compositor zonder layout of paint te triggeren. In plaats van top, left, width of height te animeren, gebruik transform: translate() en transform: scale(). Voor de volledige lijst van CSS-eigenschappen die layout triggeren, zie de web.dev rendering performance gids.

Gebruik de CSS will-change eigenschap om de browser een hint te geven dat een element geanimeerd zal worden. Dit stelt de browser in staat om een aparte compositor-laag te maken voor het element, waardoor de rendering ervan wordt geïsoleerd van de rest van de pagina:

/* Promoveer elementen naar hun eigen compositor-laag */
.animated-element {
  will-change: transform, opacity;
}

/* Schakel zichtbaarheid met opacity in plaats van 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);
}

Lange presentation delays identificeren

Om lange presentation delays te identificeren kun je Chrome's performance profiler gebruiken. Open DevTools (Ctrl+Shift+I), navigeer naar het Performance-tabblad, klik op opnemen en interacteer met de pagina.

Je kunt vervolgens de tijdlijn van een interactie analyseren en de verschillende fasen visualiseren, waaronder de presentation delay. Door de rendering-updates te onderzoeken die plaatsvinden nadat de event handlers klaar zijn, kun je eventuele knelpunten identificeren die bijdragen aan een lange presentation delay. Zoek naar grote "Recalculate Style", "Layout" en "Paint" vermeldingen in de tijdlijn. Deze vertegenwoordigen het werk dat de browser doet tijdens de presentation delay-fase.

Presentation delay identificeren met RUM-data

Presentation delay meten met Long Animation Frames (LoAF)

De Long Animation Frames (LoAF) API toont precies wat renderingvertragingen veroorzaakt tijdens gebruikersinteracties. De API geeft je timingdata om processing time te scheiden van presentation delay en te bepalen welke scripts de rendering vertragen.

De belangrijkste LoAF-eigenschappen voor het begrijpen van presentation delay zijn:

• renderStart: wanneer de browser begon met de renderingfase (stijlherberekening, layout, paint)
• styleAndLayoutStart: wanneer stijl- en layout-berekening begon
• duration: totale duur van het lange animatieframe
• blockingDuration: hoeveel van het frame geblokkeerd was door scripts

LoAF is momenteel alleen beschikbaar in Chromium (Chrome 123+). Voor andere browsers, gebruik Chrome DevTools Performance panel traces om rendering work te analyseren.

Het verschil tussen het einde van scriptuitvoering en het einde van het frame vertegenwoordigt de pure renderingkosten, wat presentation delay is. Zo kun je deze data observeren en loggen:

// Meet presentation delay met de 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-tools zoals CoreDash integreren LoAF-data en tonen je welke scripts en DOM-wijzigingen renderingvertragingen veroorzaken, met volledige scriptattributie.

Ontdek de andere INP-fasen

Om je INP onder controle te krijgen, pak ook de andere twee fasen aan:

• Input Delay: Minimaliseer de wachttijd voordat event handlers beginnen met uitvoeren. Input delay is doorgaans de kleinste fase maar piekt tijdens het opstarten van de pagina wanneer de main thread druk bezig is.
• Processing Time: Optimaliseer de event handler-code die tijdens de interactie wordt uitgevoerd. Op de meeste pagina's levert hier het grootste deel van je optimalisatie-inspanning het meeste op.

Voor een complete diagnostische workflow, zie onze gids over hoe je INP-problemen kunt vinden en oplossen. Voor aanvullende rendering-optimalisatiestrategieën, bekijk onze gidsen over het oplossen van overmatige DOM-grootte en het verwijderen van ongebruikte CSS. Keer terug naar de INP-hubpagina voor het volledige overzicht.