Interaction to Next Paint - Verwerkingstijd

Interaction to Next Paint (INP) problemen veroorzaakt door verwerkingstijd

In ons vorige artikel hebben we gesproken over de interaction to next paint en hoe je interaction to next paint problemen identificeert. Als je de basis wilt nalezen, is dit een geweldige plek om te beginnen!

In dit artikel zal ik me concentreren op 'verwerkingstijd'. Hoe dit de Interaction To Next Paint problemen beïnvloedt en vervolgens uitleggen hoe je de verwerkingstijd kunt minimaliseren om de interaction to next paint te verbeteren!

In het kort: De Interaction to Next Paint (INP) meet hoe lang het duurt voordat een visuele verandering op een pagina te zien is nadat een gebruiker interactie heeft gehad met de pagina. Deze INP kan worden onderverdeeld in 3 componenten: 'input delay', 'processing time' en 'presentation delay'. Verwerkingstijd is een belangrijke bijdrager aan de totale INP, goed voor gemiddeld ongeveer 40% van de vertraging.  Dit betekent dat het optimaliseren van je JavaScript-code, met name event handlers, een aanzienlijke invloed kan hebben op de INP-score van je website.

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

Wat is verwerkingstijd?

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

Verwerkingstijd verwijst naar de tijd die de browser nodig heeft om de bijbehorende event callback te verwerken nadat een gebruiker interageert met een webpagina (bijv. klikken op een knop of drukken op een toets). Hoewel er altijd enige verwerkingstijd is, treden INP-problemen op wanneer de event callbacks te veel verwerkingstijd in beslag nemen.

Verwerkingstijd en de INP

Verwerkingstijd is misschien wel 'het ding' als je denkt aan het optimaliseren van de Interaction To Next Paint. Het is de 'klus die geklaard moet worden' voordat de lay-out door de browser kan worden bijgewerkt.

Veel ontwikkelaars denken aan het verbeteren van de INP in termen van het optimaliseren van de callback-functie (het optimaliseren van de verwerkingstijd) en ze hebben gelijk. Maar qua belangrijkheid is verwerkingstijd niet eens het belangrijkste deel om te verbeteren, maar het maakt gemiddeld nog steeds ongeveer 40% uit van de totale INP-tijd.

Bij CoreDash verzamelen we elk uur miljoenen core web vitals datapunten. Op basis van die gegevens is de verwerkingstijd goed voor 40% van de Interaction to Next Paint. En hoewel dat veel is, zal het optimaliseren van de verwerkingstijd alleen waarschijnlijk niet genoeg zijn om INP-problemen op te lossen

Voorbeeld verwerkingstijd: Wanneer een gebruiker interageert met een webpagina, zoals het klikken op een knop, wordt de tijd die het duurt voordat de event handler die aan die knopklik is gekoppeld zijn uitvoering voltooit, verwerkingstijd genoemd. Bijvoorbeeld, als een gebruiker op een knop klikt om een formulier te verzenden, zou de code die de formuliergegevens valideert, deze naar de server verzendt en de reactie afhandelt, bijdragen aan de verwerkingstijd. Hoe langer deze bewerkingen duren, hoe langer de verwerkingstijd en mogelijk hoe slechter de INP-score.

Wat veroorzaakt hoge verwerkingstijd?

Om INP-problemen veroorzaakt door hoge verwerkingstijd op te lossen, moeten we begrijpen wat de mogelijke oorzaak van hoge verwerkingstijd kan zijn.  Hoge verwerkingstijd, de tijd die het duurt voordat event callbacks volledig zijn uitgevoerd, kan worden veroorzaakt door onnodige code, niet-geoptimaliseerde code, geclusterde callbacks en layout thrashing. Laten we die 4 gebieden eens nader bekijken.

1. Onnodige code. Oude, ongebruikte code of code zonder directe relevantie voor de gebruikersinteractie, kan de uitvoeringstijd van callbacks verlengen.
   
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.
   
3. Geclusterde callbacks: Meerdere event callbacks die dicht bij elkaar zijn gepland, creëren een wachtrij. Als een callback die door de gebruikersinteractie wordt geactiveerd in deze wachtrij vastloopt, lijkt de reactie vertraagd.
   
4. Layout thrashing: Frequente DOM-manipulaties die lay-out herberekeningen activeren, kunnen de browser belasten en leiden tot prestatieverminderingen.

