INP Presentation Delay: DOM-omvang, layoutwerk en renderoptimalisatie

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

Deze pagina is onderdeel van onze serie over Interaction to Next Paint (INP). De 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. Ben je nieuw met INP, lees dan eerst onze handleiding over INP-problemen opsporen en oplossen.

Kort gezegd: de Interaction to Next Paint (INP) meet hoe lang het duurt voordat een gebruiker na een interactie een visuele verandering op de pagina ziet. Deze INP bestaat uit 3 onderdelen: "input delay", "processing time" en "presentation delay".

Presentation delay levert gemiddeld de grootste bijdrage aan de totale INP: zo'n 42% van de totale INP-tijd. Je rendering pipeline optimaliseren en je HTML-structuur vereenvoudigen is de grootste hefboom om je INP te verbeteren.

Presentation Delay: ooit op een knop geklikt en je afgevraagd waarom het net een fractie te lang duurde voor je resultaat zag? Dat is Interaction to Next Paint (INP) in de praktijk. Presentation delay is de laatste stap in het interactieproces. Deze begint nadat je klik is verwerkt, maar vóórdat je visuele veranderingen ziet.

Hoe presentation delay werkt

De presentation is de laatste fase van een interactie. Presentation delay is de tijd die de browser nodig heeft om de visuele updates na de interactie te renderen. Presentation delay begint zodra de event handlers voor de interactie klaar zijn, en eindigt wanneer het volgende frame (met de visuele veranderingen) is getekend. Verschillende factoren beïnvloeden de presentation delay: de complexiteit van de layout, de omvang van de DOM en de benodigde hoeveelheid renderwerk.

De Interaction to Next Paint (INP) bestaat uit 3 onderdelen: "Input Delay", "Processing Time" en "Presentation Delay".

Presentation delay en de INP

Presentation delay is de laatste fase van de INP. Gemiddeld beslaat presentation delay zo'n 42% van de totale INP-tijd. Daarmee is het veruit de grootste veroorzaker van trage interacties.

Bij CoreDash verzamelen we elk uur miljoenen Core Web Vitals-datapunten. Uit die data blijkt dat de presentation delay verantwoordelijk is voor 42% van de Interaction to Next Paint. Dat is meer dan processing time (40%) en aanzienlijk meer dan input delay (18%). Ondanks dat het de grootste factor is, is presentation delay vaak de lastigste fase om te optimaliseren: het raakt namelijk de rendering pipeline van de browser in plaats van je eigen applicatiecode.

Voorbeeld van presentation delay: stel: je zoekt op je telefoon naar een nieuw paar schoenen in een webshop. Je tikt op een productafbeelding voor meer details. Maar je telefoon is wat ouder en heeft moeite om het bij te benen. Je tikt op de afbeelding (Interaction). De telefoon heeft tijd nodig om het request te verwerken en het scherm bij te werken (Processing Time). De website moet de nieuwe pagina renderen met de grotere afbeelding en details. Vervolgens duurt het merkbaar lang voordat de nieuwe productdetails en afbeelding op je scherm verschijnen (Presentation Delay). Die vertraging in de INP is frustrerend voor gebruikers; daarom is het belangrijk dit te fixen.

Wat veroorzaakt een hoge presentation delay?

Presentation delay omvat al het werk dat de browser doet nadat je event handlers klaar zijn en vóórdat de pixels op het scherm verschijnen. Denk aan style recalculation, layoutberekeningen, painting en compositing. Verschillende factoren zorgen voor een hoge presentation delay:

Een grote DOM

Een grote of diep geneste DOM is een van de meest voorkomende oorzaken van een hoge presentation delay. Moet de browser na een interactie de visuele state van de pagina bijwerken, dan berekent hij styles opnieuw, bepaalt hij de layout en tekent hij de getroffen elementen opnieuw. De impact van elk van deze stappen schaalt mee met het aantal betrokken DOM-nodes.

