16 Methoden, um JavaScript zu verzögern oder zu planen

Warum JavaScript verzögern oder planen?

JavaScript kann (und wird) Ihre Website auf verschiedene Weise verlangsamen. Dies kann alle möglichen negativen Auswirkungen auf die Core Web Vitals haben. JavaScript kann um Netzwerkressourcen konkurrieren, es kann um CPU- Ressourcen konkurrieren (den Main Thread blockieren) und es kann sogar das Parsen einer Webseite blockieren. Das Verzögern und Planen Ihrer Skripte kann die Core Web Vitals drastisch verbessern.

Zuletzt überprüft von Arjen Karel im Februar 2026

Um die unangenehmen Auswirkungen, die JavaScript auf die Core Web Vitals haben kann, zu minimieren, ist es in der Regel eine gute Idee, festzulegen, wann ein Skript in die Warteschlange zum Herunterladen gestellt wird, und zu planen, wann es CPU-Zeit beanspruchen und den Main Thread blockieren darf.

Wie kann sich das JavaScript-Timing auf die Core Web Vitals auswirken?

Wie kann sich das JavaScript-Timing auf die Core Web Vitals auswirken? Sehen Sie sich dieses Beispiel aus der Praxis an. Die erste Seite wird mit 'Render-Blocking' JavaScript geladen.  Die Paint-Metriken sowie die Total Blocking Time sind ziemlich schlecht. Das zweite Beispiel zeigt genau dieselbe Seite, jedoch mit verzögertem (deferred) JavaScript. Sie werden sehen, dass das LCP-Bild immer noch stark beeinträchtigt ist. Im dritten Beispiel wird dasselbe Skript nach dem 'load event' der Seite ausgeführt und die Funktionsaufrufe sind in kleinere Teile zerlegt. Letzteres besteht die Core Web Vitals mit viel Spielraum.

Standardmäßig blockiert externes JavaScript im head der Seite die Erstellung des Renderbaums. Genauer gesagt: Wenn der Browser auf ein Skript im Dokument stößt, muss er den DOM-Aufbau pausieren, die Kontrolle an die JavaScript-Laufzeitumgebung übergeben und das Skript ausführen lassen, bevor er mit dem DOM-Aufbau fortfährt. Dies wirkt sich auf Ihre Paint-Metriken (Largest Contentful Paint und First Contentful Paint) aus.

Verzögertes (deferred) oder async JavaScript kann sich immer noch auf Paint-Metriken auswirken, insbesondere auf den Largest Contentful Paint, da es ausgeführt wird und den Main Thread blockiert, sobald das DOM erstellt wurde (und gängige LCP-Elemente wie Bilder möglicherweise noch nicht heruntergeladen wurden).

Externe JavaScript-Dateien konkurrieren auch um Netzwerkressourcen. Externe JavaScript-Dateien werden in der Regel früher heruntergeladen als Bilder. Wenn Sie zu viele Skripte herunterladen, verzögert sich das Herunterladen Ihrer Bilder.

Zu guter Letzt kann JavaScript die Benutzerinteraktion blockieren oder verzögern. Wenn ein Skript CPU-Ressourcen verwendet (den Main Thread blockiert), reagiert ein Browser nicht auf Eingaben (Klicks, Scrollen usw.), bis dieses Skript abgeschlossen ist. Dies wirkt sich direkt auf Ihren Interaction to Next Paint (INP)-Score aus.

Die Auswirkungen sind messbar. Laut dem Web Almanac 2025 bestehen nur 15 % der mobilen Seiten das Audit für Render-Blocking-Ressourcen. Der Median der mobilen Total Blocking Time beträgt 1.916 Millisekunden. Das sind fast 2 volle Sekunden, in denen der Browser nicht auf Benutzereingaben reagieren kann. Die Wahl der richtigen Verzögerungsmethode für jedes Skript ist der Weg, wie Sie diese Zahl senken können.

Wie behebt das Planen oder Verzögern von JavaScript die Core Web Vitals?

