5 JavaScript-Prioritätsstufen und wie man sie nutzt

Nicht alle Skripte sind gleich

Eines war schon immer klar: Nicht jedes JavaScript ist gleich. Einige Skripte kümmern sich um kritische Interaktionen wie „Menü-Interaktion“ oder „In den Warenkorb“, während andere Skripte weitaus weniger wichtig sind. Nehmen Sie zum Beispiel Ihr „Exit-Intent“-Popup-Skript, das Besucher, die Ihre Website verlassen wollen, einlädt, einen Fragebogen auszufüllen. Ich bin mir sicher, wir könnten alle ohne Letztere leben, aber es wäre wirklich schwer, ohne Erstere auf einer Website zu navigieren.

Doch auf „Ihrer durchschnittlichen Website“ wird dieser Unterschied auf technischer Ebene kaum jemals gemacht. Alle JavaScripts werden der Seite „einfach hinzugefügt“ und der Browser muss damit klarkommen. Nun, das ist ein Problem, denn Ihr Browser hat keine Ahnung, was wichtig ist und was nicht. Wir als Entwickler wissen das. Also lassen Sie uns das beheben!

Zuletzt überprüft von Arjen Karel im März 2026

Die mediane mobile Seite lädt 646 KB JavaScript über 22 Anfragen, so der 2025 Web Almanac. Etwa 44 % dieses JavaScripts wird nie ausgeführt. Nur 13 % der Seiten bestehen das Lighthouse-Audit für renderblockierende Ressourcen. Das Problem ist nicht nur, wie viel JavaScript Sie laden. Es ist das Wann und in welcher Reihenfolge.

Wie die JavaScript-Priorität die Core Web Vitals beeinflussen kann

Skripte einfach ohne die richtigen Überlegungen zur Seite hinzuzufügen, kann alle 3 der Core Web Vitals beeinträchtigen. Den Largest Contentful Paint, den Interaction to Next Paint und den Cumulative Layout Shift.

Beispiel: Die LCP-Netzwerkressource wird durch renderblockierende JavaScripts verzögert

Der Largest Contentful Paint ist anfällig für Bandbreiten- und CPU-Wettbewerb. Wenn zu viele Skripte um frühe Netzwerkressourcen kämpfen, verzögert dies die Largest Contentful Paint-Netzwerkressource, und frühe CPU-Arbeit verzögert den LCP durch Blockieren des Main Threads.

Der Interaction to Next Paint kann durch Skripte beeinträchtigt werden, die direkt vor einer Interaktion ausgeführt werden. Wenn Skripte ausgeführt werden, blockieren sie den Main Thread und verzögern jede Interaktion während dieser Ausführungszeit.

Skripte können auch einen Cumulative Layout Shift verursachen, wenn Skripte „verändern, wie die Seite aussieht“. Werbe-Skripte, die Banner in die Seite einfügen, und Slider sind berüchtigt dafür.

5 Arten von JavaScript-Prioritäten

Ich unterscheide gerne zwischen 5 Arten von JavaScript-Prioritäten.

• Render Critical: Diese Skripte gehören zu den schlimmsten. Sie verändern das Layout der Seite und ohne das Laden dieser Skripte wird das Layout völlig anders sein. Beispiel: einige Slider-Skripte oder ein A/B-Test.
• Critical Scripts: Diese Skripte verarbeiten kritische Seitenfunktionen und ohne diese Skripte sind kritische Aufgaben wie das Hinzufügen eines Produkts zum Warenkorb, die Website-Suche oder die Navigation nicht möglich.
• Important Scripts: Diese Skripte verarbeiten wichtige Geschäftslogik und Ihre Website hängt von diesen ab. Zum Beispiel: Analytics.
• Nice to Have Scripts: Diese Skripte sind Nice-to-Have, aber wenn es hart auf hart kommt, brauchen wir sie nicht wirklich, damit die Seite funktioniert. Zum Beispiel ein Chat-Widget oder ein Exit-Intent.
• Future Scripts: Diese Skripte könnten kritisch oder Nice-to-Have sein, aber wir brauchen sie jetzt nicht, da „andere Schritte“ unternommen werden müssen, bevor wir diese Skripte tatsächlich verwenden können. Zum Beispiel ein mehrstufiges Checkout-Skript.

