Zusammenfassung

  • Der erste öffentliche W3C-Entwurf vom September 2015 führte requestIdleCallback ein: Die Seite bittet um Ausführung in einer vom Browser erwarteten Leerlaufphase. Ein IdleDeadline liefert mit timeRemaining() eine Schätzung der verbleibenden Zeit.
  • Die Texte von 2017 und 2025 behalten die Aufgabenteilung bei. Der Browser findet die Lücke, die Seite zerlegt ihre Arbeit. Ein optionales timeout kann eine lange wartende Aufgabe auch ohne Leerlauf zur Ausführung bringen.

Webseiten sind ausgezeichnet darin, Nebenaufgaben anzusammeln. Daten könnten noch verarbeitet, ein möglicher nächster Bildschirm vorbereitet und ein lokaler Zustand aufgeräumt werden. Jede Aufgabe hat eine plausible Begründung. Zusammen machen sie aus einem einfachen Klick leicht einen Besuch beim Amt: Man zieht eine Nummer und hofft, dass bald jemand Zeit hat. Der Browser soll derweil auf Eingaben reagieren und das nächste Bild zeichnen. Seine freie Zeit ist ein knappes Gut, das niemand allein durch Lautstärke erwerben sollte.

Mit setTimeout konnten Autoren bereits einen späteren Zeitpunkt bestellen. Die Uhr klingelte, ohne zu wissen, ob der Browser gerade eine Animation zeichnete. Der erste öffentliche W3C-Entwurf vom 17. September 2015 verlegte die Terminwahl zu der Instanz, die den eigenen Arbeitsplan sieht. Die Seite ruft requestIdleCallback auf. Erwartet der Browser eine Ruhephase, ruft er die Funktion und übergibt ein IdleDeadline. Dessen timeRemaining() schätzt den noch verfügbaren Zeitraum. Der Browser stellt den Raum bereit; die Seite entscheidet, welchen Karton sie hineinträgt.

Der Entwurf begrenzte eine Leerlaufphase auf höchstens 50 Millisekunden. Ein neuer Fingertipp kann den Zeitraum weiter verkürzen. Deshalb passt die Arbeit in kleine Stücke: einen Schritt ausführen, die Restzeit ansehen, anhalten und später erneut um einen Termin bitten. Die Bezeichnung einer langen Schleife als „Idle-Aufgabe“ zerschneidet diese Schleife nicht. Wer eine komplette Inventur beginnt, weil die Ladentür gerade kurz leer ist, lässt den nächsten Kunden vor verschlossener Kasse stehen.

Der frühe Text führte eine schrittweise Berechnung als Beispiel an. Gerade ihre Banalität zeigt die Neuerung. Der Browser kann einen günstigen Zeitpunkt nennen, aber er kennt die innere Struktur der Aufgabe nicht. Der Seitenautor muss sinnvolle Haltepunkte bauen. So entsteht die Zusammenarbeit: Die eine Seite kennt anstehende Eingaben und Zeichenvorgänge, die andere ihre Daten und die Größe eines Arbeitspakets. Der Kalender allein erledigt keine Hausarbeit.

Die Candidate Recommendation vom 31. Januar 2017 und die Proposed Recommendation vom 10. Oktober 2017 nahmen auch die Frage auf, was bei Dauerbetrieb geschieht. Eine Aufgabe kann sonst endlos auf einen ruhigen Moment warten. Mit timeout setzt der Autor eine Grenze. Nach ihrem Ablauf kann der Callback laufen; didTimeout verrät, dass die Frist und nicht der freie Platz den Ausschlag gab. Das ist ein nützlicher Notausgang. Wenn jedoch jede Bibliothek ihn zur normalen Tür erklärt, sitzen Hintergrundarbeiten mitten im Publikumsverkehr.

Die W3C-Veröffentlichungsgeschichte führt vom ersten Entwurf 2015 über die Schritte von 2017 zu späteren Fassungen. Auch der Arbeitsentwurf vom 21. Mai 2025 beschreibt die vom Browser bestimmte Leerlaufphase und die geschätzte Frist für den Callback. Nach einem Jahrzehnt steht dieselbe praktische Grenze im Zentrum: Der Browser verfügt über den gemeinsamen Takt, während die Seite selbst entscheiden muss, welche Vorbereitungen ihren Preis wert sind.

Für Betreiber wird damit die Auswahl der Arbeit zur eigentlichen Strategie. Eine bald benötigte Ansicht vorzubereiten, kann dem Leser Zeit sparen. Jede freie Lücke mit allem zu füllen, was ein Skript für dringlich hält, treibt die Warteschlange wieder hoch. Gute Hintergrundarbeit fällt kaum auf. Man tippt, die Seite antwortet, und irgendwo hinter der Bühne ist bereits etwas für den nächsten Schritt bereit. Das ist ein voller Erfolg für einen Mechanismus, der nur in leeren Augenblicken tätig werden soll.