Das Planen oder Verzögern von JavaScript behebt die Core Web Vitals nicht per se. Es geht darum, das richtige Werkzeug für die richtige Situation zu verwenden. In der Regel sollten Sie versuchen, Ihre Skripte so wenig wie möglich zu verzögern, sie aber für den Download in die Warteschlange stellen und zum richtigen Zeitpunkt ausführen.

Wie wählt man die richtige Methode zur Verzögerung?

Nicht alle Skripte sind gleich und jedes Skript hat seine eigene Funktionalität. Einige Skripte sind wichtig, um sie früh im Rendering-Prozess zu haben, andere nicht.

Ich kategorisiere JavaScripts gerne in 4 Gruppen basierend auf ihrem Wichtigkeitsgrad.

1. Render-kritisch. Dies sind die Skripte, die das Erscheinungsbild einer Webseite verändern. Wenn sie nicht geladen werden, sieht die Seite nicht vollständig aus. Diese Skripte sollten um jeden Preis vermieden werden. Wenn Sie sie aus irgendeinem Grund nicht vermeiden können, sollten sie nicht verzögert werden. Zum Beispiel ein Top-Slider oder ein A/B-Testing-Skript.
2. Kritisch. Diese Skripte verändern das Erscheinungsbild einer Webseite (zu sehr) nicht, aber die Seite funktioniert ohne sie nicht gut. Diese Skripte sollten mit defer oder async geladen werden. Zum Beispiel Ihre Menü-Skripte.
3. Wichtig. Dies sind Skripte, die Sie laden möchten, weil sie für Sie oder den Besucher wertvoll sind. Ich neige dazu, diese Skripte nach dem Auslösen des load event zu laden. Zum Beispiel Analytics oder ein 'Zurück nach oben'-Button.
4. Nice to have. Dies sind Skripte, ohne die Sie zur Not leben können. Ich lade diese Skripte mit der niedrigsten Priorität und führe sie nur aus, wenn der Browser im Leerlauf (idle) ist. Zum Beispiel ein Chat-Widget oder ein Facebook-Button.

Methode 1: Verwenden Sie das defer-Attribut

Skripte mit dem defer-Attribut werden parallel heruntergeladen und zur defer-JavaScript-Warteschlange hinzugefügt. Kurz bevor der Browser das DOMContentLoaded-Ereignis auslöst, werden alle Skripte in dieser Warteschlange in der Reihenfolge ausgeführt, in der sie im Dokument erscheinen.

<script defer src='javascript.js'></script>

Der 'defer-Trick' behebt in der Regel viele Probleme, insbesondere die Paint-Metriken. Leider gibt es keine Garantie, es hängt von der Qualität der Skripte ab. Verzögerte Skripte werden ausgeführt, sobald alle Skripte geladen und das HTML geparst ist (DOMContentLoaded). Das LCP-Element (meist ein großes Bild) ist bis dahin möglicherweise noch nicht geladen und die verzögerten Skripte verursachen dennoch eine Verzögerung beim LCP.

Wann man es verwenden sollte:

Verwenden Sie verzögerte (deferred) Skripte für kritische Skripte, die so schnell wie möglich benötigt werden.

Vorteile:

1. Verzögerte Skripte werden parallel heruntergeladen
2. Das DOM ist zum Ausführungszeitpunkt verfügbar

Nachteile:

1. Verzögerte Skripte können Ihre LCP-Metriken verzögern 
2. Verzögerte Skripte blockieren den Main Thread, sobald sie ausgeführt werden
3. Es ist möglicherweise nicht sicher, Skripte zu verzögern, wenn Inline- oder async-Skripte von ihnen abhängen

Methode 2: Verwenden Sie das async-Attribut

Skripte mit dem async-Attribut werden parallel heruntergeladen und unmittelbar nach Abschluss des Downloads ausgeführt.

<script async src='javascript.js'></script>

Async-Skripte tragen kaum zur Behebung Ihrer Pagespeed-Probleme bei. Es ist toll, dass sie parallel heruntergeladen werden, aber das war's auch schon. Sobald sie heruntergeladen sind, blockieren sie den Main Thread, während sie ausgeführt werden.

Wann man es verwenden sollte:

