Zum Hauptinhalt springen




So reagieren Sie schneller auf Benutzerinteraktionen.

Ich habe geklickt, aber nichts ist passiert! Warum kann ich nicht mit dieser Seite interagieren? 😢

First Contentful Paint (FCP) und Largest Contentful Paint (LCP) sind Metriken, die die Zeit messen, die benötigt wird, um Inhalte auf einer Seite visuell darzustellen (zu malen). Obwohl wichtig, erfassen Malzeiten nicht Reaktionsfähigkeit der Last: oder wie schnell eine Seite auf Benutzerinteraktion reagiert.

First Input Delay (FID) ist eine zentrale Web-Vitals-Metrik, die den ersten Eindruck eines Benutzers von der Interaktivität und Reaktionsfähigkeit einer Site erfasst. Misst die Zeit von der ersten Interaktion eines Benutzers mit einer Seite bis zur Reaktion des Browsers auf diese Interaktion. FID ist eine Feldmetrik und kann in einer Laborumgebung nicht simuliert werden. Eine echte Benutzerinteraktion benötigt, um die Antwortverzögerung zu messen.

Um die Vorhersage von FID im Labor zu erleichtern, empfehlen wir die Total Block Time (TBT). Sie messen unterschiedliche Dinge, aber Verbesserungen bei TBT entsprechen im Allgemeinen Verbesserungen bei FID.

Die Hauptursache für eine schlechte FID ist schwere Javascript-Ausführung. Durch die Optimierung der Art und Weise, wie JavaScript auf Ihrer Webseite geparst, kompiliert und ausgeführt wird, wird die FID direkt reduziert.

Starke JavaScript-Ausführung

Der Browser kann auf die meisten Benutzereingaben nicht reagieren, während JavaScript im Haupt-Thread ausgeführt wird. Mit anderen Worten, der Browser kann nicht auf Benutzerinteraktionen reagieren, während der Hauptthread beschäftigt ist. Um dies zu verstärken:

Brechen Sie lange Aufgaben auf

Wenn Sie bereits versucht haben, die Menge an JavaScript zu reduzieren, die auf einer einzelnen Seite geladen wird, kann es hilfreich sein, Ihren langlaufenden Code in aufzuteilen kleinere asynchrone Aufgaben.

Lange Aufgaben sind Perioden der JavaScript-Ausführung, in denen Benutzer möglicherweise feststellen, dass ihre Benutzeroberfläche nicht reagiert. Jeder Codeabschnitt, der den Hauptthread für 50 ms oder länger blockiert, kann als lange Aufgabe bezeichnet werden. Lange Aufgaben sind ein Zeichen für potenziellen JavaScript-Overkill (Laden und Ausführen von mehr, als ein Benutzer derzeit benötigt).
Das Aufteilen langer Aufgaben kann die Eingabeverzögerung auf Ihrer Website verringern.

Long-Task-6693785
Chrome DevTools lange Aufgaben visualisieren auf dem Leistungs-Dashboard

FID sollte sich merklich verbessern, wenn Sie Best Practices wie Code-Splitting und Long-Task-Splitting übernehmen. Obwohl TBT keine Feldmetrik ist, ist es nützlich, um den Fortschritt in Richtung einer endgültigen Verbesserung sowohl der Zeit bis zur Interaktion (TTI) als auch der FID zu überprüfen.

Optimieren Sie Ihre Seite so, dass sie für die Interaktion bereit ist

Es gibt eine Reihe häufiger Ursachen für niedrige FID- und TBT-Werte in Webanwendungen, die stark auf JavaScript basieren:

Das Ausführen eines Quellenskripts kann die Vorbereitung der Interaktion verzögern

  • Übermäßige JavaScript-Größe, hohe Ausführungszeiten und ineffiziente Fragmentierung können die Reaktionsgeschwindigkeit einer Seite auf Benutzereingaben verlangsamen und sich auf FIDs, TBTs und TTIs auswirken. Das fortschreitende Laden von Code und Features kann dazu beitragen, diese Arbeit zu verbreiten und die Interaktionsbereitschaft zu verbessern.
  • Serverseitig gerenderte Anwendungen können aussehen, als würden sie schnell Pixel auf den Bildschirm malen, aber achten Sie darauf, dass Benutzerinteraktionen durch große Skriptausführungen blockiert werden (z. B. Rehydrierung, um Ereignis-Listener anzuschließen). Dies kann mehrere tausend Millisekunden dauern, manchmal sogar Sekunden, wenn pfadbasierte Codeteilung verwendet wird. Erwägen Sie, mehr serverseitige Logik zu ändern oder mehr Inhalt zur Buildzeit statisch auszugeben.

