First Input Delay (FID)

Philip Walton

Browser Support

  • Chrome: 76.
  • Edge: 79.
  • Firefox: 89.
  • Safari: 26.2.

Source

Wir alle wissen, wie wichtig es ist, einen guten ersten Eindruck zu machen. Das ist wichtig, wenn Sie neue Leute kennenlernen, und auch, wenn Sie Webanwendungen entwickeln.

Im Web kann ein guter erster Eindruck darüber entscheiden, ob jemand ein treuer Nutzer wird oder die Website verlässt und nie wieder zurückkehrt. Die Frage ist, was einen guten Eindruck ausmacht und wie Sie messen können, welchen Eindruck Sie bei Ihren Nutzern wahrscheinlich hinterlassen.

Im Web können erste Eindrücke viele verschiedene Formen annehmen. Wir haben erste Eindrücke vom Design und der visuellen Attraktivität einer Website sowie erste Eindrücke von ihrer Geschwindigkeit und Reaktionsfähigkeit.

Es ist zwar schwierig, mit Web-APIs zu messen, wie gut Nutzern das Design einer Website gefällt, aber die Geschwindigkeit und Reaktionsfähigkeit lassen sich sehr wohl messen.

Der erste Eindruck, den Nutzer von der Ladegeschwindigkeit Ihrer Website haben, lässt sich mit First Contentful Paint (FCP) messen. Wie schnell Ihre Website Pixel auf dem Bildschirm darstellen kann, ist jedoch nur ein Teil der Geschichte. Ebenso wichtig ist, wie schnell Ihre Website reagiert, wenn Nutzer mit diesen Pixeln interagieren.

Mit dem Messwert „First Input Delay“ (FID) lässt sich der erste Eindruck der Nutzer von der Interaktivität und Reaktionsfähigkeit Ihrer Website messen.

Was ist FID?

Der FID-Messwert gibt an, wie lange es ab dem Zeitpunkt, zu dem ein Nutzer das erste Mal mit einer Seite interagiert (z. B. auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes JavaScript-Steuerelement verwendet), dauert, bis der Browser mit der Verarbeitung von Event-Handlern als Reaktion auf diese Interaktion beginnen kann.

Was ist ein guter FID-Wert?

Für eine gute Nutzerfreundlichkeit sollten Websites eine First Input Delay von 100 Millisekunden oder weniger anstreben. Wenn ihr dafür sorgen wollt, dass ihr für die meisten eurer Nutzerinnen und Nutzer dieses Ziel erreicht, genügt es, das 75. Perzentil aller Seitenaufrufe, aufgeschlüsselt nach Mobilgeräten und Desktop-Geräten, zu messen.

Gute FID-Werte liegen bei 2,5 Sekunden oder weniger, schlechte Werte bei mehr als 4,0 Sekunden.Werte dazwischen müssen verbessert werden.

FID im Detail

Als Entwickler, die Code schreiben, der auf Ereignisse reagiert, gehen wir oft davon aus, dass unser Code sofort ausgeführt wird, sobald das Ereignis eintritt. Als Nutzer haben wir aber alle schon oft das Gegenteil erlebt: Wir haben eine Webseite auf unserem Smartphone geladen, versucht, mit ihr zu interagieren, und waren dann frustriert, als nichts passiert ist.

Im Allgemeinen tritt eine Eingabeverzögerung (auch als Eingabelatenz bezeichnet) auf, weil der Hauptthread des Browsers mit anderen Aufgaben beschäftigt ist und daher (noch) nicht auf den Nutzer reagieren kann. Ein häufiger Grund dafür ist, dass der Browser mit dem Parsen und Ausführen einer großen JavaScript-Datei beschäftigt ist, die von Ihrer App geladen wird. Währenddessen kann er keine Event-Listener ausführen, da das geladene JavaScript möglicherweise andere Anweisungen enthält.