Verwenden Sie async-Skripte für kritische Skripte, die so schnell wie möglich benötigt werden und in sich geschlossen sind (nicht von anderen Skripten abhängen).

Vorteile:

1. Async-Skripte werden parallel heruntergeladen.
2. Async-Skripte werden so schnell wie möglich ausgeführt.

Nachteile:

1. DOMContentLoaded kann sowohl vor als auch nach async auftreten.
2. Die Ausführungsreihenfolge der Skripte ist im Vorfeld unbekannt.
3. Sie können keine async-Skripte verwenden, die von anderen async- oder verzögerten Skripten abhängen

Einen detaillierten Vergleich dieser beiden Ansätze finden Sie unter defer vs async und wie sich dies auf die Core Web Vitals auswirkt.

Methode 3: Verwenden Sie Module

Modulare Skripte werden standardmäßig verzögert (defer), es sei denn, sie haben das async-Attribut. In diesem Fall werden sie wie async-Skripte behandelt

<script module src='javascript.js'></script>

Module sind eine neue Art, über JavaScript nachzudenken, und beheben einige Designfehler. Abgesehen davon wird die Verwendung von Skript- Modulen Ihre Website nicht beschleunigen. 

Wann man es verwenden sollte:

Wenn Ihre Anwendung modular aufgebaut ist, ist es sinnvoll, auch JavaScript-Module zu verwenden.

Vorteile:

1. Module werden standardmäßig verzögert (defer)
2. Module sind einfacher zu warten und funktionieren hervorragend mit modularem Webdesign
3. Module ermöglichen eine einfache Code-Aufteilung (Code Splitting) mit dynamischen Importen, bei denen Sie nur die Module importieren, die Sie zu einem bestimmten Zeitpunkt benötigen.

Nachteile:

1. Module selbst verbessern die Core Web Vitals nicht
2. Das Importieren von Modulen Just-in-Time oder on the fly kann langsam sein und den INP verschlechtern 

Methode 4: Platzieren Sie Skripte am Ende der Seite

Footer-Skripte werden zu einem späteren Zeitpunkt für den Download in die Warteschlange gestellt. Dadurch werden andere Ressourcen priorisiert, die sich im Dokument oberhalb des script-Tags befinden.

<html>
   <head></head>
   <body>
      [your page contents here]
      <script defer src='javascript.js'></script>
   </body>
</html>

Das Platzieren Ihrer Skripte am Ende der Seite ist eine interessante Technik. Dadurch werden andere Ressourcen (wie Bilder) vor Ihren Skripten eingeplant. Dies erhöht die Chance, dass sie dem Browser zur Verfügung stehen und auf dem Bildschirm gezeichnet werden, bevor das Herunterladen der JavaScript-Dateien abgeschlossen ist und der Main Thread durch die Skriptausführung blockiert wird. Dennoch ... keine Garantie.

Wann man es verwenden sollte:

Wenn Ihre Skripte bereits recht gut performen, Sie aber andere Ressourcen wie Bilder und Webfonts leicht priorisieren möchten.

Vorteile:

1. Das Platzieren von Skripten am Ende der Seite erfordert nicht viel Wissen.
2. Wenn es richtig gemacht wird, besteht kein Risiko, dass dies Ihre Seite kaputt macht

Nachteile:

1. Kritische Skripte könnten später heruntergeladen und ausgeführt werden
2. Es behebt keine zugrunde liegenden JavaScript-Probleme

Methode 5: Skripte injizieren (inject)

Injizierte Skripte werden wie async-Skripte behandelt. Sie werden parallel heruntergeladen und werden unmittelbar nach dem Herunterladen ausgeführt.

<script>
    const loadScript = (scriptSource) => {
        const script = document.createElement('script');
        script.src = scriptSource;
        document.head.appendChild(script);
    }

    // call the loadscript function that injects 'javascript.js'
    loadScript('javascript.js');
</script>

Aus Sicht der Core Web Vitals ist diese Technik genau dieselbe wie die Verwendung von <script async>.

Wann man es verwenden sollte:

Diese Methode wird oft von Drittanbieter-Skripten verwendet, die so früh wie möglich ausgelöst werden sollen. Der Funktionsaufruf macht es einfach, Code zu kapseln und zu komprimieren.