Bevor wir uns jede Prioritätsstufe ansehen, hier ist, wie Chrome verschiedenen Skripttypen Netzwerkpriorität zuweist:

Das Verständnis dieser Standardeinstellungen ist der Schlüssel zur Ressourcenpriorisierung.

1. Render-Critical Scripts

Diese Skripte verändern das Layout der Seite direkt. Ohne sie sieht die Seite völlig anders aus als das beabsichtigte Design. Beispiele hierfür sind Skripte für Slider oder A/B-Testing-Frameworks, die das Layout früh im Ladevorgang ändern.

Das Problem bei diesen Skripten ist, dass sie nicht aufgeschoben oder verzögert werden können. Jede Verzögerung führt dazu, dass sich das Layout der Website verschiebt, was zu einer schlechten UX führt und die Core Web Vitals fehlschlagen lässt.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Best Practices:

• Vermeiden Sie Render Critical Scripts, wann immer es möglich ist. Schreiben Sie Ihren Code so um, dass die Abhängigkeit von dieser Art von Skripten entfällt.
• Wenn es sich nicht vermeiden lässt, inlinen Sie diese Skripte oder laden Sie nur die absolut notwendigen Teile davon.
• Verwenden Sie kein defer oder async für diese Skripte und platzieren Sie sie ganz oben im head, um einen Download 'so früh wie möglich' auszulösen.

2. Critical Scripts

Diese Skripte ermöglichen grundlegende Interaktionen. Ohne sie werden kritische Aufgaben wie Website-Navigation, das Hinzufügen von Artikeln zum Warenkorb, Cookie-Hinweise oder die Durchführung einer Suche unmöglich. Sie sind für die Kernfunktionalität der Website unverzichtbar.

Diese Skripte sollten im head der Seite platziert werden, entweder mit dem async- oder dem defer-Attribut. Für einen vollständigen Vergleich dieser beiden Ansätze, siehe async vs. defer und wie sie die Core Web Vitals beeinflussen.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Best Practices:

• Beschränken Sie solche Skripte auf ein Minimum und kombinieren Sie diese Funktionalität nicht mit anderen, weniger kritischen Funktionen.
• Laden Sie diese Skripte frühzeitig mit async oder defer, abhängig von ihren Abhängigkeiten.
• Nutzen Sie Real User Monitoring, um Engpässe in der Ausführung zu identifizieren und sicherzustellen, dass ihre Performance mit den Nutzeranforderungen übereinstimmt.

3. Important Scripts

Diese Skripte unterstützen Ihr Geschäft, werden aber nicht für das Funktionieren der Seite benötigt. Analytics-Skripte liefern zum Beispiel essentielle Daten, müssen aber nicht vor wichtigeren visuellen Elementen geladen werden. Die Unterscheidung zwischen Critical und Important Scripts kann Ansichtssache sein, sprechen Sie also unbedingt mit allen Stakeholdern, bevor Sie diese Priorität festlegen!

Es gibt 2 zuverlässige Wege, die Skript-Priorität für diese Arten von Skripten zu senken.

<html>
<head>
<!-- method 1: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 2: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1: Nach DOMContentLoaded injizieren

Indem Sie das Skript nach dem DOMContentLoaded-Event injizieren, stellen Sie sicher, dass der Download des Skripts direkt nach dem vollständigen Parsen des HTML beginnt. Dies ermöglicht es entdeckbaren Ressourcen, wie Bildern und Schriftarten, Vorrang zu haben. Diese Methode bietet ein Gleichgewicht: Das Skript beginnt früh genug zu laden, um Verzögerungen in der Funktionalität zu vermeiden, konkurriert aber nicht mit frühen Ressourcen, die für das anfängliche Rendering der Seite entscheidend sind.

2: Am Ende der Seite platzieren

Diese klassische Technik zögert das Laden von Skripten hinaus, bis der Browser das gesamte Dokument verarbeitet hat, und erzielt in etwa das gleiche Ergebnis wie Technik 1. Der einzige Unterschied besteht darin, dass Technik 1 den Preload Scanner Ihres Browsers überspringt, während diese Technik dies nicht tut. Der Preload Scanner ist ein leichtgewichtiger Schnellscanner, den Ihr Browser verwendet, um kritische Ressourcen schnell zu identifizieren und in die Warteschlange einzureihen. Das Überspringen des Preload Scanners könnte eine gute Idee sein, wenn die Möglichkeit von lazy-loaded Bildern im Viewport besteht, während die Verwendung des Preload Scanners das Laden für dieses Skript beschleunigt.