Sehen Sie sich die folgende Zeitachse für den Seitenaufbau einer typischen Webseite an:

Beispiel für einen Seitenaufbau-Trace

Die obige Visualisierung zeigt eine Seite, die einige Netzwerkanfragen für Ressourcen (wahrscheinlich CSS- und JS-Dateien) stellt. Nachdem diese Ressourcen heruntergeladen wurden, werden sie im Hauptthread verarbeitet.

Dies führt zu Phasen, in denen der Hauptthread kurzzeitig ausgelastet ist. Das wird durch die beigefarbenen Aufgaben-Blöcke angezeigt.

Lange Verzögerungen bei der ersten Eingabe treten in der Regel zwischen First Contentful Paint (FCP) und Time to Interactive (TTI) auf, da die Seite einige ihrer Inhalte gerendert hat, aber noch nicht zuverlässig interaktiv ist. Zur Veranschaulichung, wie das passieren kann, wurden FCP und TTI in die Zeitachse eingefügt:

Beispiel für einen Seitenaufbau-Trace mit FCP und TTI

Sie haben vielleicht bemerkt, dass zwischen FCP und TTI eine beträchtliche Zeitspanne liegt (einschließlich drei lang andauernder Aufgaben). Wenn ein Nutzer in dieser Zeit versucht, mit der Seite zu interagieren (z. B. auf einen Link klickt), kommt es zu einer Verzögerung zwischen dem Zeitpunkt, zu dem der Klick empfangen wird, und dem Zeitpunkt, zu dem der Haupt-Thread reagieren kann.

Stellen Sie sich vor, was passieren würde, wenn ein Nutzer versuchen würde, mit der Seite zu interagieren, wenn die längste Aufgabe gerade erst begonnen hat:

Beispiel für einen Seitenaufbau-Trace mit FCP, TTI und FID

Da die Eingabe erfolgt, während der Browser gerade eine Aufgabe ausführt, muss er warten, bis die Aufgabe abgeschlossen ist, bevor er auf die Eingabe reagieren kann. Die Wartezeit ist der FID-Wert für diesen Nutzer auf dieser Seite.

Was passiert, wenn eine Interaktion keinen Event-Listener hat?

FID misst die Zeitspanne zwischen dem Empfang eines Eingabeereignisses und dem nächsten Leerlauf des Haupt-Threads. Das bedeutet, dass FID auch dann gemessen wird, wenn kein Event-Listener registriert wurde. Das liegt daran, dass für viele Nutzerinteraktionen kein Event-Listener erforderlich ist, aber der Hauptthread im Leerlauf sein muss, damit sie ausgeführt werden können.

Beispielsweise müssen alle folgenden HTML-Elemente warten, bis laufende Aufgaben im Hauptthread abgeschlossen sind, bevor sie auf Nutzerinteraktionen reagieren:

  • Textfelder, Kästchen und Optionsfelder (<input>, <textarea>)
  • Drop-down-Menüs auswählen (<select>)
  • Links (<a>)

Warum wird nur die erste Eingabe berücksichtigt?

Eine Verzögerung bei der Reaktion auf eine Eingabe kann zu einer schlechten Nutzererfahrung führen. Wir empfehlen jedoch, aus folgenden Gründen in erster Linie die Verzögerung bei der ersten Eingabe zu messen:

  • Die erste Eingabeverzögerung ist der erste Eindruck, den Nutzer von der Reaktionsfähigkeit Ihrer Website erhalten. Erste Eindrücke sind entscheidend für die Gesamtbewertung der Qualität und Zuverlässigkeit einer Website.
  • Die größten Interaktivitätsprobleme, die wir heute im Web sehen, treten beim Laden von Seiten auf. Daher sind wir der Meinung, dass sich die Interaktivität im Web insgesamt am besten verbessern lässt, wenn wir uns zunächst auf die erste Nutzerinteraktion mit einer Website konzentrieren.
  • Die empfohlenen Lösungen für die Behebung hoher First Input Delays (z. B. Code-Splitting, weniger JavaScript im Voraus laden) sind nicht unbedingt dieselben wie für die Behebung langsamer Input Delays nach dem Seitenaufbau. Durch die Trennung dieser Messwerte können wir Webentwicklern genauere Leistungsrichtlinien zur Verfügung stellen.