Vorteile:

1. Eingekapselter Code, der ein async-Skript injiziert.

Nachteile:

1. DOMContentLoaded kann sowohl vor als auch nach dem Laden des Skripts auftreten.
   
2. Die Ausführungsreihenfolge der Skripte ist im Vorfeld unbekannt.
3. Sie können dies nicht für Skripte verwenden, die von anderen async- oder verzögerten Skripten abhängen

Methode 6: Skripte zu einem späteren Zeitpunkt injizieren

Nice-to-have-Skripte sollten meiner Meinung nach niemals verzögert (deferred) geladen werden. Sie sollten im günstigsten Moment injiziert werden. Im folgenden Beispiel wird das Skript ausgeführt, nachdem der Browser das 'load'-Ereignis gesendet hat.

<script>
window.addEventListener('load', function () {
  // see method 5 for the loadscript function
  loadScript('javascript.js');
});
</script>

Dies ist die erste Technik, die den Largest Contentful Paint zuverlässig verbessert. Alle wichtigen Ressourcen, einschließlich Bilder, werden heruntergeladen, wenn der Browser das 'load event' auslöst. Dies könnte alle möglichen Probleme verursachen, da es lange dauern kann, bis das load event aufgerufen wird.

Wann man es verwenden sollte:

Für Nice-to-have-Skripte, bei denen es keinen Grund gibt, die Paint-Metriken zu beeinflussen.

Vorteile:

1. Konkurriert nicht um kritische Ressourcen, da das Skript erst injiziert wird, sobald die Seite und ihre Ressourcen geladen sind

Nachteile:

1. Wenn Ihre Seite in Bezug auf Core Web Vitals schlecht gestaltet ist, kann es lange dauern, bis die Seite das 'load'-Ereignis sendet
2. Sie müssen aufpassen, dass Sie dies nicht auf kritische Skripte anwenden (wie Lazy Loading, Menü usw.)

Methode 7: Ändern Sie den Skript-Typ (und ändern Sie ihn dann zurück)

Wenn irgendwo auf der Seite ein script-Tag gefunden wird, das 1. ein type-Attribut hat und 2. das type- Attribut nicht "text/javascript" ist, wird das Skript von einem Browser nicht heruntergeladen und ausgeführt. Viele JavaScript-Loader (wie der RocketLoader von CloudFlare) basieren auf diesem Prinzip. Die Idee ist recht einfach und elegant.

Zuerst werden alle Skripte wie folgt umgeschrieben:

<script type="some-cool-script-type" src="javascript.js"></script>

Dann, zu einem bestimmten Zeitpunkt während des Ladevorgangs, werden diese Skripte wieder in 'normale JavaScripts' umgewandelt.

Wann man es verwenden sollte:

Dies ist keine Methode, die ich empfehlen würde. Das Beheben der Auswirkungen von JavaScript erfordert weitaus mehr, als nur jedes Skript ein Stück weiter nach hinten in der Warteschlange zu verschieben. Wenn Sie andererseits wenig Kontrolle über die auf der Seite ausgeführten Skripte haben oder über unzureichende JavaScript-Kenntnisse verfügen, ist dies möglicherweise Ihre beste Option.

Vorteile:

1. Es ist einfach: Aktivieren Sie einfach den Rocket Loader oder ein anderes Plugin, und alle Ihre Skripte werden nun zu einem etwas späteren Zeitpunkt ausgeführt.
2. Es wird wahrscheinlich Ihre Paint-Metriken beheben, vorausgesetzt, Sie haben kein JS-basiertes Lazy Loading verwendet.
3. Es funktioniert für Inline- und externe Skripte.

Nachteile:

1. Sie haben keine fein abgestufte Kontrolle darüber, wann die Skripte ausgeführt werden
2. Schlecht geschriebene Skripte könnten kaputtgehen
3. Es verwendet JavaScript, um JavaScript zu beheben
4. Es trägt nicht dazu bei, lang laufende Skripte zu beheben

Methode 8: Verwenden Sie den Intersection Observer