Minimaliseer verwerkingstijd

Om verwerkingstijd te minimaliseren, moeten we ervoor zorgen dat de code die verantwoordelijk is voor de daaropvolgende lay-outupdate zo snel mogelijk werkt. We kunnen dit doen door bestaande code te optimaliseren (onnodige code verwijderen en de huidige code optimaliseren) en door onderscheid te maken tussen code die voor en na de lay-outupdate moet draaien. In feite moet code die kritiek is voor de lay-outupdate ervoor draaien en alle andere code kan na de lay-outupdate draaien.

1. Verwijder ongebruikte code.  Hoewel het verwijderen van ongebruikte code misschien een no-brainer lijkt, is er op de meeste sites op zijn minst wat oude ongebruikte code die gewoon wordt uitgevoerd zonder echt iets toe te voegen aan de pagina of de UX.  Dit betekent dat het eerste wat je moet doen, is ervoor zorgen dat er geen code draait die niet nodig is. Dit kan op vele manieren worden gedaan. Bijvoorbeeld door  een proces dat tree shaking of code splitting wordt genoemd. Of handmatig door je code coverage in Chrome te inspecteren en ook door een goede IDE te gebruiken die hint naar ongebruikte code. (Pro tip: kijk ook kritisch naar resources die door je Tag Manager worden geladen)
2. Minimaliseer Callback Execution Time: Gebruik een JavaScript-profiler om knelpunten in je code te identificeren en richt je op die gebieden voor optimalisatie. Overweeg technieken zoals memoization, pre-calculation en caching om redundante berekeningen te voorkomen. (Tip: je kunt het Chrome performance panel gebruiken om scripts met een lange uitvoeringstijd te vinden!)
   
3. Prioriteer kritieke code en plan andere code: Wanneer de callback-code is geoptimaliseerd, splits je de code op in code die onmiddellijk moet draaien en code die kan worden uitgesteld. Bekijk dit praktijkvoorbeeld:
   
   In dit voorbeeld worden Google Tag Manager en Facebook events callback uitgevoerd vóór de (REACT) code die voorafging aan de lay-outupdate. De oplossing zou zijn geweest om de GTM callbacks te plannen wanneer de browser inactief is
4. Vermijd Layout Thrashing of reflow. Layout thrashing gebeurt wanneer stijluitupdates en stijlleesslagen in een lus worden gemengd, waardoor de browser de lay-out talloze keren opnieuw moet berekenen. 
   Om layout thrashing te voorkomen, voer je alle stijlwijzigingen (de "sets") uit voordat je stijlwaarden opvraagt (de "gets"). Deze aanpak minimaliseert de frequentie van lay-outupdates, wat leidt tot een snellere webpagina.
   Bijvoorbeeld, in een lus die de breedte van elke paragraaf instelt om overeen te komen met de breedte van een element, lees je de breedte van het element één keer voordat de lus begint en gebruik je die waarde om de breedtes van de paragrafen binnen de lus bij te werken.

Hoe prioriteer je kritieke code

Het laatste item 'Prioriteer kritieke code en plan andere code' is misschien een beetje abstract voor velen van jullie. We kunnen kritieke code prioriteren door requestIdleCallback() te gebruiken en door de main thread voorrang te geven.

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

/* before :: immediately run code  */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* after :: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

Het nadeel van requestIdleCallback is dat code misschien niet zo snel draait als je zou willen. In dat geval kunnen we 'yielden aan de main thread' nadat de belangrijkste code heeft gedraaid en daarmee de browser een moment geven om de lay-outupdates uit te voeren. Hier is een voorbeeld van hoe taken kunnen worden opgesplitst door te yielden aan 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(){
 // do the most important layout updates here
 await yieldToMain();
 // do other tasks that need to run as asap after the layout update
}

