INP-verwerkingstijd: Oorzaken, optimalisatie en codevoorbeelden

Interaction to Next Paint (INP)-problemen veroorzaakt door processing time

Deze pagina is onderdeel van onze Interaction to Next Paint (INP) serie. De INP meet de totale tijd vanaf een gebruikersinteractie tot de volgende visuele update. Processing time is de tweede van drie fases die de INP vormen, voorafgegaan door input delay en gevolgd door presentation delay. Als de INP nieuw voor je is, lees dan eerst onze gids over het identificeren en oplossen van INP-problemen.

Kortom: De Interaction to Next Paint (INP) meet hoe lang het duurt voordat een gebruiker een visuele verandering op een pagina ziet na een interactie. Deze INP bestaat uit drie componenten: "input delay", "processing time" en "presentation delay".

Processing time draagt sterk bij aan de totale INP. Het veroorzaakt gemiddeld zo'n 40% van de vertraging. Het optimaliseren van je event handlers is de meest directe manier om de processing time te verlagen en je INP-score te verbeteren.

INP-TIP: je optimaliseert de processing time door belangrijke code die aan de layout-update voorafgaat direct uit te voeren. Plan alle andere code in om daarna te draaien.

Wat is processing time?

De Interaction to Next Paint (INP) bestaat uit drie onderdelen: "input delay", "processing time" en "presentation delay".

Processing time is de tijd die de browser nodig heeft om alle gekoppelde event callbacks uit te voeren na een gebruikersinteractie met een webpagina (bijvoorbeeld een klik op een knop of een toetsaanslag). Er is altijd enige processing time. INP-problemen ontstaan pas wanneer de event callbacks te veel processing time in beslag nemen.

Simpel gezegd: processing time is de duur van het "werk" dat plaatsvindt als reactie op je interactie. Wanneer je op een zoekknop klikt, omvat de processing time alles van het valideren van je zoekopdracht, het voorbereiden van het API-verzoek, het updaten van de lokale state, het afvuren van analytics events tot alle andere code die aan dat klik-event vastzit. Elke regel JavaScript in die event handlers draagt bij aan de processing time.

Processing time en de INP

Processing time is waarschijnlijk het eerste waar je aan denkt bij het optimaliseren van de Interaction to Next Paint. Het is de "klus die geklaard moet worden" voordat de browser de layout kan updaten.

Veel developers denken bij het verbeteren van de INP aan het optimaliseren van callback-functies (het optimaliseren van de processing time). Ze hebben gelijk. Maar qua belangrijkheid is processing time niet eens het allerbelangrijkste onderdeel om te verbeteren. Gemiddeld is het nog steeds goed voor ongeveer 40% van de totale INP-tijd.

Bij CoreDash verzamelen we elk uur miljoenen Core Web Vitals-datapunten. Op basis van die data is processing time verantwoordelijk voor 40% van de Interaction to Next Paint. 40% is veel, maar het optimaliseren van uitsluitend de processing time lost INP-problemen niet op. Kijk ook naar input delay (18%) en presentation delay (42%).

Voorbeeld van processing time: Wanneer een gebruiker op een knop klikt om een formulier te verzenden, draagt de code die de formulierdata valideert, deze naar de server stuurt en de reactie afhandelt allemaal bij aan de processing time. Hoe langer deze bewerkingen duren, hoe langer de processing time en hoe slechter mogelijk de INP-score.

Wat veroorzaakt een hoge processing time?

Een hoge processing time heeft vier veelvoorkomende oorzaken: onnodige code, niet-geoptimaliseerde code, geclusterde callbacks en layout thrashing.

1. Onnodige code. Oude, ongebruikte code of code zonder directe relevantie voor de gebruikersinteractie verlengt de uitvoeringstijd van de callback. Dit omvat analytics-calls, logging en state-synchronisatie die niet hoeft te voltooien voor de volgende paint.
   
2. Niet-geoptimaliseerde code. Inefficiënte code (meestal loops of inefficiënte DOM-lookups) laat event callbacks trager draaien dan nodig is. Een veelvoorkomend voorbeeld is het bevragen van de DOM in een loop met document.querySelectorAll() in plaats van het resultaat te cachen voor de loop.
   
