Optimierung der JavaScript-Priorität für schnellere Ladezeiten

Erfahren Sie, wie Sie Skripte effektiv priorisieren, um die Core Web Vitals zu steigern.

Arjen Karel - linkedin

Last update: 2024-12-12

Management von JavaScript-Prioritäten für bessere Web-Performance

Eines war schon immer klar: Nicht alles JavaScript ist gleich. Einige Skripte handhaben kritische Interaktionen wie 'Menüinteraktion' oder 'In den Warenkorb', während andere Skripte weit weniger wichtig sind. Nehmen wir Ihr 'Exit Intent' Popup-Skript, das Besucher, die im Begriff sind, Ihre Seite zu verlassen, einlädt, einen Fragebogen auszufüllen. Ich bin sicher, wir könnten alle ohne die letzten leben, aber es wäre wirklich schwer, eine Website ohne die ersten zu navigieren.

Dennoch wird auf 'Ihrer durchschnittlichen Website' auf technischer Ebene diese Unterscheidung fast nie gemacht. Alle JavaScripts werden 'einfach hinzugefügt' zur Seite und der Browser muss es herausfinden. Das ist jetzt ein Problem, weil Ihr Browser keine Ahnung hat, was wichtig ist und was nicht. Wir als Entwickler tun das. Also lassen Sie uns das reparieren!

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

Einfach Skripte zur Seite hinzuzufügen, ohne die richtige Überlegung, kann alle 3 Core Web Vitals beeinflussen. Den Largest Contentful Paint, den Interaction to Next Paint und den Cumulative Layout Shift.

javascript lcp impact example

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

Der Largest contentful Paint ist anfällig für Bandbreiten- und CPU-Konkurrenz. 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 beeinflusst 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 'ändern, wie die Seite aussieht'. Werbeskripte, die Banner in die Seite injizieren, und Slider sind berüchtigt dafür.

5 Arten von JavaScript-Prioritäten

Ich unterscheide gerne zwischen 5 Arten von JavaScript-Prioritäten. Lassen Sie uns diese kurz besprechen, bevor wir eintauchen.

Render Critical: Diese Skripte gehören zu den schlimmsten. Sie ä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.
Kritische Skripte: Diese Skripte handhaben kritische Seitenfunktionalität und ohne diese Skripte sind kritische Aufgaben wie das Hinzufügen eines Produkts zu einem Warenkorb, Seitensuche oder Navigation nicht möglich.
Wichtige Skripte. Diese Skripte handhaben wichtige (Geschäfts-)Logik und Ihre Seite hängt von diesen ab. Zum Beispiel: Analytics
Nice-to-have Skripte. Diese Skripte sind nett zu haben, 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
Zukünftige Skripte. Diese Skripte könnten kritisch oder nice-to-have sein, aber wir brauchen sie jetzt nicht, weil 'andere Schritte' unternommen werden müssen, bevor wir diese Skripte tatsächlich verwenden können. Zum Beispiel ein mehrstufiges Checkout-Skript.

Jetzt, da wir eine Vorstellung von Skriptprioritäten haben, lassen Sie es uns aufschlüsseln!

1. Render-Kritische Skripte

Diese sind die störendsten Skripte, da sie direkt beeinflussen, wie die Seite angezeigt wird. Ohne sie kann das Layout brechen oder drastisch anders aussehen als beabsichtigt. Beispiele sind Skripte für Slider oder A/B-Testing-Frameworks, die das Layout früh im Ladeprozess ändern.

Das Problem mit diesen Arten von Skripten ist, dass sie nicht deferred oder verzögert werden können. Jede Verzögerung führt dazu, dass sich das Website-Layout verschiebt, was eine schlechte UX verursacht und zum Scheitern der Core Web Vitals führt.

<!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-kritische Skripte wie dieses, wann immer möglich. Schreiben Sie Ihren Code neu, um die Abhängigkeit von diesen Arten von Skripten zu vermeiden.
Wenn es sich nicht vermeiden lässt, inlinen Sie oder laden Sie nur die absolut notwendigen Teile dieser Skripte.
Verwenden Sie für diese Skripte kein defer oder async und platzieren Sie sie oben im Head, um einen Download 'so früh wie möglich' auszulösen.

2. Kritische Skripte

Diese Skripte ermöglichen fundamentale Interaktionen. Ohne sie werden kritische Aufgaben wie Seitennavigation, Hinzufügen von Artikeln zu einem Warenkorb, Cookie-Hinweis oder Durchführen einer Suche unmöglich. Sie sind unverzichtbar für die Kernfunktionalität der Seite.

Diese Skripte sollten im Head der Seite entweder mit dem async- oder dem defer-Attribut platziert werden.

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

Best Practices:

Halten Sie Skripte wie diese auf ein Minimum und kombinieren Sie diese Funktionalität nicht mit anderer, weniger kritischer Funktionalität.
Laden Sie diese Skripte frühzeitig mit async oder defer, abhängig von ihren Abhängigkeiten.
Verwenden Sie Real User Monitoring (RUM) Tools wie Coredash, um Engpässe in der Ausführung zu identifizieren und sicherzustellen, dass ihre Leistung mit den Benutzerbedürfnissen übereinstimmt.

