Wir alle wissen, wie wichtig es ist, einen guten ersten Eindruck zu machen. Das ist wichtig, wenn man neue Leute kennenlernen möchte, und auch, wenn man Erfahrungen im Web erschaffen möchte.
Ein guter erster Eindruck im Internet kann den Unterschied machen, ob jemand ein treuer Nutzer wird oder ob jemand die Website wieder verlässt und nie wiederkommt. Die Frage ist, was einen guten Eindruck ausmacht und wie Sie messen, welchen Eindruck Sie bei Ihren Nutzern wahrscheinlich erzielen werden.
Der erste Eindruck im Web kann viele verschiedene Formen annehmen. So erhalten wir einen ersten Eindruck vom Design und der Optik einer Website sowie einen ersten Eindruck von der Geschwindigkeit und Reaktionsschnelligkeit.
Es ist zwar schwierig zu messen, wie sehr Nutzern das Design einer Website gefällt, mit Web-APIs, das Messen der Geschwindigkeit und Reaktionsfähigkeit ist es jedoch nicht.
Der erste Eindruck davon, wie schnell Ihre Website geladen wird, kann mit First Contentful Paint (FCP) gemessen werden. Aber wie schnell sich mit Ihrer Website Pixel auf dem Bildschirm darstellen lassen, ist nur ein Teil der Geschichte. Ebenso wichtig ist die Reaktionsfähigkeit Ihrer Website, wenn Nutzer mit diesen Pixeln interagieren.
Mit dem Messwert „First Input Delay“ (FID) lässt sich der erste Eindruck des Nutzers in Bezug auf die Interaktivität und Reaktionsfähigkeit Ihrer Website messen.
Was ist FID?
FID gibt die Zeit ab der ersten Interaktion eines Nutzers mit einer Seite (d. h. dem Klicken auf einen Link, dem Tippen auf eine Schaltfläche oder Verwendung eines benutzerdefinierten JavaScript-Steuerelements) bis zu dem Zeitpunkt an, zu dem der Browser als Reaktion auf diese Interaktion Event-Handler verarbeiten kann.
Was ist ein guter FID-Wert?
Für eine gute Nutzerfreundlichkeit sollten Websites eine First Input Delay von 100 Millisekunden oder weniger anstreben. Damit Sie dieses Ziel für die meisten Nutzer erreichen, sollten Sie das 75. Perzentil der Seitenaufbauvorgänge, aufgeschlüsselt nach Mobilgeräten und Desktop-Geräten, 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 das Gegenteil erlebt: Wir haben eine Webseite auf unserem Smartphone geladen, versucht, mit ihr zu interagieren, und sind dann frustriert, als nichts passiert ist.
Im Allgemeinen tritt eine Eingabeverzögerung (auch als Eingabelatenz bezeichnet) auf, weil der Hauptthread des Browsers mit etwas anderem ausgelastet ist und dem Nutzer (noch) nicht antworten kann. Ein häufiger Grund dafür ist, dass der Browser mit dem Parsen und Ausführen einer großen JavaScript-Datei, die von Ihrer Anwendung geladen wird, beschäftigt ist. Dabei kann er keine Event-Listener ausführen, da der geladene JavaScript-Code möglicherweise etwas anderes tut.
Betrachten Sie die folgende Zeitachse für einen typischen Ladevorgang einer Webseite:
Die obige Visualisierung zeigt eine Seite, die einige Netzwerkanfragen für Ressourcen sendet (wahrscheinlich CSS- und JS-Dateien). Nachdem diese Ressourcen heruntergeladen wurden, werden sie im Hauptthread verarbeitet.
Dies führt zu Zeiten, in denen der Hauptthread kurzzeitig ausgelastet ist. Dies wird durch die beigefarbenen Aufgabenblöcke angezeigt.
Verzögerungen bei der ersten Eingabe treten normalerweise zwischen First Contentful Paint (FCP) und Time to Interactive (TTI) auf, da die Seite einen Teil ihres Inhalts gerendert hat, aber noch nicht zuverlässig interaktiv ist. Um zu veranschaulichen, wie dies möglich ist, wurden FCP und TTI in den Zeitplan aufgenommen:
Sie haben vielleicht bemerkt, dass zwischen FCP und TTI ziemlich viel Zeit (einschließlich drei langer Aufgaben) liegt. Wenn ein Nutzer während dieser Zeit versucht, mit der Seite zu interagieren (z. B. durch Klicken auf einen Link), kann es zu einer Verzögerung zwischen dem Empfang des Klicks und der Reaktion des Hauptthreads kommen.
Überlegen Sie, was passieren würde, wenn ein Nutzer zu Beginn der längsten Aufgabe versucht, mit der Seite zu interagieren:
Da die Eingabe erfolgt, während der Browser 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 Differenz zwischen dem Empfang eines Eingabeereignisses und dem nächsten inaktiven Hauptthread. Das bedeutet, dass FID auch dann gemessen wird, wenn kein Event-Listener registriert ist. Dies liegt daran, dass für viele Nutzerinteraktionen kein Event-Listener erforderlich ist, der Hauptthread jedoch unbedingt inaktiv sein muss, damit sie ausgeführt werden können.
Die folgenden HTML-Elemente müssen beispielsweise warten, bis laufende Aufgaben im Hauptthread abgeschlossen sind, bevor sie auf Nutzerinteraktionen antworten:
- Textfelder, Kästchen und Optionsfelder (
<input>,<textarea>) - Drop-down-Menüs auswählen (
<select>) - Links (
<a>)
Warum sollte nur die erste Eingabe berücksichtigt werden?
Obwohl eine Verzögerung von einer Eingabe zu einer schlechten User Experience führen kann, empfehlen wir aus folgenden Gründen hauptsächlich, die erste Eingabeverzögerung zu messen:
- Die erste Eingabeverzögerung ist der erste Eindruck des Nutzers von der Reaktionsfähigkeit Ihrer Website. Der erste Eindruck ist entscheidend für unseren Gesamteindruck von der Qualität und Zuverlässigkeit einer Website.
- Die meisten Interaktivitätsprobleme, die wir heute im Web beobachten, treten beim Seitenaufbau auf. Daher sind wir der Meinung, dass der erste Fokus auf die Verbesserung der ersten Nutzerinteraktion auf der Website den größten Einfluss auf die Verbesserung der Gesamtinteraktion des Webs haben wird.
- Die empfohlenen Lösungen, mit denen Websites mit hohen Verzögerungen bei der ersten Eingabe (z. B. Codeaufteilung, weniger JavaScript-Ladevorgang usw.) umgehen sollten, sind nicht unbedingt dieselben Lösungen, um langsame Eingabeverzögerungen nach dem Seitenaufbau zu beheben. 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 Ladevorgangs misst. Daher konzentriert es sich nur auf Eingabeereignisse aus diskreten Aktionen wie Klicken, 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 konzentriert sich FID auf das R (Responsivität) im RAIL-Leistungsmodell, während Scrollen und Zoomen eher mit A (Animation) zusammenhängen und ihre Leistungsmerkmale separat bewertet werden sollten.
Was passiert, wenn ein Nutzer nie mit Ihrer Website interagiert?
Nicht alle Nutzer interagieren jedes Mal 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 schlechten Zeiten statt, wenn der Hauptthread über einen längeren Zeitraum ausgelastet ist. Die ersten Interaktionen einiger Nutzer finden zu guten Zeiten statt, wenn der Hauptthread vollständig inaktiv ist.
Das bedeutet, dass einige Nutzer keine FID-Werte, andere einen niedrigen FID-Wert und andere wahrscheinlich hohe FID-Werte haben werden.
Die Art und Weise, wie Sie FID erfassen, Berichte dazu erstellen und analysieren, wird sich wahrscheinlich etwas von anderen Messwerten unterscheiden, die Sie vielleicht kennen. Im nächsten Abschnitt wird erläutert, wie Sie dies am besten tun.
Warum sollte nur die Eingabeverzögerung berücksichtigt werden?
Wie bereits erwähnt, misst FID nur die „Verzögerung“ bei der Ereignisverarbeitung. Er misst weder die Zeit für die Ereignisverarbeitung selbst noch die Zeit, die der Browser benötigt, um die UI nach dem Ausführen von Event-Handlern zu aktualisieren.
Auch wenn diese Zeit für den Nutzer wichtig ist und sich auf die Nutzerfreundlichkeit beeinflusst, ist sie in diesem Messwert nicht enthalten, da dies Entwickler dazu motivieren könnte, Problemumgehungen zu implementieren, die das Erlebnis tatsächlich verschlimmern. Sie könnten also ihre Event-Handler-Logik in einen asynchronen Callback (über setTimeout() oder requestAnimationFrame()) einbinden, um sie von der mit dem Ereignis verbundenen Aufgabe zu trennen. Das Ergebnis wäre eine Verbesserung des Messwertwerts, aber aus Sicht des Nutzers eine langsamere Reaktion.
Während FID nur den „Verzögerung“-Teil der Ereignislatenz misst, können Entwickler, die einen größeren Teil des Ereignislebenszyklus verfolgen möchten, dies mit der Event Timing API tun. Weitere Informationen finden Sie in der Anleitung zu benutzerdefinierten Messwerten.
FID messen
FID ist ein Messwert, der nur vor Ort gemessen werden kann, da ein echter Nutzer mit Ihrer Seite interagieren muss. Sie können den FID-Wert mit den folgenden Tools messen.
Außendienst-Tools
- Bericht zur Nutzererfahrung in Chrome
- PageSpeed Insights
- Search Console (Core Web Vitals-Bericht)
web-vitals-JavaScript-Bibliothek
FID in JavaScript messen
Zum Messen der FID in JavaScript kannst du die Event Timing API verwenden. Das folgende Beispiel zeigt, wie Sie einen PerformanceObserver erstellen, der first-input-Einträge überwacht und in der Console 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 gemessen, indem das Delta zwischen den Zeitstempeln startTime und processingStart des Eintrags ermittelt wird. In den meisten Fällen ist dies der FID-Wert. Allerdings sind nicht alle first-input-Einträge zum Messen der FID gültig.
Im folgenden Abschnitt werden die Unterschiede zwischen den Informationen in der API und der Berechnung des Messwerts aufgeführt.
Unterschiede zwischen Messwert und API
- Die API sendet
first-input-Einträge für Seiten, die in einem Hintergrund-Tab geladen werden. Diese Seiten sollten jedoch bei der Berechnung des FID-Werts ignoriert werden. - Die API sendet auch
first-input-Einträge, wenn die Seite vor der ersten Eingabe im Hintergrund war. Diese Seiten sollten jedoch bei der Berechnung der FID ebenfalls ignoriert werden. Eingaben werden nur berücksichtigt, wenn die Seite die ganze Zeit im Vordergrund zu sehen war. - Die API meldet keine
first-input-Einträge, wenn die Seite aus dem Back-Forward-Cache wiederhergestellt wird. FID sollte jedoch in diesen Fällen gemessen werden, da Nutzer sie als verschiedene Seitenbesuche erleben. - Die API meldet keine Eingaben, die in iFrames erfolgen, sondern nur für den Messwert, da sie Teil der Nutzererfahrung auf der Seite sind. Dies kann sich als Unterschied zwischen CrUX und RUM anzeigen lassen.
Um den FID-Wert korrekt zu messen, sollten Sie sie berücksichtigen. Subframes können die API verwenden, um ihre
first-input-Einträge zur Aggregation an den übergeordneten Frame zu melden.
Anstatt sich all die subtilen Unterschiede zu merken, können Entwickler die web-vitals-JavaScript-Bibliothek verwenden, um die FID zu messen, die diese Unterschiede für dich handhabt (falls möglich – das iFrame-Problem wird nicht behandelt):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Im Quellcode für onFID() finden Sie ein vollständiges Beispiel für die Messung der FID in JavaScript.
FID-Daten analysieren und Berichte dazu erstellen
Aufgrund der erwarteten Abweichung der FID-Werte ist es wichtig, dass Sie sich bei Berichten zum FID-Wert auf die Verteilung der Werte konzentrieren und sich auf die höheren Perzentile konzentrieren.
Obwohl die Auswahl des Perzentils für alle Core Web Vitals-Grenzwerte der 75. ist, empfehlen wir insbesondere für FID weiterhin dringend, das 95. bis 99. Perzentil zu betrachten, da diese sich auf die besonders schlechten ersten Erfahrungen beziehen, die Nutzer mit Ihrer Website haben. Und Sie sehen die Bereiche, die am meisten verbessert werden müssen.
Dies gilt auch dann, wenn Sie Ihre Berichte nach Gerätekategorie oder -typ segmentieren. Wenn Sie beispielsweise separate Berichte für Computer und Mobilgeräte erstellen, sollte der FID-Wert, der für Computernutzer am wichtigsten ist, das 95. bis 99. Perzentil der Computernutzer und der FID-Wert, der Ihnen am wichtigsten ist, für Mobilgerätenutzer das 95. bis 99. Perzentil der mobilen Nutzer sein.
FID verbessern
In einem vollständigen Leitfaden zur FID-Optimierung finden Sie Techniken zur Verbesserung dieses Messwerts.
Änderungsprotokoll
Gelegentlich werden Fehler in den APIs entdeckt, die zum Messen von Messwerten verwendet werden, und manchmal in den Definitionen der Messwerte selbst. Aus diesem Grund müssen gelegentlich Änderungen vorgenommen werden, die sich in Ihren internen Berichten und Dashboards als Verbesserungen oder Regressionen zeigen lassen.
Alle Änderungen an der Implementierung oder an der Definition dieser Messwerte werden in diesem Änderungsprotokoll angezeigt.
Wenn du Feedback zu diesen Messwerten hast, kannst du es in der Google-Gruppe „web-vitals-feedback“ einreichen.