3. Geclusterde callbacks. Meerdere kort op elkaar geplande event callbacks creëren een wachtrij. Als een door de gebruiker getriggerde callback vastloopt in deze wachtrij, lijkt de reactie vertraagd. Een pointerdown-handler, een mousedown-handler en een click-handler kunnen bijvoorbeeld allemaal achter elkaar afvuren voor één enkele klik.
   
4. Layout thrashing. Frequente DOM-manipulaties die layout-herberekeningen triggeren belasten de browser en leiden tot prestatieverlies. Dit gebeurt wanneer je code in een loop afwisselt tussen het lezen en schrijven van layout-properties. Hierdoor dwing je de browser om de layout meerdere keren opnieuw te berekenen.

Minimaliseer processing time

De strategie is tweeledig: optimaliseer bestaande code (verwijder onnodige code en optimaliseer de huidige code) en maak onderscheid tussen code die vóór en na de layout-update moet draaien. Code die cruciaal is voor de layout-update draait als eerste. Alle andere code kan draaien na de layout-update.

1. Verwijder ongebruikte code. Hoewel het verwijderen van ongebruikte code een no-brainer lijkt, is er op de meeste sites ten minste wat oude ongebruikte code die simpelweg draait zonder iets toe te voegen aan de pagina of de UX. Zorg er allereerst voor dat er geen code draait die je niet nodig hebt. Dit doe je met tree shaking, code splitting, het inspecteren van je code coverage in Chrome en het gebruiken van een goede IDE die hint op ongebruikte code. (Pro-tip: kijk ook kritisch naar resources die je Tag Manager inlaadt.) Voor meer strategieën, zie onze gids over 14 methoden om JavaScript uit te stellen.
2. Minimaliseer de uitvoeringstijd van callbacks. Gebruik een JavaScript profiler om knelpunten in je code te identificeren en optimaliseer deze gebieden. Overweeg technieken zoals memoization, pre-calculation en caching om overbodige berekeningen te voorkomen. (Tip: gebruik het Chrome performance panel om scripts met een lange uitvoeringstijd te vinden.)
   
3. Geef prioriteit aan cruciale code en plan andere code in. Zodra de callback-code geoptimaliseerd is, splits je de code op in code die direct moet draaien en code die je kunt uitstellen. Kijk naar dit praktijkvoorbeeld:
   
   In dit voorbeeld worden de Google Tag Manager- en Facebook-event callbacks uitgevoerd vóór de (React) code die voorafgaat aan de layout-update. De oplossing is om de GTM- en Facebook-callbacks in te plannen zodat ze draaien wanneer de browser idle is.
4. Voorkom layout thrashing of reflow. Layout thrashing ontstaat wanneer style-updates en style-reads gemengd worden in een loop. Hierdoor berekent de browser de layout talloze keren opnieuw. Om layout thrashing te voorkomen, voer je alle style-wijzigingen (de "sets") uit voordat je style-waardes opvraagt (de "gets"). Deze aanpak minimaliseert de frequentie van layout-updates, wat leidt tot een snellere pagina. Bijvoorbeeld: in een loop die de breedte van elke paragraaf instelt op de breedte van een element, lees je de breedte van het element eenmalig voor de loop. Gebruik die waarde vervolgens in de loop om de breedte van de paragrafen te updaten.

Event handlers opknippen met setTimeout(0)

Wanneer je geen code uit een event handler kunt verwijderen of uitstellen, is het opknippen van de handler in kleinere stukken de op één na beste optie. Met het setTimeout(callback, 0) patroon verdeel je werk over meerdere taken. Dit geeft de browser de kans om tussendoor de layout-update af te handelen. Hier is een praktijkvoorbeeld:

// Voorheen: één lange event handler blokkeert de next paint
button.addEventListener('click', () => {
  updateUI();           // Cruciaal: moet draaien vóór de paint
  validateForm();       // Belangrijk maar kan wachten
  sendAnalytics();      // Niet cruciaal
  syncLocalStorage();   // Niet cruciaal
});

// Na: opgeknipt in cruciaal en uitgesteld werk
button.addEventListener('click', () => {
  updateUI();  // Cruciaal: draait direct vóór de paint

  setTimeout(() => {
    validateForm();
  }, 0);

  setTimeout(() => {
    sendAnalytics();
    syncLocalStorage();
  }, 0);
});