Mit dem Intersection Observer können Sie eine Funktion ausführen (die in diesem Fall ein externes JavaScript lädt), wenn ein Element in den sichtbaren Viewport gescrollt wird.

<script>
const handleIntersection = (entries, observer) => {
    if (entries?.[0].isIntersecting) {
        // load your script or execute another
           function like trigger a lazy loaded element
        loadScript('javascript.js');

        // remove the observer
        observer.unobserve(entries?.[0].target);
    }
};
const Observer = new window.IntersectionObserver()
Observer.observe(document.querySelector('footer'));
</script>

Dies ist mit Abstand die effektivste Methode zur Verzögerung von JavaScript, die es gibt. Laden Sie nur die Skripte, die Sie benötigen, kurz bevor Sie sie benötigen. Leider ist die Realität selten so sauber und nicht viele Skripte können an ein Element gebunden werden, das in den sichtbaren Bereich scrollt.

Wann man es verwenden sollte:

Verwenden Sie diese Technik so oft wie möglich! Wann immer ein Skript nur mit einer Off-Screen-Komponente (wie einer Karte, einem Slider, einem Formular) interagiert, ist dies der beste Weg, dieses Skript zu injizieren.

Vorteile:

1. Beeinträchtigt nicht die Core Web Vitals LCP und FCP
2. Injiziert niemals Skripte, die nicht verwendet werden. Dies verbessert den INP

Nachteile:

1. Sollte nicht mit Komponenten verwendet werden, die sich möglicherweise im sichtbaren Viewport befinden
2. Ist schwerer zu warten als einfaches <script src="...">
3. Könnte einen Layout Shift verursachen

Methode 9: Verwenden Sie readystatechange

document.readystate kann als Alternative zum 'DOMContentLoaded'- und 'load'-Ereignis verwendet werden. Der 'interactive' readystate ist in der Regel ein guter Zeitpunkt, um kritische Skripte aufzurufen, die das DOM ändern oder Event-Handler hinzufügen müssen. 
Der 'complete' ready state ist ein guter Zeitpunkt, um Skripte aufzurufen, die weniger kritisch sind.

document.addEventListener('readystatechange', (event) => {
  if (event.target.readyState === 'interactive') {
    initLoader();
  } else if (event.target.readyState === 'complete') {
    initApp();
  }
});

Methode 10: Verwenden Sie setTimeout ohne Timeout

setTimeout ist eine verpönte, aber stark unterschätzte Methode in der Pagespeed-Community. setTimeout hat einen schlechten Ruf bekommen, weil es oft missbraucht wird.  Viele Entwickler glauben, dass setTimeout nur verwendet werden kann, um die Skriptausführung um die eingestellte Anzahl von Millisekunden zu verzögern. Obwohl dies wahr ist, tut setTimeout eigentlich etwas viel Interessanteres. Es erstellt einen neuen Task am Ende der Event Loop des Browsers. Dieses Verhalten kann verwendet werden, um Ihre Tasks effektiv zu planen. Es kann auch verwendet werden, um lange Tasks in separate, kleinere Tasks zu unterteilen

<script>
   setTimeout(() => {
       // load a script or execute another function
       console.log('- I am called from a 0ms timeOut()')
    }, 0);

   console.log('- I was last in line but executed first')

   /*
      Output:
      - I was last in line but executed first
      - I am called from a 0ms timeOut()
   */
</script>

Wann man es verwenden sollte:

setTimeout erstellt einen neuen Task in der Event Loop des Browsers. Verwenden Sie dies, wenn Ihr Main Thread durch viele nacheinander ablaufende Funktionsaufrufe blockiert wird.

Vorteile:

1. Kann lang laufenden Code in kleinere Stücke aufteilen.

Nachteile:

1. setTimeout ist eine ziemlich grobe Methode und bietet keine Priorisierung für wichtige Skripte.
2. Fügt den auszuführenden Code am Ende der Loop (Schleife) hinzu

Methode 11: Verwenden Sie setTimeout mit einem Timeout

Die Dinge werden noch interessanter, wenn wir setTimeout mit einem Timeout von mehr als 0ms aufrufen

