INP Processing Time: Oorzaken, optimalisatie en codevoorbeelden

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

Deze pagina maakt deel uit van onze Interaction to Next Paint (INP) serie. De INP meet de totale tijd van een gebruikersinteractie tot de volgende visuele update. Processing time is de tweede van de drie fasen waaruit de INP bestaat, voorafgegaan door input delay en gevolgd door presentation delay. Als INP nieuw voor u is, lees dan eerst onze gids over hoe u INP-problemen kunt identificeren en oplossen.

In het kort: 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 kan worden onderverdeeld in 3 componenten: "input delay", "processing time", en "presentation delay".

Processing time is een belangrijke factor in de totale INP en is gemiddeld verantwoordelijk voor ongeveer 40% van de vertraging. Het optimaliseren van uw event handlers is de meest directe manier om de processing time te verkorten en uw INP-score te verbeteren.

INP TIP: de processing time kan worden geoptimaliseerd door belangrijke code die voorafgaat aan de lay-outupdate onmiddellijk uit te voeren en alle andere code daarna in te plannen.

Wat is processing time?

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

Processing time verwijst naar de tijd die de browser nodig heeft om alle bijbehorende event callbacks uit te voeren nadat een gebruiker interactie heeft gehad met een webpagina (bijvoorbeeld het klikken op een knop of het indrukken van een toets). Hoewel er altijd enige processing time is, treden INP-problemen op wanneer de event callbacks te veel processing time in beslag nemen.

Simpel gezegd: processing time is de duur van het "werk" dat gebeurt in reactie op uw interactie. Wanneer u op een zoekknop klikt, omvat de processing time alles van het valideren van uw zoekopdracht, het voorbereiden van de API-aanvraag, het bijwerken van de lokale status, het triggeren van analytics-events en alle andere code die aan dat click-event is gekoppeld. Elke regel JavaScript in die event handlers draagt bij aan de processing time.

Processing time en de INP

Processing time is misschien wel het eerste waar u aan denkt bij het optimaliseren van de Interaction to Next Paint. Het is de "klus die moet worden geklaard" voordat de lay-out door de browser kan worden bijgewerkt.

Veel ontwikkelaars denken bij het verbeteren van de INP aan het optimaliseren van callback-functies (het optimaliseren van de processing time), en ze hebben gelijk. Maar qua belang is processing time niet eens het allerbelangrijkste onderdeel om te verbeteren. Het maakt nog steeds gemiddeld ongeveer 40% van de totale INP-tijd uit.

Bij CoreDash verzamelen we elk uur miljoenen Core Web Vitals-gegevenspunten. Op basis van die gegevens is de processing time verantwoordelijk voor 40% van de Interaction to Next Paint. 40% is veel, maar het optimaliseren van alleen de processing time zal INP-problemen niet oplossen. U moet ook kijken naar input delay (18%) en presentation delay (42%).

Voorbeeld van processing time: Wanneer een gebruiker op een knop klikt om een formulier te verzenden, dragen de code die de formuliergegevens valideert, de gegevens naar de server verzendt en de reactie verwerkt allemaal bij aan de processing time. Hoe langer deze bewerkingen duren, hoe langer de processing time en hoe potentieel slechter 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 onmiddellijke relevantie voor de gebruikersinteractie kan de uitvoeringstijd van de callback verlengen. Dit omvat analytics-aanroepen, logging en statussynchronisatie die niet voltooid hoeven te zijn voor de volgende paint.
   
2. Niet-geoptimaliseerde code. Inefficiënte code (meestal loops of inefficiënte DOM-lookups) kan ervoor zorgen dat de event callbacks langzamer draaien dan nodig is. Een veelvoorkomend voorbeeld is het opvragen van de DOM binnen een loop met document.querySelectorAll() in plaats van het resultaat voor de loop te cachen.
   