Google adviseert om je DOM onder de 1.400 elementen te houden, met een maximale diepte van 32 niveaus en maximaal 60 child-elementen per parent node (zie de Lighthouse DOM size audit). Komt je DOM boven deze drempelwaarden uit, dan besteedt de browser na elke interactie aanzienlijk meer tijd aan style recalculation en layoutberekeningen.

Neem dit scenario: een gebruiker klikt op een knop die een CSS-class op een container-element togglet. Heeft die container 5.000 onderliggende nodes, dan moet de browser mogelijk voor al die nodes de styles opnieuw berekenen—ook al veranderen er visueel maar een paar elementen. Deze style recalculation gebeurt synchroon vóór de volgende paint, wat de presentation delay direct opdrijft.

Lees voor specifieke technieken om je DOM te verkleinen onze handleiding over een te grote DOM oplossen.

Overmatig layoutwerk

Layout (ook wel "reflow" genoemd) is het proces waarin de browser de positie en afmetingen van elk zichtbaar element op de pagina berekent. Wijzigt een interactie de DOM of verandert er een CSS-property die de geometrie beïnvloedt (width, height, margin, padding, top, left), dan moet de browser eerst de layout berekenen voordat hij het bijgewerkte frame kan tekenen.

Twee patronen verplaatsen het layoutwerk naar je eigen event handler. Die geforceerde layout telt mee in de processing time; alleen het layoutwerk dat de browser uitvoert nadat je handler klaar is, telt mee voor de presentation delay:

Forced synchronous layout ontstaat als JavaScript een layout-property uitleest (zoals offsetHeight of getBoundingClientRect()) direct na een DOM-wijziging die de eerdere layout ongeldig maakt. De browser wordt gedwongen om de layout synchroon binnen je event handler te berekenen om een correcte waarde terug te geven. Dit layoutwerk valt daardoor onder de processing time. Alle verdere layout die door latere DOM-wijzigingen wordt getriggerd, valt vervolgens onder de presentation delay.

Layout thrashing is het herhaaldelijk schrijven naar de DOM en direct daarna uitlezen van layout-properties in een loop. Elke read dwingt de browser om de layout opnieuw te berekenen, en elke write maakt die layout meteen weer ongeldig. Dit kan tientallen tot honderden overbodige layoutberekeningen per interactie veroorzaken. Dit is een voorbeeld van layout thrashing en hoe je dit fixt:

// 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 in Single Page Applications