<script>
   setTimeout(() => {
       // load a script or execute another function
       console.log('- I am called from a 10ms timeOut()')
    }, 10);

   setTimeout(() => {
       // load a script or execute another function
       console.log('- I am called from a 0ms timeOut()')
    }, 0);

   console.log('- I was last in line but executed first')

   /*
      Output:
      - I was last in line but executed first
      - I am called from a 0ms timeOut()
      - I am called from a 10ms timeOut()
   */
</script>

Wann man es verwenden sollte:

Wenn Sie eine einfache Methode benötigen, um ein Skript nach dem anderen zu planen, reicht ein kleines Timeout aus

Vorteile:

1. Wird von allen Browsern unterstützt

Nachteile:

1. Bietet kein erweitertes Scheduling (Planung)

Methode 12: Verwenden Sie ein Promise, um einen Microtask festzulegen

Das Erstellen eines Microtasks ist ebenfalls eine interessante Möglichkeit, JavaScript zu planen. Microtasks werden so geplant, dass sie unmittelbar nach Abschluss der aktuellen Ausführungsschleife (execution loop) ausgeführt werden.

<script>
   const myPromise = new Promise((resolve, reject) => {
      resolve();
   }).then(
      () => {
         console.log('- I was scheduled after a promise')
         }
   );

   console.log('- I was last in line but executed first')

   /*
      Output:
      - I was last in line but executed first
      - I was scheduled after a promise
   */
</script>

Wann man es verwenden sollte:

Wenn ein Task unmittelbar nach einem anderen Task geplant werden muss. 

Vorteile:

1. Der Microtask wird unmittelbar nach Beendigung des Tasks geplant.
2. Ein Microtask kann verwendet werden, um weniger wichtige Teile von JavaScript-Code im selben Ereignis zu verzögern. 

Nachteile:

1. Unterteilt den Main Thread nicht in kleinere Teile. Der Browser hat keine Chance, auf Benutzereingaben zu reagieren.
2. Sie werden Microtasks wahrscheinlich nie benötigen, um die Core Web Vitals zu verbessern, es sei denn, Sie wissen bereits ganz genau, was Sie tun.

Methode 13: Verwenden Sie einen Microtask

Das gleiche Ergebnis kann durch die Verwendung von queueMicrotask() erzielt werden. Der Vorteil der Verwendung von queueMicrotask() gegenüber einem Promise ist, dass es etwas schneller ist und Sie Ihre Promises nicht handhaben müssen.

<script>
   queueMicrotask(() => {
      console.log('- I am a microtask')
   })

   console.log('- I was last in line but executed first')

   /*
      Output:
      - I was last in line but executed first
      - I am a microtask
   */
</script>

Methode 14: Verwenden Sie requestIdleCallback

Die Methode window.requestIdleCallback() stellt eine Funktion in die Warteschlange, die während der Leerlaufzeiten (idle periods) des Browsers aufgerufen werden soll. Dies ermöglicht es Entwicklern, Hintergrund- und Arbeit mit niedriger Priorität in der Haupt-Event-Loop (main event loop) auszuführen, ohne latenzkritische Ereignisse wie Animationen und Eingabereaktionen zu beeinträchtigen. Funktionen werden im Allgemeinen in der First-in-First-out-Reihenfolge aufgerufen; Callbacks, für die ein Timeout angegeben ist, können jedoch bei Bedarf in einer anderen Reihenfolge aufgerufen werden, um sie auszuführen, bevor das Timeout abläuft.

<script>
requestIdleCallback(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
});
</script>

Wann man es verwenden sollte:

Verwenden Sie dies für Skripte, die Nice to have sind, oder zur Behandlung nicht kritischer Tasks nach Benutzereingaben

Vorteile:

1. Führt JavaScript mit minimalen Auswirkungen auf den Benutzer aus
2. Wird höchstwahrscheinlich den INP verbessern

Nachteile:

1. Keine Garantie, dass der Code jemals ausgelöst wird 

Methode 15: Verwenden Sie postTask