3. Geclusterde callbacks. Meerdere event callbacks die kort na elkaar zijn gepland, creëren een wachtrij. Als een callback die door de gebruikersinteractie wordt getriggerd vast komt te zitten in deze wachtrij, lijkt de reactie vertraagd. Een pointerdown handler, een mousedown handler en een click handler kunnen bijvoorbeeld allemaal achter elkaar vuren voor een enkele klik.
   
4. Layout thrashing. Frequente DOM-manipulaties die lay-out-herberekeningen triggeren, kunnen de browser zwaar belasten en leiden tot prestatievermindering. Dit gebeurt wanneer uw code afwisselend lay-out-eigenschappen leest en schrijft binnen een loop, waardoor de browser de lay-out meerdere keren moet herberekenen.

Processing time minimaliseren

De strategie is tweeledig: bestaande code optimaliseren (onnodige code verwijderen en de huidige code optimaliseren) en onderscheid maken tussen code die voor en na de lay-outupdate moet draaien. Code die cruciaal is voor de lay-outupdate moet eerst draaien, en alle andere code kan na de lay-outupdate draaien.

1. Verwijder ongebruikte code. Hoewel het verwijderen van ongebruikte code een inkopper lijkt, is er op de meeste sites wel wat oude ongebruikte code die gewoon wordt uitgevoerd zonder echt iets toe te voegen aan de pagina of de UX. Het eerste wat u moet doen is ervoor zorgen dat er geen code draait die niet nodig is. Dit kan worden gedaan door tree shaking, code splitting, het inspecteren van uw code coverage in Chrome en door een goede IDE te gebruiken die ongebruikte code aangeeft. (Pro-tip: kijk ook kritisch naar resources die door uw Tag Manager worden geladen.) 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 bottlenecks in uw code te identificeren en richt u op die gebieden voor optimalisatie. Overweeg technieken als memoization, pre-calculatie en caching om overbodige berekeningen te vermijden. (Tip: u kunt het Chrome performance paneel gebruiken om scripts met een lange uitvoeringstijd te vinden.)
   
3. Prioriteer kritieke code en plan andere code in. Wanneer de callback-code is geoptimaliseerd, splitst u de code in code die onmiddellijk moet draaien en code die kan worden uitgesteld. Kijk eens naar dit praktijkvoorbeeld:
   
   In dit voorbeeld worden Google Tag Manager en Facebook event callbacks uitgevoerd voor de (React) code die voorafgaat aan de lay-outupdate. De oplossing is om de GTM- en Facebook-callbacks in te plannen voor wanneer de browser idle is.
4. Vermijd layout thrashing of reflow. Layout thrashing gebeurt wanneer stijlupsates en stijllezingen worden gemengd in een loop, waardoor de browser de lay-out talloze keren opnieuw moet berekenen. Om layout thrashing te voorkomen, voert u alle stijlwijzigingen (de "sets") uit voordat u stijlwaarden opvraagt (de "gets"). Deze aanpak minimaliseert de frequentie van lay-outupdates, wat leidt tot een snellere pagina. Bijvoorbeeld, in een loop die de breedte van elke paragraaf instelt op de breedte van een element, leest u de breedte van het element één keer voor de loop en gebruikt u die waarde om de breedtes van de paragrafen binnen de loop bij te werken.

Event handlers opsplitsen met setTimeout(0)

Wanneer u code niet kunt verwijderen of uitstellen uit een event handler, is de volgende beste optie om de handler op te splitsen in kleinere stukken. Het setTimeout(callback, 0) patroon stelt u in staat om werk over meerdere taken te verdelen, waardoor de browser de kans krijgt om de lay-outupdate tussendoor af te handelen. Hier is een praktisch voorbeeld:

\/\/ Voor: één lange event handler blokkeert de volgende paint
button.addEventListener('click', () => {
  updateUI();           \/\/ Kritiek: moet voor de paint draaien
  validateForm();       \/\/ Belangrijk maar kan wachten
  sendAnalytics();      \/\/ Niet-kritiek
  syncLocalStorage();   \/\/ Niet-kritiek
});