Client-side rendering van HTML kan de presentation delay flink verhogen, vooral bij Single Page Applications (SPA's). Triggert een interactie van de gebruiker een routewijziging of een grote UI-update, dan moet het SPA-framework:

1. Het virtual DOM-diffingalgoritme uitvoeren om te bepalen wat er is gewijzigd
2. De resulterende DOM-mutaties toepassen op de echte DOM
3. Style recalculation en layout triggeren voor alle geraakte elementen
4. Het bijgewerkte frame tekenen

In React-applicaties valt het reconciliatieproces van de virtual DOM onder processing time. De resulterende DOM-mutaties en de bijbehorende renderkosten vallen echter onder de presentation delay. Hoe meer DOM-nodes je component tree produceert, hoe zwaarder de reconciliatie en het daaropvolgende renderwerk worden.

Zo beperk je dit in React- en Next.js-applicaties:

• Gebruik React.memo() om onnodige re-renders te voorkomen van child components die dezelfde props ontvangen.
• Gebruik useDeferredValue() voor waarden die zware re-renders triggeren, zodat React urgentere updates voorrang kan geven.
• Houd component trees ondiep. Diep geneste hiërarchieën leveren een diep geneste DOM op, wat zowel de reconciliatie als het renderen door de browser vertraagt.
• Gebruik virtualisatie-libraries (zoals react-window of @tanstack/react-virtual) voor lange lijsten, zodat de DOM alleen de zichtbare items bevat.

Presentation delay verminderen

Houd de DOM klein

De grootste winst voor presentation delay behaal je door je DOM klein te houden:

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

// 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>

Gebruik content-visibility om content buiten het scherm lazy te renderen

De CSS-property content-visibility vertelt de browser om het renderen van content buiten het scherm over te slaan totdat de gebruiker er dichtbij scrollt. Dit vermindert de hoeveelheid renderwerk tijdens interacties, doordat style recalculation en layout beperkt blijven tot het zichtbare deel van de pagina.

/* 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;
}

De property contain-intrinsic-size geeft een geschatte hoogte mee, zodat de browser de scrollbar correct kan berekenen zonder de content te hoeven renderen. Dit voorkomt layout shifts zodra de gebruiker scrollt en de content zichtbaar wordt.

Bekijk onze handleiding over ongebruikte CSS verwijderen voor meer optimalisatiestrategieën om renderkosten te verlagen.

Beperk het layoutwerk bij interacties

Kies bij het ontwerpen van interacties bij voorkeur voor CSS-properties die geen layout triggeren. Properties zoals transform en opacity worden direct door de GPU-compositor afgehandeld, zonder layout of paint te triggeren. Animeer geen top, left, width of height, maar gebruik transform: translate() en transform: scale(). Bekijk de web.dev rendering performance guide voor de volledige lijst van CSS-properties die layout triggeren.

Gebruik de CSS-property will-change om de browser te tippen dat een element geanimeerd gaat worden. De browser kan het element dan op een eigen compositor layer plaatsen, waardoor het renderen losstaat van de rest van de pagina:

/* 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);
}

Lange presentation delays opsporen

Om een lange presentation delay op te sporen, gebruik je de performance profiler van Chrome. Open DevTools (Ctrl+Shift+I), ga naar het tabblad Performance, klik op record en voer een interactie uit op de pagina.

Vervolgens analyseer je de timeline van de interactie om de verschillende fases in kaart te brengen, inclusief de presentation delay. Kijk naar de render-updates die plaatsvinden nadat de event handlers klaar zijn; zo zie je precies welke knelpunten voor een lange presentation delay zorgen. Let vooral op grote "Recalculate Style"-, "Layout"- en "Paint"-blokken in de timeline. Dit is het werk dat de browser uitvoert tijdens de presentation delay-fase.

Presentation delay opsporen met RUM-data

Presentation delay meten met Long Animation Frames (LoAF)

De Long Animation Frames (LoAF) API toont exact wat rendering-vertragingen veroorzaakt tijdens interacties van gebruikers. De API levert timingdata om processing time en presentation delay van elkaar te scheiden en wijst direct aan welke scripts het renderen vertragen.

De belangrijkste LoAF-properties om presentation delay te begrijpen zijn:

• renderStart: het moment waarop de browser begon met de rendering-fase (style recalculation, layout, paint)
• styleAndLayoutStart: het moment waarop de berekening van styles en layout startte
• duration: de totale duur van het long animation frame
• blockingDuration: hoelang het frame werd geblokkeerd door scripts

LoAF werkt momenteel alleen in Chromium (Chrome 123+). Gebruik voor andere browsers traces uit het Performance-paneel van Chrome DevTools om het renderwerk te analyseren.

Het verschil tussen het einde van de scriptuitvoering en het einde van het frame zijn de pure renderkosten: de presentation delay. Dit is hoe je deze data uitleest en logt:

// 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-tools zoals CoreDash integreren LoAF-data en laten met volledige script-attributie zien welke scripts en DOM-wijzigingen voor rendering-vertragingen zorgen.

Bekijk de andere INP-fases

Om je INP onder controle te krijgen, moet je ook de andere twee fases aanpakken:

• Input Delay: minimaliseer de wachttijd voordat event handlers starten met de uitvoering. Input delay is doorgaans de kortste fase, maar piekt bij het opstarten van de pagina wanneer de main thread druk is.
• Processing Time: optimaliseer de code van de event handlers die tijdens de interactie draait. Op de meeste pagina's levert dit het grootste deel van je optimalisatiewinst op.

Bekijk voor een complete diagnose onze handleiding over INP-problemen opsporen en oplossen. Lees voor aanvullende render-optimalisaties onze handleidingen over een te grote DOM oplossen en ongebruikte CSS verwijderen. Ga terug naar de INP-overzichtspagina voor het complete overzicht.