Nachfolgend finden Sie die TBT-Ergebnisse vor und nach dem vollständigen Laden Ihrer eigenen Skripts für eine Anwendung. Indem das kostspielige Laden (und Ausführen) von Skripts für eine nicht wesentliche Komponente aus dem kritischen Pfad verschoben wurde, konnten Benutzer viel früher mit der Seite interagieren.

tbt-before-after-first-party-4830319

Die Suche nach Daten kann viele Aspekte der Vorbereitung auf die Interaktion beeinflussen

  • Das Erwarten einer Kaskade kaskadierender Abrufe (z. B. JavaScript- und Datenabrufe für Komponenten) kann sich auf die Interaktionslatenz auswirken. Versuchen Sie, die Abhängigkeit von kaskadierenden Datenabrufen zu minimieren.
  • Große Online-Datenspeicher können die HTML-Parsing-Zeit verlängern und sowohl die Paint- als auch die Engagement-Metriken beeinflussen. Versuchen Sie, die Datenmenge zu minimieren, die später auf der Client-Seite verarbeitet werden muss.

Das Ausführen eines Skripts eines Drittanbieters kann auch die Interaktionslatenz verzögern

  • Viele Websites enthalten Tags und Analysen von Drittanbietern, die das Netzwerk auslasten und dazu führen können, dass der Haupt-Thread regelmäßig nicht mehr reagiert, was sich auf die Interaktionslatenz auswirkt. Untersuchen Sie das On-Demand-Laden von Drittanbieter-Code (z. B. werden diese Anzeigen in der unteren Hälfte der Seite möglicherweise erst geladen, wenn sie näher an den Darstellungsbereich gezoomt werden).
  • In einigen Fällen können Skripte von Drittanbietern Ihren eigenen in Bezug auf Priorität und Bandbreite im Hauptthread voraus sein, was die Geschwindigkeit, mit der eine Seite für die Interaktion bereit ist, weiter verzögert. Versuchen Sie, zuerst das zu laden, was Ihrer Meinung nach den größten Nutzen für die Benutzer bietet.

Verwenden Sie einen Web-Mitarbeiter

Ein blockierter Haupt-Thread ist eine der Hauptursachen für Eingangsverzögerungen. Web-Mitarbeiter machen es möglich, JavaScript in einem Hintergrund-Thread auszuführen. Das Verschieben von Nicht-UI-Operationen in einen separaten Arbeitsthread kann die Blockierungszeit des Hauptthreads verkürzen und somit die FID verbessern.

Erwägen Sie die Verwendung der folgenden Bibliotheken, um die Verwendung von Webmitarbeitern auf Ihrer Website zu vereinfachen:

  • Comlink: Eine Hilfsbibliothek, die abstrahiert
    POST-Meldung und macht es einfach zu bedienen
  • Workway: Ein Allzweck-Web-Mitarbeiter-Exporteur
  • Arbeiten: Verschieben Sie ein Modul zu einem Webmitarbeiter

Verringern Sie die JavaScript-Ausführungszeit

Die Beschränkung der JavaScript-Menge auf Ihrer Seite verringert die Zeit, die der Browser zum Ausführen von JavaScript-Code benötigt. Dadurch kann der Browser schneller auf Benutzerinteraktionen reagieren.

So verringern Sie die auf Ihrer Seite ausgeführte JavaScript-Menge:

  • Verschieben Sie nicht verwendetes JavaScript
  • Minimieren Sie nicht verwendete Polyfills

Verschieben Sie nicht verwendetes JavaScript