Het nadeel van setTimeout(0) is dat het de vervolgstap aan het einde van de takenlijst plaatst. Als er al andere taken in de wachtrij staan, draait de uitgestelde code mogelijk niet direct. Gebruik in plaats daarvan scheduler.yield() voor voorspelbaarder gedrag (zie de sectie hieronder). Voor patronen die specifiek gericht zijn op JavaScript scroll handling, bekijk onze specifieke gids.

requestAnimationFrame gebruiken voor visuele updates

Wanneer je event handler een visuele update moet triggeren, zorgt requestAnimationFrame() ervoor dat je code op het optimale moment draait: direct voordat de browser zijn volgende repaint uitvoert. Dit is vooral handig wanneer je DOM-reads en -writes moet batchen om layout thrashing te voorkomen.

// Gebruik requestAnimationFrame om visuele updates te batchen
button.addEventListener('click', () => {
  // Lees layout-properties als eerste (buiten rAF)
  const containerWidth = container.offsetWidth;

  requestAnimationFrame(() => {
    // Schrijf layout-properties binnen rAF
    items.forEach(item => {
      item.style.width = containerWidth + 'px';
    });
  });

  // Plan niet-visueel werk in voor idle time
  requestIdleCallback(() => {
    trackButtonClick();
    updateSessionState();
  });
});

Dit patroon scheidt DOM-reads van DOM-writes en voorkomt een forced synchronous layout. De visuele update draait op het ideale moment in de rendering pipeline van de browser en het niet-visuele werk draait tijdens idle time.

Hoe geef je prioriteit aan cruciale code

"Geef prioriteit aan cruciale code en plan andere code in" klinkt abstract. Dit is hoe het er in de praktijk uitziet. We geven prioriteit aan cruciale code door requestIdleCallback() te gebruiken en door te yielden naar de main thread.

We gebruiken requestIdleCallback voor minder belangrijke taken die niet direct hoeven te draaien. Hier is een voor-en-na voorbeeld van het inplannen van een GTM-event:

/* voorheen: code direct uitvoeren */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* na: dezelfde code draaien wanneer de browser idle is */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

Het nadeel van requestIdleCallback is dat code mogelijk niet zo snel draait als je zou willen. In dat geval kun je "yielden naar de main thread" nadat de belangrijkste code heeft gedraaid. Dit geeft de browser een moment om de layout-update uit te voeren. Hier is een voorbeeld van hoe je taken opknipt door te yielden naar de main thread:

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

async function handleClick() {
  // Voer hier de belangrijkste layout-updates uit
  await yieldToMain();
  // Voer andere taken uit die zo snel mogelijk na de layout-update moeten draaien
}

Fijnmazige scheduling met scheduler.postTask()

De scheduler.postTask() functie biedt fijnmazigere scheduling van taken door prioriteiten in te stellen. Dit helpt de browser werk te prioriteren, zodat low-priority taken yielden naar de main thread. Bekijk de browser support tabel voordat je deze API in productie gebruikt.

De postTask() functie accepteert drie prioriteitsinstellingen: "background" voor de laagste prioriteitstaken, "user-visible" voor medium-priority taken en "user-blocking" voor cruciale taken die een hoge prioriteit vereisen.

Door de juiste prioriteit toe te wijzen aan elk stuk werk binnen je event handler, zorg je ervoor dat de browser de interacties van de gebruiker responsief afhandelt terwijl hij toch alle nodige taken voltooit:

// Plan cruciaal UI-werk in met hoge prioriteit
scheduler.postTask(() => {
  updateCartBadge();
  showConfirmation();
}, { priority: 'user-blocking' });

// Plan data-sync in met medium prioriteit
scheduler.postTask(() => {
  syncCartWithServer();
}, { priority: 'user-visible' });

// Plan analytics in met lage prioriteit
scheduler.postTask(() => {
  gtag('event', 'add_to_cart', { item: productId });
  fbq('track', 'AddToCart');
}, { priority: 'background' });

Praktische implicaties

Hier is hoe je de optimalisatie van processing time aanpakt in WordPress en React/Next.js.