Die Methode scheduler.postTask() ermöglicht es Benutzern, optional eine Mindestverzögerung (minimum delay) anzugeben, bevor der Task ausgeführt wird, eine Priorität für den Task und ein Signal, mit dem die Priorität des Tasks geändert und/oder der Task abgebrochen werden kann. Sie gibt ein Promise zurück, das mit dem Ergebnis der Task-Callback-Funktion aufgelöst oder mit dem Abbruchgrund oder einem im Task geworfenen Fehler abgelehnt wird.

<script>
scheduler.postTask(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
}, { priority: 'background' });
</script>

Wann man es verwenden sollte:

postTask ist die richtige API, um Skripte zu planen, wenn Sie eine fein abgestufte Kontrolle über die Priorität benötigen.

Vorteile:

1. Vollständige Kontrolle über das Scheduling der JavaScript-Ausführung!

Nachteile:

1. Wird in Safari nicht unterstützt. Wird in Chrome 94+, Edge 94+ und Firefox 142+ unterstützt. Verwenden Sie Feature Detection und einen setTimeout-Fallback für eine vollständige Abdeckung.

Methode 16: Verwenden Sie scheduler.yield()

scheduler.yield() ist die neueste Methode, um lange Tasks aufzuteilen. Es gibt ein Promise zurück, das in einem neuen Task aufgelöst wird, was dem Browser die Chance gibt, zwischen den Arbeitspaketen (chunks of work) auf Benutzereingaben zu reagieren. Im Gegensatz zu setTimeout erhält die Fortsetzung Vorrang vor anderen in der Warteschlange befindlichen Tasks, sodass Ihr Code dort weitermacht, wo er aufgehört hat, ohne ans Ende der Warteschlange geschoben zu werden.

<script>
async function processItems(items) {
    for (const item of items) {
        doWork(item);
        await scheduler.yield();
    }
}
</script>

Dies ist das mit Abstand beste Werkzeug zur Verbesserung des INP. Lange Tasks, die den Main Thread für Hunderte von Millisekunden blockieren, können in kleinere Stücke aufgeteilt werden, die jeweils durch einen Yield-Point (Unterbrechungspunkt) getrennt sind. Der Browser kann Benutzereingaben an jedem Yield-Point verarbeiten. Einen praktischen Durchlauf durch dieses Muster finden Sie unter wie man einen Yield an den Main Thread durchführt.

Safari unterstützt scheduler.yield() noch nicht, fügen Sie daher immer einen Fallback ein:

<script>
function yieldToMain() {
    if (globalThis.scheduler?.yield) {
        return scheduler.yield();
    }
    return new Promise(resolve => {
        setTimeout(resolve, 0);
    });
}

async function processItems(items) {
    for (const item of items) {
        doWork(item);
        await yieldToMain();
    }
}
</script>

Wann man es verwenden sollte:

Verwenden Sie dies immer dann, wenn Sie lang laufendes JavaScript haben, das den Main Thread blockiert. Es ist der empfohlene Ansatz zur Verbesserung des INP bei Interaktions-Handlern und jeglichem Code, der Daten in einer Schleife verarbeitet.

Vorteile:

1. Unterteilt lange Tasks, ohne Ihren Platz in der Warteschlange zu verlieren
2. Die Fortsetzung läuft vor anderen in der Warteschlange befindlichen Tasks ab (im Gegensatz zu setTimeout, das ans Ende der Warteschlange wandert)
3. Verbessert den INP direkt, indem es dem Browser die Chance gibt, auf Benutzereingaben zu reagieren

Nachteile:

1. Wird in Safari nicht unterstützt. Wird in Chrome 129+, Edge 129+ und Firefox 142+ unterstützt.
2. Erfordert einen Fallback für die vollständige Browserabdeckung (setTimeout funktioniert als Polyfill)

Nachdem Sie diese Techniken angewendet haben, überprüfen Sie die Verbesserung mit Real User Monitoring. Lighthouse-Scores sind ein Ausgangspunkt, aber Felddaten von echten Benutzern sind das, was Google für das Ranking verwendet. CoreDash trackt den INP und alle Core Web Vitals von echten Besuchern, sodass Sie sehen können, ob Ihre Defer-Strategie in der Produktion tatsächlich funktioniert.