3. Wichtige Skripte

Obwohl nicht direkt an die Benutzerfreundlichkeit der Seite gebunden, unterstützen wichtige Skripte Schlüsselfunktionen des Unternehmens. Analytics-Skripte liefern beispielsweise wesentliche Daten, müssen aber nicht vor wichtigeren visuellen Elementen geladen werden. Offensichtlich kann die Unterscheidung zwischen kritischen und wichtigen Skripten debattiert werden, also stellen Sie sicher, dass Sie mit allen Stakeholdern sprechen, bevor Sie diese Priorität festlegen!

Es gibt 3 Möglichkeiten, die Skriptpriorität für diese Arten von Skripten zu senken.

<html>
<head>
<!-- Methode 1: niedrige fetchpriority -->
<script fetchpriority="low" defer src="important.js"></script>

<!-- Methode 2: Injizieren nach DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- Methode 3: am Ende der Seite platzieren -->
<script defer src="important.js"></script>
</body>
</html>

1. Niedrige fetchpriority.

Das Setzen der fetchpriority senkt die relative Priorität des Skripts. Andere deferred oder asynced Skripte werden wahrscheinlich mit einer hohen Priorität in die Warteschlange gestellt, während die Skripte mit fetchpriority="low" mit einer niedrigen Priorität in die Warteschlange gestellt werden. Abhängig von Ihrer Seite (oder Ihrem Rendering-Pfad) könnte dies ausreichen, um andere Ressourcen wie Ihr Largest Contentful Paint Bild und wichtige Schriftarten zu priorisieren.

2: Injizieren nach DOMContentLoaded

Indem Sie das Skript nach dem DOMContentLoaded-Ereignis injizieren, stellen Sie sicher, dass das Skript direkt nach dem vollständigen Parsen des HTML heruntergeladen wird. 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 Seitenrendering entscheidend sind.

3: am Ende der Seite platzieren

Diese klassische Technik verzögert das Laden des Skripts, bis der Browser das gesamte Dokument verarbeitet hat, und erzielt im Wesentlichen das gleiche Ergebnis wie Technik. Der einzige Unterschied ist, dass Technik 2 Ihren Browser-Preload-Scanner überspringt, während diese Technik dies nicht tut. Der Preload-Scanner ist ein leichter, schneller Scanner, den Ihr Browser verwendet, um kritische Ressourcen schnell zu identifizieren und in die Warteschlange zu stellen. Den Preload-Scanner zu überspringen könnte eine gute Idee sein, wenn die Möglichkeit besteht, dass lazy geladene Bilder im Viewport sind, während die Verwendung des Preload-Scanners das Laden für dieses Skript beschleunigen wird.

4. Nice-to-Have Skripte

Diese Skripte verbessern die Benutzererfahrung, sind aber nicht erforderlich, damit die Seite funktioniert. Beispiele sind Chat-Widgets, Kundenfeedback-Popups oder optionale Animationen. Obwohl vorteilhaft, sollten sie die primäre Benutzererfahrung nicht beeinträchtigen.

Diese Skripte sind ein idealer Kandidat, um mit einem Muster namens 'lazy on load' geladen zu werden. Das bedeutet, auf das Load-Event der Seite zu warten und dann, während der Leerlaufzeit, das Skript zu injizieren. Das Warten auf das Load-Event stellt sicher, dass das Skript nicht um Bandbreite und CPU mit wichtigeren frühen Ressourcen konkurriert. Das Warten auf einen Leerlaufmoment stellt sicher, dass der Browser keine wichtigeren Aufgaben wie Benutzereingaben erledigt.

Hier ist ein funktionierendes Beispiel:

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

Best Practices:

Laden Sie diese Skripte lazy, nachdem die Seite geladen wurde, und warten Sie auf einen Leerlaufmoment.
Verstehen Sie, dass Skripte, die mit diesem Muster geladen werden, nicht garantiert schnell laden

5. Zukünftige Skripte

Zukünftige Skripte sind solche, die erst benötigt werden, wenn bestimmte Bedingungen erfüllt sind. Ein mehrstufiges Checkout-Skript wird beispielsweise erst relevant, nachdem ein Benutzer Artikel in seinen Warenkorb gelegt hat. Diese Skripte können oft bis viel später in der Reise des Benutzers warten.

Schauen Sie sich dieses Beispiel an. Es verwendet den Intersection Observer, um die für das Anmelde-Skript erforderliche JS-Logik nur dann zu laden, wenn das Formular im sichtbaren Viewport ist.

<!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">Registrieren</button>
    </form>
  </body>
</html>

Best Practices:

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

Make decisions with Data.

You cannot optimize what you do not measure. Install the CoreDash pixel and capture 100% of user experiences.

Create Free Account >>

100% Capture
Data Driven
Easy Install

Optimierung der JavaScript-Priorität für schnellere Ladezeiten

Core Web Vitals Optimierung der JavaScript-Priorität für schnellere Ladezeiten