First Input Delay (FID) - Core Web-Vitals (Teil 3)

Die Metrik First Input Delay (FID) ist eine wichtige nutzerzentrierte Kennzahl um die gefühlte Reaktivität der Website auf Benutzereingaben zu messen. Ziel ist es diesen Wert so gering wie möglich zu halten, damit eine gute Usability (Gebrauchstauglichkeit) der Website sichergestellt ist.

Der erste Eindruck zählt

Beim Besuch entscheidet der Nutzer ziemlich schnell ob er weiterhin auf der Website bleibt oder diese direkt verlässt und im schlimmsten Fall nie wieder kommt. In diese Entscheidung fließen verschiedene Eindrücke des Nutzers ein. Der Benutzer stellt sich unbewusst die Fragen: Wie visuell ansprechend ist die Website auf den Nutzer? Wie schnell ist die Website? Wie reaktionsfähig ist die Website? Die meisten Eindrücken können wir nicht einfach messen, aber bei Geschwindigkeit und Reaktionsfähigkeit ist dies durchaus möglich.

Was ist der First Input Delay?

FID misst die Zeit von der ersten Interaktion des Benutzers mit der Website bis hin zu dem Zeitpunkt an welchem der Browser in der Lage ist, mit der Verarbeitung der Interaktion in einem Event-Handler zu beginnen. Beispiele für eine Interaktion wären ein Klick auf ein Link, auf einen Button oder irgendeine getriggerte JavaScript-Aktion.

Was ist ein guter FID Wert?

Um eine gute User Experience sicherzustellen, sollte der First Input Delay geringer als 100ms sein. Dieser Zielwert sollte bei mindestens 75% der Websites (geräteübergreifend) erreicht werden.

Als Entwickler gehen wir häufig davon aus, das Event-Handler sofort ausgeführt werden, sobald das Ereignis eintritt. Die Realität sieht aber häufig anders aus und der Benutzer muss auf ein Event-Handling warten. Meistens kommt es zu dieser Verzögerung (input latency) wenn der Hauptthread des Browsers noch mit einer anderen Aufgabe beschäftigt ist. Eine Aufgabe könnte zum Beispiel das Parsen und Ausführen einer großen JavaScript-Datei sein. Währenddessen kann kein Event-Handler ausgeführt werden, da es sein könnte, dass in dieser Datei sich die Ausführungslogik ändert.

Merke:
FID misst nur die Verzögerung bei der Ereignisverarbeitung. Es wird weder die Eventverarbeitungszeit noch die Zeit die der Browser benötigt, die Ausgabe zu aktualisieren gemessen. Diese Zeit wirkt sich zwar auch stark auf die Benutzer Erfahrung aus, doch könnte man diese leicht beeinflussen, in dem man die Verarbeitung asynchron erledigt. Das würde den Wert zwar verbessern, sich aber negativ auf die User Experience auswirken.

In dem Beispiel sieht man das wasserfallartige Laden der Website-Ressourcen (graue Balken). Hier wird zuerst das grundlegende HTML-Dokument geladen und anschließend alle angegebenen Ressourcen wie JavaScript, CSS,.... Nachdem die Dateien geladen wurden, werden diese im Hauptthread (beige Balken) verarbeitet.

Lange Verzögerungen des FID treten typischerweise zwischen dem FCP (First Contentful Paint) und der TTI (Time to Interactive) auf, da schon ein Teil der Website gerendert wurde, aber noch nicht zuverlässig interaktiv ist. Folgende Grafik zeigt diese Verzögerung.

In diesem Beispiel liegt eine gewisse Zeit zwischen dem First Contentful Paint und der Time to Interactive. In dieser Zeit liegen auch drei lange Aufgaben im Hauptthread (beige Balken). Wenn während dieser Zeit ein Besucher versucht mit der Website zu interagieren, kommt es zu einer Verzögerung.

In der folgenden Zeitachse können Sie sehen, was passiert wenn der Nutzer zu Beginn der zeitintensivsten Aufgabe versucht mit der Seite zu agieren.

Die Eingabe erfolgt während der Browser gerade eine Aufgabe ausführt. So muss gewartet werden bis die Aufgabe abgeschlossen ist, bis der Browser auf die Eingabe reagieren kann.

Was passiert wenn eine Interaktion kein Event-Listener hat?

Bei der Metrik FID wird das Delta zwischen Empfang eines Input Events und dem nächsten Leerlauf des Hauptthreads gemessen. Damit wird der FID auch in den Fällen gemessen, in denen kein Event-Listener registriert wurde. Der Grund hierfür ist, dass viele Benutzerinteraktionen kein Event-Listener, aber einen Leerlauf des Hauptthreads, benötigen um ausgeführt zu werden.

So müssen beispielsweise folgende HTML-Elemente warten bis die laufende Aufgaben im Hauptthread abgeschlossen wurden, bevor diese auf Interaktionen des Benutzers reagieren können:

• <input>
• <textarea>
• <select>
• <a>

Warum wird nur der First Input berücksichtigt?

Neben dem FID verschlechtern natürlich auch alle anderen Verzögerungen die User Experience. Warum wird dann nur der FID gemessen?

• Der First Input Delay wiederspiegelt den ersten Eindruck des Benutzers mit der Reaktionsfähigkeit der Website. Dieser erste Eindruck ist entscheident für den Gesamteindruck des Benutzers für die aufgerufene Website.
• Erfahrungsgemäß bestehen die größten Probleme mit der Reaktionsfähigkeit einer Website beim Seitenaufbau.
• Die empfohlenen Optimierungsmaßnahmen für die Verbesserung eines hohen FID sind andere als die zur Optimierung von Verzögerungen die nach dem Laden einer Seite erforderlich sind.

Welche Interaktionen zählen zum First Input und welche nicht?

Zählen:

• Klicks
• Tippen
• Tastendrücken

Zählen nicht:

• Scrollen
• Zoomen

Wie können Sie den FID optimieren?

• Impact von third-party Code reduzieren
• JavaScript Ausführungszeit reduzieren
• Aufgaben im Hauptthread minimieren
• Möglichst wenig und kleine Requests

In einem weiteren Beitrag dieser Serie werden wir uns detailliert mit der Optimierung des FID beschäftigen.

Beitragsserie "Core Web Vitals"

• Teil 1: Google Page Experience Update und Core Web-Vitals
• Teil 2: Largest Contentful Paint (LCP)
• Teil 3: First Input Delay (FID) (dieser Beitrag)
• Teil 4: Cumulative Layout Shift (CLS)
• Teil 5: Messen der Core Web Vitals