Hoe u kunt overdragen aan de main thread om INP te verbeteren

Yield naar de main thread

Stel je een romantische film voor. De setting is een kleine Franse markt in het centrum van een klein dorpje. De straten zijn gevuld met stelletjes die koffie drinken, croissants eten en bloemen kopen. Stel je nu voor wat er gebeurt als slechts één koper tegelijk iets van een verkoper kan kopen, terwijl alle anderen op hun beurt moeten wachten. De bakker wordt overspoeld met verzoeken, er ontstaan ruzies bij de bloemist en de romantische wandeling verandert in een frustrerend wachten.

Nou ... dat is ongeveer wat er gebeurt op een website als het te druk wordt.

Laatst beoordeeld door Arjen Karel op maart 2026

Waarom yielding belangrijk is voor INP

De main thread van een browser handelt alle belangrijke processen af: het parsen van HTML en CSS, het uitvoeren van JavaScript, het afhandelen van input-events zoals klikken en scrollen, en de visuele rendering. Het draait op een single-threaded model, wat betekent dat het slechts één taak tegelijk kan uitvoeren. Wanneer een taak begint te draaien, voert de browser deze uit tot hij klaar is en stopt niet voordat hij klaar is. Er wordt geen andere taak ingepland totdat de huidige klaar is. Dit wordt het blokkeren van de main thread genoemd.

Het blokkeren van de main thread is de primaire oorzaak van slechte Interaction to Next Paint (INP) scores. Wanneer een bezoeker op een knop klikt en uw JavaScript de main thread gedurende 200ms blokkeert, kan de browser geen reactie tonen totdat het script klaar is. De processing time fase van INP meet precies deze vertraging. Volgens de 2025 Web Almanac is de mediane mobiele Total Blocking Time 1.916ms, een stijging van 58% ten opzichte van het voorgaande jaar. Dat is bijna 2 seconden waarin de browser niet kan reageren op gebruikersinvoer.

Eén manier om dit op te lossen is door te yielden naar de main thread. Yielding is een techniek waarbij lange taken worden opgesplitst in meerdere kleinere taken om de browser in staat te stellen belangrijker werk (zoals reageren op gebruikersinvoer) tussendoor af te handelen.

Lange taken en blokkeringsperiode: Wanneer een taak langer duurt dan 50 milliseconden, wordt deze geclassificeerd als een lange taak, en alles boven die drempel van 50 milliseconden staat bekend als de "blokkeringsperiode" van de taak. Door deze lange taken op te splitsen in kleinere stukken kan de browser responsief blijven, zelfs bij het afhandelen van rekenintensieve bewerkingen.

Oude yielding strategieën

Vóór de Prioritized Task Scheduling API waren er 4 manieren om te yielden naar de main thread. Allemaal hebben ze beperkingen.

• setTimeout(): De meest voorkomende strategie. setTimeout() met een vertraging van 0 voegt de taak toe aan het einde van de wachtrij, waardoor andere taken eerst kunnen draaien. Het probleem: taken kunnen alleen naar het einde van de wachtrij worden gepusht, dus andere scripts kunnen voordringen voordat uw code wordt hervat. Geneste setTimeout() aanroepen leggen ook een minimale vertraging van 5ms op na vijf ronden.
• requestAnimationFrame(): Plaatst een functie in de wachtrij om te worden uitgevoerd vóór de volgende repaint van de browser. Vaak gecombineerd met setTimeout() om ervoor te zorgen dat callbacks worden ingepland na de volgende layout-update. Niet ontworpen voor yielding; ontworpen voor animatiewerk.
• requestIdleCallback(): Het meest geschikt voor niet-kritieke taken met een lage prioriteit die kunnen draaien tijdens de downtime van de browser. De beperking: er is geen garantie dat geplande taken onmiddellijk (of überhaupt) zullen draaien op een drukke main thread.
• isInputPending(): Controleert op openstaande gebruikersinvoer en yieldt alleen als er invoer wordt gedetecteerd. Google raadt deze aanpak niet langer aan. Het kan fout-negatieve resultaten opleveren en houdt geen rekening met ander prestatiekritisch werk zoals animaties en rendering-updates.

scheduler.yield()

De beperkingen van deze methoden waren een punt van zorg voor het Chrome-team, vooral omdat veel sites niet slagen voor INP. Om dit aan te pakken, hebben ze scheduler.yield() gebouwd: een nieuwe API waarmee ontwikkelaars onmiddellijk kunnen yielden naar de main thread zonder de volgorde van taken te veranderen of complexiteit toe te voegen.