\/\/ Na: opsplitsen in kritiek en uitgesteld werk
button.addEventListener('click', () => {
  updateUI();  \/\/ Kritiek: draait onmiddellijk voor de paint

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

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

Het nadeel van setTimeout(0) is dat het de voortzetting aan het einde van de takenwachtrij plaatst. Als er al andere taken in de wachtrij staan, draait de uitgestelde code mogelijk niet onmiddellijk. Gebruik voor voorspelbaarder gedrag scheduler.yield() (zie de sectie hieronder). Voor patronen die specifiek gericht zijn op JavaScript scroll-afhandeling, zie onze speciale gids.

requestAnimationFrame gebruiken voor visuele updates

Wanneer uw event handler een visuele update moet triggeren, zorgt requestAnimationFrame() ervoor dat uw code op het optimale moment draait: vlak voordat de browser zijn volgende repaint uitvoert. Dit is vooral handig wanneer u DOM-lezingen en -schrijvingen in batches moet uitvoeren om layout thrashing te voorkomen.

\/\/ Gebruik requestAnimationFrame om visuele updates te groeperen
button.addEventListener('click', () => {
  \/\/ Lees lay-out-eigenschappen eerst (buiten rAF)
  const containerWidth = container.offsetWidth;

  requestAnimationFrame(() => {
    \/\/ Schrijf lay-out-eigenschappen binnen rAF
    items.forEach(item => {
      item.style.width = containerWidth + 'px';
    });
  });

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

Dit patroon scheidt DOM-lezingen van DOM-schrijvingen, waardoor forced synchronous layout wordt voorkomen. De visuele update draait op het ideale moment in de randerings-pipeline van de browser, en niet-visueel werk draait tijdens idle-tijd.

Hoe kritieke code te prioriteren

"Prioriteer kritieke code en plan andere code in" klinkt abstract, dus hier is hoe het er in de praktijk uitziet. We kunnen kritieke code prioriteren door requestIdleCallback() te gebruiken en door de main thread de ruimte te geven (yielding).

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

\/* voor: code onmiddellijk uitvoeren *\/
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

\/* na: dezelfde code uitvoeren tijdens browser idle *\/
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

Het nadeel van requestIdleCallback is dat code mogelijk niet zo snel draait als u zou willen. In dat geval kunt u "de main thread de ruimte geven" (yield to the main thread) nadat de belangrijkste code is uitgevoerd, waardoor de browser een moment krijgt om de lay-outupdate uit te voeren. Hier is een voorbeeld van hoe u taken kunt opsplitsen door de main thread de ruimte te geven:

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() {
  \/\/ Doe hier de belangrijkste lay-outupdates
  await yieldToMain();
  \/\/ Doe andere taken die zo snel mogelijk na de lay-outupdate moeten draaien
}

Fijnmazige planning met scheduler.postTask()

De functie scheduler.postTask() biedt een fijnmazigere planning van taken door prioriteiten in te stellen, wat de browser helpt werk te prioriteren zodat taken met een lage prioriteit de main thread de ruimte geven. Controleer de browserondersteuningstabel voordat u deze API in productie gebruikt.

De functie postTask() accepteert drie prioriteitsinstellingen: "background" voor taken met de laagste prioriteit, "user-visible" voor taken met een gemiddelde prioriteit, en "user-blocking" voor kritieke taken die een hoge prioriteit vereisen.

Door de juiste prioriteit toe te wijzen aan elk stukje werk binnen uw event handler, kunt u ervoor zorgen dat de browser gebruikersinteracties responsief afhandelt terwijl alle noodzakelijke taken toch worden voltooid:

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

\/\/ Plan gegevenssynchronisatie in met gemiddelde 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 leest u hoe u de optimalisatie van de processing time aanpakt op WordPress en React/Next.js.

WordPress

WordPress biedt beperkte controle als het gaat om scripts van derden. Veel scripts worden toegevoegd via plugins. Meestal voegen die scripts event listeners toe aan de pagina die niets anders doen dan de Interaction to Next Paint (INP) vertragen. Als uw WordPress-site problemen heeft met de INP veroorzaakt door een lange processing time, neem dan de volgende stappen:

• Controleer de thema-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 paneel). Als die scripts plugin-gerelateerd zijn, overweeg dan een andere plugin te zoeken die ongeveer hetzelfde doet met minder JavaScript.
• Vaak draaien er aangepaste scripts op de pagina. Controleer die scripts en zorg ervoor dat ze de main thread vaak de ruimte geven (yield) en wikkel minder belangrijke callbacks in een requestIdleCallback functie.
• Verwijder ongebruikte scripts per pagina (tip: gebruik wp_deregister_script). Sommige plugins hebben de neiging om scripts op elke pagina te injecteren, zelfs wanneer de functionaliteit niet nodig is.
• Controleer uw Tag Manager en verwijder ongebruikte of onnodige tags.
• Gebruik slanke en schone thema's. Multifunctionele thema's die "alles doen" hebben de neiging om meer scripts en zwaardere event handlers te hebben.
• Vermijd page builders, omdat deze vaak zwaar leunen op JavaScript voor het presenteren van pagina's aan de eindgebruiker.

React / Next.js

React's hooks en concurrency-functies maken het mogelijk om de INP processing time aanzienlijk te verminderen. Hier zijn de belangrijkste technieken:

Prioriteer gebruikersinteractie met React concurrency-functies:

React 18 introduceerde concurrency-functies die het renderen optimaliseren voor een soepelere gebruikerservaring, vooral tijdens invoer.

• useTransition en startTransition: Markeer niet-kritieke updates voor later renderen. Dit voorkomt dat grote updates de gebruikersinteractie blokkeren. Wikkel bijvoorbeeld een update van zoekresultaten in startTransition zodat het typen in het zoekvak responsief blijft.
• useDeferredValue: Splits uw UI op in essentiële en minder kritieke secties. React kan het renderen van de minder kritieke onderdelen onderbreken voor een responsievere ervaring. Dit is ideaal voor het renderen van gefilterde lijsten of zoekresultaten.
• useOptimistic (React 19+): Toon een tijdelijke, optimistische status terwijl asynchrone bewerkingen (zoals netwerkaanvragen) gaande zijn. Dit houdt de UI responsief, zelfs tijdens het ophalen van gegevens.

Suspense voor het ophalen van gegevens (React 18+)

Suspense in React 18 kan worden gebruikt om INP te verbeteren door de browser in staat te stellen gebruikersinteracties te prioriteren en het renderen te optimaliseren. Terwijl React 16 Suspense introduceerde voor code splitting, breidt React 18 deze functionaliteit uit naar het ophalen van gegevens.

• Een fallback-component, zoals een laadindicator, wordt weergegeven terwijl gegevens worden geladen.
• Zodra de gegevens binnen zijn, hervat React het renderen van de suspended component.
• Suspense, gecombineerd met onderbreekbaar renderen in Concurrent React, prioriteert gebruikersinteracties. Als een gebruiker interactie heeft met een suspended component, geeft React prioriteit aan het renderen van die component, waardoor de responsiviteit behouden blijft.

Deze functies helpen React om gebruikersinteracties te prioriteren boven randerings-werk op de achtergrond.

Verken de andere INP-fasen

Processing time is slechts één onderdeel van de Interaction to Next Paint. Om uw INP-scores volledig te optimaliseren, moet u ook de andere twee fasen aanpakken:

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

Voor een volledige diagnostische workflow, zie onze gids over hoe u INP-problemen kunt vinden en oplossen, en keer terug naar de INP-hub-pagina voor het volledige overzicht.