Was zählt als erste Eingabe?

FID ist ein Messwert, der die Reaktionsfähigkeit einer Seite während des Ladens misst. Daher werden nur Eingabeereignisse aus diskreten Aktionen wie Klicks, Tippen und Tastendrücken berücksichtigt.

Andere Interaktionen wie Scrollen und Zoomen sind kontinuierliche Aktionen und haben völlig andere Leistungsanforderungen. Außerdem können Browser ihre Latenz oft verbergen, indem sie sie in einem separaten Thread ausführen.

Anders ausgedrückt: FID konzentriert sich auf die Reaktionsfähigkeit (R) im RAIL-Leistungsmodell, während sich Scrollen und Zoomen eher auf die Animation (A) beziehen. Ihre Leistungsmerkmale sollten separat bewertet werden.

Was passiert, wenn ein Nutzer nie mit Ihrer Website interagiert?

Nicht alle Nutzer interagieren bei jedem Besuch mit Ihrer Website. Außerdem sind nicht alle Interaktionen für FID relevant (wie im vorherigen Abschnitt erwähnt). Außerdem finden die ersten Interaktionen einiger Nutzer zu ungünstigen Zeiten statt (wenn der Hauptthread über einen längeren Zeitraum ausgelastet ist), während die ersten Interaktionen anderer Nutzer zu günstigen Zeiten stattfinden (wenn der Hauptthread vollständig im Leerlauf ist).

Das bedeutet, dass einige Nutzer keine FID-Werte, einige niedrige FID-Werte und einige wahrscheinlich hohe FID-Werte haben.

Die Art und Weise, wie Sie FID erfassen, Berichte dazu erstellen und analysieren, unterscheidet sich wahrscheinlich erheblich von anderen Messwerten, die Sie gewohnt sind. Im nächsten Abschnitt wird erläutert, wie Sie am besten vorgehen.

Warum wird nur die Eingabeverzögerung berücksichtigt?

Wie oben erwähnt, wird mit FID nur die „Verzögerung“ bei der Ereignisverarbeitung gemessen. Es wird weder die gesamte Dauer der Ereignisverarbeitung noch die Zeit gemessen, die der Browser benötigt, um die Benutzeroberfläche nach dem Ausführen von Event-Handlern zu aktualisieren.

Auch wenn diese Zeit für den Nutzer wichtig ist und die Nutzerfreundlichkeit beeinträchtigt, wird sie nicht in diesen Messwert einbezogen. Andernfalls könnten Entwickler dazu verleitet werden, Workarounds hinzuzufügen, die die Nutzerfreundlichkeit tatsächlich verschlechtern. Sie könnten ihre Event-Handler-Logik in einen asynchronen Callback (über setTimeout() oder requestAnimationFrame()) einbetten, um sie vom mit dem Ereignis verknüpften Task zu trennen. Das Ergebnis wäre eine Verbesserung des Messwertwerts, aber eine langsamere Antwort aus Nutzersicht.

FID misst jedoch nur den „Verzögerungs“-Teil der Ereignislatenz. Entwickler, die mehr vom Ereignislebenszyklus erfassen möchten, können dies mit der Event Timing API tun. Weitere Informationen

FID messen

FID ist ein Messwert, der nur in der Praxis gemessen werden kann, da ein echter Nutzer mit Ihrer Seite interagieren muss. Sie können FID mit den folgenden Tools messen.

Feldtools

FID in JavaScript messen