In de toekomst zouden we veel meer kunnen doen met de window.scheduler dan alleen yielden aan de main thread. . We zouden ook taken kunnen prioriteren met behulp van de scheduler API (zie [url=https://caniuse.com/mdn-api_scheduler_posttask]Support Table[/url]).

De scheduler API biedt de postTask() functie voor fijnmazigere planning van taken door prioriteiten in te stellen, wat de browser helpt werk te prioriteren zodat taken met lage prioriteit wijken voor de main thread. 

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

Door kritieke taken te prioriteren met 'user-blocking', kunnen ontwikkelaars ervoor zorgen dat ze met een hogere prioriteit worden uitgevoerd, waardoor de browser gebruikersinteracties responsiever kan afhandelen. De scheduler API biedt de postTask() functie voor fijnmazigere planning van taken door prioriteiten in te stellen, wat de browser helpt werk te prioriteren zodat taken met lage prioriteit wijken voor de main thread. 

Praktische implicaties

Laten we naar de belangrijkste vraag gaan: 'Wat betekent dit allemaal voor mijn site'. Laten we het opsplitsen voor WordPress & REACT en kijken hoe je de Interaction to Next Paint kunt verbeteren als het gaat om verwerkingstijd.

WordPress

WordPress biedt erg weinig controle als het gaat om scripts. Veel scripts worden toegevoegd via plug-ins. Meestal zullen die scripts 'event listeners' aan de pagina toevoegen die niets anders doen dan de interaction to next paint (INP) vertragen.  Als je WordPress-site problemen heeft met de Interaction to Next Paint veroorzaakt door lange verwerkingstijd, neem dan de volgende stappen:

• Controleer de thema-instellingen. Vink onnodige opties uit zoals 'smooth scroll' of 'geanimeerd menu'. Instellingen zoals deze veroorzaken vaak INP-problemen.
• Controleer welke scripts verantwoordelijk zijn voor de lange verwerkingstijd (tip: gebruik het Chrome performance panel). Als die scripts plug-in-gerelateerd zijn, overweeg dan om een andere plug-in te zoeken die ongeveer hetzelfde doet
• Vaak draaien er aangepaste scripts op de pagina. Controleer die scripts en zorg ervoor dat ze vaak yielden aan de main thread en verpak minder belangrijke callbacks in een requestIdleCallback functie
• Laad ongebruikte scripts uit op pagina-basis (tip: gebruik wp_deregister_script). Sommige plug-ins hebben de neiging om scripts op elke pagina te injecteren, zelfs als de functionaliteit niet nodig is.
• Controleer je Tag Manager en verwijder ongebruikte of onnodige tags.
• Gebruik lichte en schone thema's. Vaak hebben multifunctionele thema's die 'alles doen' de neiging om meer scripts te hebben
• Vermijd paginabouwers omdat ze vaak zwaar leunen op JavaScript voor het presenteren van pagina's aan de eindgebruiker

REACT / NextJS

React hooks en features maken het mogelijk om de INP verwerkingstijd te verminderen:

Prioriteer gebruikersinteractie met React Concurrency Features:

React's concurrency features geïntroduceerd in versies 16 en 18 bieden hooks en mechanismen om rendering te optimaliseren voor een soepelere gebruikerservaring, vooral tijdens input.

• useTransition & startTransition: Markeer niet-kritieke updates voor latere rendering. Dit voorkomt dat grote updates gebruikersinteractie blokkeren.
• useDeferredValue: Splits je UI op in essentiële en minder kritieke secties. React kan het renderen van de minder kritieke delen onderbreken voor een responsievere ervaring.
• useOptimistic: Toon een tijdelijke, optimistische status terwijl asynchrone bewerkingen (zoals netwerkverzoeken) aan de gang zijn. Dit houdt de UI responsief, zelfs tijdens het ophalen van gegevens.

Suspense voor Data Fetching (React 18+):

Suspense in React 18 kan worden gebruikt om INP (Interaction to Next Paint) te verbeteren door de browser toe te staan gebruikersinteracties te prioriteren en rendering te optimaliseren. Terwijl React 16 Suspense introduceerde voor code splitting, breidt React 18 deze functionaliteit uit om ook data fetching te omvatten.

• Een fallback-component, zoals een ladingsindicator, wordt weergegeven terwijl gegevens worden geladen.
  
• Zodra gegevens binnenkomen, hervat React het renderen van de geschorste component.
• Suspense, gecombineerd met onderbreekbare rendering in Concurrent React, prioriteert gebruikersinteracties. Als een gebruiker interageert met een geschorste component, prioriteert React het renderen van die component, waardoor de responsiviteit behouden blijft.

Over het algemeen werken deze functies samen om ervoor te zorgen dat React gebruikersinteracties prioriteert en voorkomt dat de UI wordt geblokkeerd tijdens updates of het ophalen van gegevens.