scheduler.yield() werd stabiel uitgebracht in Chrome 129 (september 2024) en wordt nu ondersteund door alle grote browsers behalve Safari.

Codevoorbeeld

Omdat Safari scheduler.yield() nog niet ondersteunt, gebruikt u een fallback naar setTimeout():

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

De yieldToMain() functie controleert of window.scheduler.yield bestaat. Als dat het geval is, gebruikt het de native API. Zo niet, dan valt de code terug op setTimeout(). Dit komt overeen met het door Google aanbevolen patroon.

Voor projecten die de volledige Prioritized Task Scheduling API nodig hebben (inclusief scheduler.postTask() en TaskController), onderhoudt Google Chrome Labs een officiële polyfill.

Voorbeeld uit de praktijk: zoeken verbeteren met yieldToMain()

Hier leest u hoe yieldToMain() de zoekervaring voor uw gebruikers kan verbeteren.

De handleSearch() functie werkt eerst de inhoud van de knop bij om onmiddellijke feedback te geven dat er een zoekopdracht wordt uitgevoerd, en yieldt vervolgens om de browser in staat te stellen die update te renderen. Vervolgens haalt fetchData() zoekgegevens op en toont updateHTML(data) de resultaten. Een andere yieldToMain() zorgt voor een snelle layout-update. Ten slotte worden minder belangrijke taken ingepland tijdens de idle time van de browser. Merk op dat ik niet heb geyield vóór requestIdleCallback(), omdat dit sowieso alleen draait als de main thread idle is.

async function handleSearch() {
  /* update snel de inhoud van de knop na het verzenden */
  updateButtonToPending();

  /* Yield naar de Main Thread */
  await yieldToMain();

  /* gegevens ophalen en html bijwerken */
  const data = await fetchData();
  updateHTML(data);

  /* Opnieuw yielden naar de Main Thread */
  await yieldToMain();

  /* sommige functies mogen alleen draaien tijdens browser idle time */
  requestIdleCallback(sendDataToAnalytics);
}

Zie voor een ander praktisch voorbeeld hoe u ditzelfde yield-patroon kunt gebruiken met dataLayer pushes om te voorkomen dat analytics-scripts interacties blokkeren.

Waarom scheduler.yield() beter is

In tegenstelling tot setTimeout(), dat uitgestelde taken toevoegt aan het einde van de taakwachtrij, pauzeert scheduler.yield() de uitvoering en plaatst het vervolg aan de voorkant van de wachtrij. Uw code wordt hervat zodra werk met een hogere prioriteit (zoals het afhandelen van input-callbacks) is voltooid. Dit is het belangrijkste verschil: u kunt yielden naar de main thread zonder het risico dat andere scripts voordringen voordat uw code wordt hervat.

scheduler.yield() is ook ontworpen om te werken met de Prioritized Task Scheduling API. Wanneer aangeroepen binnen een scheduler.postTask() callback, erft scheduler.yield() het prioriteitsniveau van de taak. Deze combinatie geeft u fijnmazige controle over hoe uw JavaScript wordt geprioriteerd en wanneer deze yieldt.

Browserondersteuning

scheduler.yield() wordt ondersteund door 71,5% van de browsers wereldwijd:

• Chrome 129+ en Edge 129+: stabiel sinds september 2024
• Firefox 142+: stabiel sinds augustus 2025
• Safari: niet ondersteund, geen aangekondigde planning

De setTimeout() fallback in de yieldToMain() functie hierboven zorgt ervoor dat uw code in alle browsers werkt. Safari-gebruikers krijgen het oudere gedrag waarbij vervolgtaken achteraan de wachtrij komen, maar de pagina yieldt nog steeds. Naarmate de browserondersteuning groeit, zullen meer gebruikers automatisch profiteren van de snellere hervatting.

Als het probleem is dat scripts van derden de main thread volledig blokkeren, is het uitstellen van die scripts een betere eerste stap dan yielding. Yielding helpt wanneer uw eigen code veel werk moet verrichten, maar u wilt dat de browser responsief blijft tussen de brokken door.

Om te verifiëren of yielding uw INP in de praktijk verbetert, monitort u uw pagina's met Real User Monitoring. Lab-tools zoals Lighthouse meten de Total Blocking Time, maar alleen veldgegevens laten u de werkelijke INP zien die uw bezoekers ervaren.