Eine Anmerkung zu fetchpriority: Sie könnten erwarten, dass fetchpriority="low" bei einem deferierten Skript dessen Priorität senken würde. Das tut es nicht. Deferred und async Skripte laden in Chrome bereits mit Low-Priorität. Das Hinzufügen von fetchpriority="low" zu ihnen hat keinen Effekt. Das fetchpriority-Attribut macht nur einen Unterschied bei blockierenden Skripten, wo es die Priorität von Highest auf High senken kann. Für weitere Möglichkeiten, JavaScript aufzuschieben, lesen Sie unseren vollständigen Leitfaden.

4. Nice-to-Have Scripts

Diese Skripte verbessern die UX, sind aber für die Funktion der Website nicht erforderlich. Beispiele hierfür sind Chat-Widgets, Kunden-Feedback-Popups oder optionale Animationen.

Diese Skripte sind ein idealer Kandidat für ein Muster namens 'lazy on load'. Das bedeutet: Warten Sie auf das Load-Event der Seite und injizieren Sie das Skript dann in der Idle-Zeit. Das Warten auf das Load-Event stellt sicher, dass das Skript nicht mit wichtigeren frühen Ressourcen um Bandbreite und CPU konkurriert. Das Warten auf einen Idle-Moment stellt sicher, dass der Browser keine wichtigeren Aufgaben wie Benutzereingaben verarbeitet.

Hier ist ein funktionierendes Beispiel:

window.addEventListener("load", () => {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  idle(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

Der setTimeout-Fallback wird benötigt, da Safari requestIdleCallback nicht unterstützt. Bei Skripten, die ihre Ausführung ebenfalls in kleinere Blöcke aufteilen müssen, sollten Sie die Verwendung von scheduler.yield() in Betracht ziehen, um den Main Thread reaktionsfähig zu halten und Ihren INP-Score zu schützen.

Best Practices:

• Laden Sie diese Skripte per Lazy-Loading, nachdem die Seite geladen wurde, und warten Sie auf einen Idle-Moment.
• Machen Sie sich bewusst, dass Skripte, die mit diesem Muster geladen werden, nicht garantiert schnell laden.

Über von CoreDash überwachte Websites hinweg erzielen Seiten, die unkritische Skripte auf nach dem Load-Event aufschieben (defer), bei INP zu 84 % ein 'good', verglichen mit 61 % bei Seiten, die alle Skripte sofort (eager) laden.

5. Future Scripts

Future Scripts sind solche, die erst benötigt werden, wenn bestimmte Bedingungen erfüllt sind. Zum Beispiel wird ein mehrstufiges Checkout-Skript erst relevant, nachdem ein Nutzer Artikel in seinen Warenkorb gelegt hat. Diese Skripte können bis viel später in der User Journey warten.

Sehen Sie sich dieses Beispiel an. Es verwendet den IntersectionObserver, um die JS-Logik nur dann zu laden, wenn sie benötigt wird: wenn sich das Formular im sichtbaren Viewport befindet.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Best Practices:

• Laden Sie diese Skripte On-Demand, ausgelöst durch Benutzeraktionen.
• Verwenden Sie Code-Splitting-Techniken, um nur die Teile bereitzustellen, die bei jedem Schritt erforderlich sind.
• Injizieren Sie sie dynamisch nur bei Bedarf, etwa wenn ein Benutzer zu einem bestimmten Abschnitt scrollt.

Die meisten Websites benötigen nur zwei Muster: defer für alles Funktionale und das Load+Idle-Muster für alles andere. Wenn Sie Zeit damit verbringen, fetchpriority bei Skripten feinzutunen, verkomplizieren Sie es wahrscheinlich. Holen Sie sich zuerst die großen Gewinne: verschieben (defer) Sie, was Sie können, verzögern Sie, was Sie können, und löschen Sie, was Sie nicht brauchen.