Um FID in JavaScript zu messen, können Sie die Event Timing API verwenden. Das folgende Beispiel zeigt, wie Sie ein PerformanceObserver erstellen, das auf first-input-Einträge wartet und sie in der Konsole protokolliert:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

Im obigen Beispiel wird der Verzögerungswert des Eintrags first-input anhand der Differenz zwischen den Zeitstempeln startTime und processingStart des Eintrags gemessen. In den meisten Fällen ist das der FID-Wert. Allerdings sind nicht alle first-input-Einträge für die FID-Messung gültig.

Im folgenden Abschnitt werden die Unterschiede zwischen den API-Berichten und der Berechnung der Messwerte aufgeführt.

Unterschiede zwischen dem Messwert und der API

  • Die API sendet first-input-Einträge für Seiten, die auf einem Hintergrundtab geladen werden. Diese Seiten sollten bei der Berechnung von FID jedoch ignoriert werden.
  • Die API sendet auch first-input-Einträge, wenn die Seite vor der ersten Eingabe in den Hintergrund verschoben wurde. Diese Seiten sollten jedoch auch bei der Berechnung von FID ignoriert werden, da Eingaben nur berücksichtigt werden, wenn die Seite die ganze Zeit im Vordergrund war.
  • Die API meldet keine first-input-Einträge, wenn die Seite aus dem Back-Forward-Cache wiederhergestellt wird. FID sollte in diesen Fällen jedoch gemessen werden, da Nutzer sie als separate Seitenaufrufe wahrnehmen.
  • Die API meldet keine Eingaben, die in iFrames erfolgen, der Messwert jedoch schon, da sie Teil der Nutzerfreundlichkeit der Seite sind. Dies kann zu einem Unterschied zwischen CrUX und RUM führen. Um den FID richtig zu messen, sollten Sie sie berücksichtigen. Untergeordnete Frames können die API verwenden, um ihre first-input-Einträge zur Aggregation an den übergeordneten Frame zu melden.

FID-Daten analysieren und Berichte erstellen

Aufgrund der erwarteten Varianz bei FID-Werten ist es wichtig, dass Sie bei der Berichterstellung zu FID die Verteilung der Werte betrachten und sich auf die höheren Perzentile konzentrieren.

Während für alle Core Web Vitals-Grenzwerte das 75. Perzentil verwendet wird, empfehlen wir für FID weiterhin dringend, das 95. bis 99. Perzentil zu betrachten, da diese Werte den besonders schlechten ersten Erfahrungen entsprechen, die Nutzer mit Ihrer Website machen. Außerdem sehen Sie, in welchen Bereichen die größten Verbesserungen erforderlich sind.

Das gilt auch dann, wenn Sie Ihre Berichte nach Geräteklasse oder ‑typ segmentieren. Wenn Sie beispielsweise separate Berichte für Computer und Mobilgeräte erstellen, sollte der FID-Wert, der Sie auf Computern am meisten interessiert, das 95. bis 99. Perzentil der Computernutzer sein. Der FID-Wert, der Sie auf Mobilgeräten am meisten interessiert, sollte das 95. bis 99. Perzentil der Mobilgerätenutzer sein.

FID verbessern

Hier finden Sie einen vollständigen Leitfaden zur Optimierung von FID.

Änderungsprotokoll

Gelegentlich werden Fehler in den APIs entdeckt, die zum Messen von Messwerten verwendet werden, und manchmal auch in den Definitionen der Messwerte selbst. Daher müssen manchmal Änderungen vorgenommen werden, die sich in Ihren internen Berichten und Dashboards als Verbesserungen oder Regressionen bemerkbar machen können.

Damit Sie diese Änderungen besser nachvollziehen können, werden alle Änderungen an der Implementierung oder Definition dieser Messwerte in diesem Changelog aufgeführt.

Wenn Sie Feedback zu diesen Messwerten haben, können Sie es in der Google-Gruppe „web-vitals-feedback“ geben.