Standardmäßig blockiert alles JavaScript das Rendern. Wenn der Browser auf ein Skript-Tag stößt, das auf eine externe JavaScript-Datei verweist, muss er seine Aktion anhalten und dieses JavaScript herunterladen, analysieren, abrufen und ausführen. Daher sollten Sie nur den Code laden, der für die Seite erforderlich ist, oder auf Benutzereingaben reagieren.

das Abdeckung Auf der Registerkarte Chrome DevTools können Sie feststellen, wie viel JavaScript auf Ihrer Webseite nicht verwendet wird.

Coverage-Panel-js-6236715

So verringern Sie ungenutztes JavaScript:

  • Teilen Sie Ihren Paketcode in mehrere Teile
  • Verzögern Sie die Verwendung von unkritischem JavaScript, einschließlich Skripts von Drittanbietern asynchron oder verschieben

Codeteilung Es ist das Konzept, ein einzelnes großes JavaScript-Bundle in kleinere Teile zu zerlegen, die bedingt geladen werden können (auch bekannt als Lazy Loading).
Die meisten neueren Browser unterstützen die dynamische Importsyntax, die das Erreichen von Modulen auf Anfrage ermöglicht:

importieren ( 'module.js' )
. dann ( ( Modul ) => {
} ) ;

Der dynamische JavaScript-Import bei bestimmten Benutzerinteraktionen (z. B. Ändern einer Route oder Anzeigen eines Modals) stellt sicher, dass Code, der nicht für das anfängliche Laden der Seite verwendet wird, nur bei Bedarf abgerufen wird.

Abgesehen von der allgemeinen Browserunterstützung kann die dynamische Importsyntax auf vielen verschiedenen Build-Systemen verwendet werden.

Verwenden Sie neben der Code-Aufteilung immer asynchron oder aufschieben für Skripte, die für Inhalte der oberen Hälfte oder des kritischen Pfads nicht erforderlich sind.

< script defer src = "" >  Skript >
< script async src = "" >
Skript >

Sofern es keinen bestimmten Grund gibt, dies nicht zu tun, müssen alle Skripte von Drittanbietern mit geladen werden verschieben
oder asynchron Standard.

Minimieren Sie nicht verwendete Polyfills

Wenn Sie Ihren Code mit moderner JavaScript-Syntax erstellen und auf moderne Browser-APIs verweisen, müssen Sie ihn transpilieren und Polyfills einschließen, damit er in älteren Browsern funktioniert.

Eines der Hauptleistungsprobleme beim Einfügen von Polyfills und transpiliertem Code auf Ihrer Website besteht darin, dass neuere Browser ihn nicht herunterladen müssen, wenn sie ihn nicht benötigen. Um die Größe des JavaScripts Ihrer Anwendung zu verringern, minimieren Sie ungenutzte Polyfills so weit wie möglich und beschränken Sie ihre Verwendung auf Umgebungen, in denen sie benötigt werden.

So nutzen Sie Polyfill auf Ihrer Website optimal:

  • wenn du benutzt Babel als Transpiler verwenden
    @ babel / preset-env um nur die Polyfills einzuschließen, die von den Browsern benötigt werden, auf die Sie abzielen möchten. Aktivieren Sie für Babel 7.9 die Option
    Fehlerbehebung Option, um unnötige Polyfills weiter zu reduzieren

  • Verwenden Sie das Modul- / Nichtmodulmuster, um zwei separate Pakete zu liefern (@ babel / preset-env unterstützt dies weiter über target.esmodules)

    < script type = " module " src = " modern.js " >  Skript >
    <Script nomodule src = "legacy.js" defer>
    Skript >

    Viele der neueren ECMAScript-Funktionen, die mit Babel kompiliert wurden, sind bereits mit Umgebungen kompatibel, die JavaScript-Module unterstützen. Auf diese Weise vereinfachen Sie den Prozess, sicherzustellen, dass der transpilierte Code nur für die Browser verwendet wird, die ihn wirklich benötigen.

Es stehen mehrere Funktionen zum Messen und Debuggen von FID zur Verfügung:

Wir danken Philip Walton, Kayce Basques, Ilya Grigorik und Annie Sullivan für ihre Bewertungen.

R Marketing Digital