Wir alle wissen, wie wichtig es ist, einen guten ersten Eindruck zu hinterlassen. Es ist wichtig, wenn Sie neue Leute treffen, und auch, wenn Sie Erfahrungen im Web erstellen.
Im Web kann ein guter erster Eindruck ausschlaggebend dafür sein, ob ein Nutzer zu einem treuen Nutzer wird oder die Website verlässt und nie wiederkehrt. Die Frage ist: Was macht einen guten Eindruck aus und wie messen Sie, welchen Eindruck Sie bei Ihren Nutzern wahrscheinlich hinterlassen?
Der erste Eindruck im Web kann viele verschiedene Formen annehmen. Der erste Eindruck zählt zum Beispiel vom Design und von der visuellen Darstellung einer Website sowie von der Geschwindigkeit und Reaktionsfähigkeit einer Website.
Es ist zwar schwierig, mit Web-APIs zu messen, wie gut Nutzer das Design einer Website finden, aber die Geschwindigkeit und Reaktionsfähigkeit zu messen, ist kein Problem.
Der erste Eindruck, den Nutzer von der Geschwindigkeit des Ladens Ihrer Website haben, kann mit dem Messwert First Contentful Paint (FCP) gemessen werden. Aber wie schnell Ihre Website Pixel auf den Bildschirm zeichnen kann, ist nur ein Teil der Geschichte. Ebenso wichtig ist, wie responsiv Ihre Website ist, wenn Nutzer versuchen, mit diesen Pixeln zu 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?
FID misst die Zeit von der ersten Interaktion eines Nutzers mit einer Seite (d. h. wenn er auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes JavaScript-Steuerelement verwendet) bis zu der Zeit, zu der der Browser tatsächlich 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 Latenz bei der ersten Eingabe von 100 Millisekunden oder weniger anstreben. Damit Sie dieses Ziel für die meisten Ihrer Nutzer erreichen, empfiehlt es sich, das 75. Perzentil der Seitenladevorgänge, aufgeteilt nach Mobil- und Desktopgeräten, zu messen.
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 jedoch 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 gerade mit einem anderen Vorgang beschäftigt ist, sodass er dem Nutzer (noch) nicht antworten kann. Dies kann häufig der Fall sein, weil der Browser gerade eine große JavaScript-Datei parst und ausführt, die von Ihrer Anwendung geladen wurde. Währenddessen kann er keine Event-Listener ausführen, da der geladene JavaScript-Code ihn möglicherweise anweist, eine andere Aktion auszuführen.
Betrachten Sie die folgende Zeitleiste für einen typischen Webseitenaufbau:
Die obige Visualisierung zeigt eine Seite, auf der mehrere Netzwerkanfragen für Ressourcen (höchstwahrscheinlich CSS- und JS-Dateien) gesendet werden. Nachdem diese Ressourcen heruntergeladen wurden, werden sie im Hauptthread verarbeitet.
Dies führt zu Zeiträumen, in denen der Hauptthread kurzzeitig ausgelastet ist. Dies wird durch die beigefarbenen Aufgabenblöcke angezeigt.
Lange First Input Delays treten in der Regel zwischen First Contentful Paint (FCP) und Time to Interactive (TTI) auf, weil die Seite zwar einige Inhalte gerendert hat, aber noch nicht zuverlässig interaktiv ist. Zur Veranschaulichung wurden der Zeitachse FCP und TTI hinzugefügt:
Möglicherweise ist Ihnen aufgefallen, dass zwischen FCP und TTI eine relativ lange Zeit vergeht (einschließlich drei langer Aufgaben). Wenn ein Nutzer während dieser Zeit versucht, mit der Seite zu interagieren (z. B. durch Klicken auf einen Link), tritt eine Verzögerung zwischen dem Empfang des Klicks und der Reaktion des Hauptthreads auf.
Überlegen Sie, was passieren würde, wenn ein Nutzer versucht, am Anfang der längsten Aufgabe mit der Seite zu interagieren:
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 ist, wenn eine Interaktion keinen Event-Listener hat?
Der FID misst das Delta zwischen dem Empfang eines Eingabeereignisses und dem nächsten Inaktivitätszeitraum des Hauptthreads. Das bedeutet, dass FID auch dann gemessen wird, wenn kein Ereignis-Listener registriert ist. Das liegt daran, dass für viele Nutzerinteraktionen kein Event-Listener erforderlich ist, der Hauptthread aber zur Ausführung inaktiv sein muss.
Beispielsweise müssen alle folgenden HTML-Elemente warten, bis laufende Aufgaben im Hauptthread abgeschlossen sind, bevor auf Nutzerinteraktionen geantwortet wird:
- Textfelder, Kästchen und Optionsfelder (
<input>,<textarea>) - Drop-down-Menüs auswählen (
<select>) - Links (
<a>)
Warum nur die erste Eingabe berücksichtigen?
Eine Verzögerung bei jeder Eingabe kann zu einer schlechten Nutzererfahrung führen. Wir empfehlen jedoch aus mehreren Gründen, vor allem die Verzögerung bei der ersten Eingabe zu messen:
- Die First Input Delay ist der erste Eindruck des Nutzers von der Reaktionsfähigkeit Ihrer Website. Der erste Eindruck ist entscheidend für den Gesamteindruck von der Qualität und Zuverlässigkeit einer Website.
- Die größten Probleme mit Interaktivität im Web treten beim Laden der Seite auf. Wir sind daher der Meinung, dass sich die Verbesserung der ersten Nutzerinteraktion auf der Website am stärksten auf die allgemeine Interaktivität des Web auswirken wird.
- Die empfohlenen Lösungen zum Beheben hoher Verzögerungen bei der ersten Eingabe (Codeaufteilung, weniger JavaScript im Voraus usw.) sind nicht unbedingt dieselben Lösungen zum Beheben langsamer Eingabeverzögerungen nach dem Seitenaufbau. Durch die Aufteilung dieser Messwerte können wir Webentwicklern spezifischere Leistungsrichtlinien zur Verfügung stellen.
Was zählt als erste Eingabe?
FID ist ein Messwert, mit dem die Reaktionsfähigkeit einer Seite beim Laden gemessen wird. Daher konzentriert er sich nur auf Eingabeereignisse aus diskreten Aktionen wie Klicks, Tippen und Drücken von Tasten.
Andere Interaktionen wie Scrollen und Zoomen sind kontinuierliche Aktionen und haben völlig unterschiedliche Leistungseinschränkungen. Außerdem können Browser ihre Latenz häufig ausblenden, indem sie sie in einem separaten Thread ausführen.
Anders ausgedrückt: FID konzentriert sich auf die Reaktionsfähigkeit (Responsivität) im RAIL-Leistungsmodell, während Scrollen und Zoomen eher mit A (Animation) in Zusammenhang steht und ihre Leistungsqualitäten separat bewertet werden sollten.
Was passiert, wenn ein Nutzer nie mit Ihrer Website interagiert?
Nicht alle Nutzer interagieren bei jedem Besuch mit Ihrer Website. Und nicht alle Interaktionen sind 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 belegt ist) und die ersten Interaktionen anderer Nutzer zu günstigen Zeiten (wenn der Hauptthread völlig inaktiv ist).
Das bedeutet, dass einige Nutzer keine FID-Werte, andere niedrige FID-Werte und einige Nutzer wahrscheinlich hohe FID-Werte haben.
Die Erfassung, Berichterstellung und Analyse des FID unterscheidet sich wahrscheinlich erheblich von anderen Messwerten, die Sie vielleicht gewohnt sind. Im nächsten Abschnitt wird erläutert, wie Sie das am besten tun.
Warum wird nur die Eingabeverzögerung berücksichtigt?
Wie bereits erwähnt, wird mit FID nur die „Verzögerung“ bei der Ereignisverarbeitung gemessen. Er misst weder die Gesamtdauer der Ereignisverarbeitung selbst, noch die Zeit, die der Browser benötigt, um die UI nach der Ausführung von Event-Handlern zu aktualisieren.
Auch wenn diese Zeit für den Nutzer wichtig ist und sich auf die Nutzerfreundlichkeit auswirkt, wird sie in diesem Messwert nicht berücksichtigt. Andernfalls könnten Entwickler dazu verleitet werden, Umgehungslösungen zu implementieren, die die Nutzerfreundlichkeit tatsächlich verschlechtern. Sie könnten beispielsweise die Logik des Ereignishandlers in einen asynchronen Rückruf (über setTimeout() oder requestAnimationFrame()) einbetten, um sie von der mit dem Ereignis verknüpften Aufgabe zu trennen. Das würde zu einer Verbesserung des Messwerts führen, aber zu einer langsameren Antwort, wie sie vom Nutzer wahrgenommen wird.
Der 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 finden Sie im Leitfaden zu benutzerdefinierten Messwerten.
FID messen
Der FID ist ein Messwert, der nur in der Praxis gemessen werden kann, da ein echter Nutzer mit Ihrer Seite interagieren muss. Sie können den FID mit den folgenden Tools messen.
Tools für die Arbeit im Außendienst
- Chrome User Experience Report
- PageSpeed Insights
- Search Console (Core Web Vitals-Bericht)
web-vitals-JavaScript-Bibliothek
FID in JavaScript messen
Sie können die Event Timing API verwenden, um FID in JavaScript zu messen. Im folgenden Beispiel wird gezeigt, wie ein PerformanceObserver erstellt wird, der 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 first-input-Eintrags anhand des Deltas zwischen den Zeitstempeln startTime und processingStart des Eintrags gemessen. In den meisten Fällen ist dies der FID-Wert. Allerdings sind nicht alle first-input-Einträge zum Messen des FID-Werts gültig.
Im folgenden Abschnitt werden die Unterschiede zwischen den API-Berichten und der Berechnung des Messwerts aufgeführt.
Unterschiede zwischen dem Messwert und der API
- Die API sendet
first-input-Einträge für Seiten, die in einem Hintergrundtab geladen werden. Diese Seiten sollten bei der Berechnung der FID jedoch ignoriert werden. - Die API sendet auch
first-input-Einträge, wenn die Seite vor der ersten Eingabe im Hintergrund war. Diese Seiten sollten jedoch auch bei der Berechnung des FID ignoriert werden. Eingaben werden nur berücksichtigt, 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 die Nutzer sie als separate Seitenbesuche erleben. - Die API erfasst keine Eingaben in Iframes, der Messwert hingegen schon, da sie Teil der Nutzerfreundlichkeit der Seite sind. Dies kann sich als Unterschied zwischen CrUX und RUM anzeigen lassen.
Um den FID korrekt zu messen, sollten Sie diese berücksichtigen. Subframes können die API verwenden, um ihre
first-input-Einträge zur Aggregation an den übergeordneten Frame zu melden.
FID-Daten analysieren und Berichte dazu erstellen
Aufgrund der erwarteten Abweichungen bei den FID-Werten ist es wichtig, dass Sie sich bei Berichten zu FID auf die Werteverteilung konzentrieren und sich auf die höheren Perzentile konzentrieren.
Als Perzentil für alle Core Web Vitals-Grenzwerte wird der 75. Wert verwendet. Wir empfehlen jedoch dringend, sich insbesondere bei der FID die Werte für das 95. bis 99. Perzentil anzusehen, da diese den besonders schlechten ersten Eindruck der Nutzer von Ihrer Website widerspiegeln. So erfahren Sie, in welchen Bereichen Sie am stärksten verbesserungswürdig sind.
Das gilt auch, wenn Sie Ihre Berichte nach Gerätekategorie oder ‑typ segmentieren. Wenn Sie beispielsweise separate Berichte für Computer und Mobilgeräte erstellen, sollte der für Sie wichtigste FID-Wert auf Computern der 95. bis 99. Perzentilwert für Computernutzer und auf Mobilgeräten der 95. bis 99. Perzentilwert für Mobilgerätenutzer sein.
FID verbessern
Es steht ein vollständiger Leitfaden zur Optimierung von FID mit Techniken zur Verbesserung dieses Messwerts zur Verfügung.
Änderungsprotokoll
Gelegentlich werden Fehler in den APIs, mit denen Messwerte gemessen werden, und manchmal in den Definitionen der Messwerte selbst entdeckt. Daher müssen manchmal Änderungen vorgenommen werden, die sich als Verbesserungen oder Regressionen in Ihren internen Berichten und Dashboards zeigen können.
Alle Änderungen an der Implementierung oder der Definition dieser Messwerte werden in diesem Änderungsprotokoll veröffentlicht, um Ihnen die Verwaltung zu erleichtern.
Wenn Sie Feedback zu diesen Messwerten haben, können Sie es in der Google-Gruppe „web-vitals-feedback“ geben.