WordPress

WordPress biedt beperkte controle over scripts van derden. Veel scripts worden toegevoegd via plug-ins. Meestal voegen die scripts event listeners toe aan de pagina die niets anders doen dan de Interaction to Next Paint (INP) vertragen. Heeft je WordPress-site problemen met de INP door een lange processing time, neem dan de volgende stappen:

• Controleer de theme-instellingen. Vink onnodige opties zoals "smooth scroll" of "animated menu" uit. Dit soort instellingen veroorzaken vaak INP-problemen.
• Controleer welke scripts verantwoordelijk zijn voor de lange processing time (tip: gebruik het Chrome performance panel). Zijn die scripts gerelateerd aan een plug-in, overweeg dan een andere plug-in te zoeken die grofweg hetzelfde doet met minder JavaScript.
• Vaak draaien er custom scripts op de pagina. Controleer deze scripts. Zorg ervoor dat ze vaak yielden naar de main thread en wikkel minder belangrijke callbacks in een requestIdleCallback functie.
• Verwijder ongebruikte scripts per pagina (tip: gebruik wp_deregister_script). Sommige plug-ins injecteren scripts op elke pagina, zelfs wanneer de functionaliteit niet nodig is.
• Controleer je Tag Manager en verwijder ongebruikte of onnodige tags.
• Gebruik lichte en schone themes. Multipurpose themes die "alles doen" hebben doorgaans meer scripts en zwaardere event handlers.
• Vermijd page builders, aangezien zij voor het tonen van pagina's aan de gebruiker vaak zwaar leunen op JavaScript.

React / Next.js

De hooks en concurrency features van React maken het mogelijk om de INP processing time aanzienlijk te verlagen. Dit zijn de belangrijkste technieken:

Geef prioriteit aan de interactie van de gebruiker met React concurrency features:

React 18 introduceerde concurrency features die rendering optimaliseren voor een soepelere UX, vooral tijdens input.

• useTransition en startTransition: Markeer niet-cruciale updates voor latere rendering. Dit voorkomt dat grote updates interacties van de gebruiker blokkeren. Wikkel bijvoorbeeld een update van zoekresultaten in startTransition zodat het typen in het zoekveld responsief blijft.
• useDeferredValue: Splits je UI op in essentiële en minder cruciale secties. React kan het renderen van de minder cruciale delen onderbreken voor een responsievere ervaring. Dit is ideaal voor het renderen van gefilterde lijsten of zoekresultaten.
• useOptimistic (React 19+): Toon een tijdelijke, optimistische state terwijl asynchrone operaties (zoals netwerkverzoeken) lopen. Dit houdt de UI responsief, zelfs tijdens het ophalen van data.

Suspense voor het ophalen van data (React 18+)

Je kunt Suspense in React 18 gebruiken om de INP te verbeteren door de browser interacties van de gebruiker te laten prioriteren en rendering te optimaliseren. Waar React 16 Suspense introduceerde voor code splitting, breidt React 18 deze functionaliteit uit naar het ophalen van data.

• Een fallback-component, zoals een loading indicator, wordt getoond terwijl data laadt.
• Zodra de data binnen is, hervat React het renderen van het suspended component.
• Suspense geeft, in combinatie met interruptible rendering in Concurrent React, prioriteit aan de interactie van de gebruiker. Als een gebruiker interacteert met een suspended component, geeft React prioriteit aan het renderen van dat component. Zo behoud je de responsiviteit.

Deze features helpen React om interacties van de gebruiker prioriteit te geven boven render-werk in de achtergrond.

Ontdek de andere INP-fases

Processing time is slechts één onderdeel van de Interaction to Next Paint. Om je INP-scores volledig te optimaliseren, pak je ook de andere twee fases aan:

• Input delay: Minimaliseer de wachttijd voordat event handlers beginnen met draaien. De input delay veroorzaakt ongeveer 18% van de totale INP-tijd.
• Presentation delay: Verminder het render- en paint-werk dat goed is voor ongeveer 42% van de totale INP-tijd.

Voor een complete diagnostische workflow bekijk je onze gids over het vinden en oplossen van INP-problemen. Keer terug naar de INP hub-pagina voor het volledige overzicht.