Core Web Vitals: First Input Delay

First Input Delay (FID) verbessern und optimieren! – CWV-Serie 4/5:

Im vierten Teil unserer Artikelserie zu den Core Web Vitals kommen wir nun zu einer schwierig zu messenden Metrik: Der „First Input Delay“, also die Verzögerung der ersten Eingabe, ist eine wichtige, nutzerorientierte Kennzahl für die Messung der Reaktionsfähigkeit der Ladevorgänge. Sie quantifiziert die Probleme der Interaktion mit nicht reagierenden Seiten.

Inhaltsverzeichnis:

  1. Was ist der FID und was bedeutet First Input Delay?
  2. So analysierst Du den FID-Wert
  3. Probleme priorisieren und mit Entwicklern teilen
  4. Häufige Ursachen und Problemlösungen für schlechte FID-Werte
  5. Fehlerbehebung überprüfen

 

1. Was ist der FID und was bedeutet First Input Delay?

Wir alle wissen, wie wichtig es ist, einen guten ersten Eindruck zu hinterlassen. Das ist wichtig, wenn man neue Leute kennenlernt, und es ist ebenso wichtig, wenn man Webseiten besucht. Dieser erste Eindruck kann den Unterschied ausmachen, ob jemand ein treuer Nutzer wird oder ob er die Seite verlässt und nie wieder zurückkommt. Gerade der erste Eindruck von der Reaktionsfähigkeit einer Webseite hat einen großen Einfluss darauf, wie wir eine Webseite wahrnehmen, ist doch nichts nerviger als eine Webseite, mit der wir interagieren wollen, die aber noch nicht bereit ist oder mit Verzögerungen auf unsere Eingaben reagiert und uns dadurch Aktionen mehrfach ausführen lässt.

First Input Delay: Eingabeverzögerung von 100ms oder weniger
First Input Delay: Eingabeverzögerung von 100ms oder weniger sind ideal

 

Um ein gutes Nutzererlebnis zu bieten, sollten Websites laut Google eine erste Eingabeverzögerung von 100 Millisekunden oder weniger haben. Um sicherzustellen, dass du dieses Ziel für die meisten Nutzer erreichst, ist ein guter Schwellenwert das 75. Perzentil der Seitenladevorgänge, aufgeschlüsselt nach mobilen und Desktop-Geräten.

 

2. So analysierst Du den FID-Wert

Die Kennzahl des „First Input Delay“ (FID) aus den Core Web Vitals hilft dabei, genau diese Reaktionsfähigkeit Ihrer Website zu messen. Anders als die beiden anderen Metriken, CLS und LCP lässt sich der FID jedoch nicht einfach mittels Lighthouse Test messen. Für die Messung der Verzögerung ist eine Interaktion eines Nutzers notwendig und diese gibt es naturgemäß bei Labor-Tests wie Googles PageSpeed Insights oder Lighthouse nicht.

 

Am besten ist es daher, sich auf die Werte im Core Web Vitals Bericht der Search Console zu verlassen:

 

First Input Delay: Erste Interaktion des Nutzers bis zur Reaktion des Browsers
First Input Delay: Erste Interaktion des Nutzers bis zur Reaktion des Browsers

Dort findet man die Zeit von der ersten Interaktion des Nutzers mit Ihrer Seite bis zum Reagieren des Browsers auf diese Interaktion. Eine Interaktion findet aber nur statt, wenn der Nutzer auf einen Link klickt oder auf eine Schaltfläche tippt, nicht etwa beim Scrollen oder Zoomen.

 

Wichtig zum Verständnis ist noch, dass der „aggregierter FID“ im Bericht das 75. Percentil angibt, also der Mindest-Wert, der bei 75 % der Besuche einer URL in dieser Gruppe erreicht wurde.

 

Dieser Wert ist damit leider nur sehr schwer zu debuggen, denn er wird von dem interaktiven Element abgerufen, auf das der Nutzer zuerst klickt. Das können bei unterschiedlichen Nutzern verschiedene Elemente zu vollkommen unterschiedlichen Zeitpunkten sein. Ein Nutzer versucht womöglich bereits nach zwei Sekunden das Hauptmenü aufzurufen, ein anderer klickt vielleicht erst nach 25 Sekunden Lesezeit einen Link auf eine Unterseite an.

 

Am besten verwendest Du das CrUX Dashboard, um den FID-Wert Deiner Website zu beobachten. In der Search Console, lassen sich die Seiten identifizieren, die Probleme verursachen und Aufmerksamkeit benötigen. Mit den PageSpeed Insights oder dem Lighthouse Test, oder auch den Chrome DevTools kannst du dann tief in die Analyse der Metriken der Benutzererfahrung für eine bestimmte Seite eintauchen. Insbesondere beim FID ist dies aus meiner Sicht jedoch nur für erfahrene Entwickler sinnvoll, denn spätestens, um die Ursachen zu beheben, sind Zugang zu Code und Erfahrung bei der Webentwicklung unbedingt notwendig.

 

First Input Delay: Wert analysieren
First Input Delay: Wert analysieren

3. Probleme priorisieren und mit Entwicklern teilen

Du solltest damit beginnen, zuerst alle als „Langsam“ gekennzeichneten Seiten und deren Probleme zu beheben. Du kannst diese nach der Anzahl von URLs priorisieren. URLs, die mit „Optimierung erforderlich“ gekennzeichnet sind, kannst du später verbessern, wenn die wirklich „langsamen“ alle behoben wurden.

 

Wenn du deine Prioritäten gesetzt hast, kannst du den Bericht mit deinen Entwicklern bzw. der Person, die deine Webseite verwaltet teilen. Dazu musst du auf die Schaltfläche „Teilen“ klicken. Der geteilte Link bietet nur Zugriff auf die Seite mit den Problemdetails sowie auf die Seiten mit dem Überprüfungsverlauf für das Problem.

 

Jeder, der diesen Link hat, kann darauf zugreifen. Nutzer, mit denen der Link geteilt wurde, können aber nicht auf andere Seiten in der Search Console zugreifen, noch etwas an der Property oder dem Konto verändern. Der Link lässt sich außerdem jederzeit ungültig machen, indem man das Teilen für diese Seite deaktiviert.

4. Häufige Ursachen und Problemlösungen für schlechte FID-Werte

Lange Verzögerungen bei der ersten Eingabe treten typischerweise zwischen dem „First Contentful Paint“ (FCP) und der „Time to Interactive“ (TTI) auf, weil die Seite zwar einen Teil ihres Inhalts gerendert hat, aber noch nicht zuverlässig interaktiv ist. 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 Zeit, die er warten muss, ist der FID-Wert für diesen Benutzer auf dieser Seite.

 

Zur Verbesserung der FID empfiehlt Google, sich auf die Verbesserung der „Total Blocking Time“ (TBT) als guten Stellvertreter zu konzentrieren. Diese misst zwar etwas anderes, aber Verbesserungen der TBT entsprechen in der Regel auch Verbesserungen der FID.

 

Die Hauptursache für eine schlechte FID und auch für eine hohe „Blocking Time“ ist die intensive Ausführung von JavaScript. Wenn man also das Parsen, Kompilieren und Ausführen von JavaScript auf einer Webseite optimiert, wird automatisch auch die FID reduziert.

 

Bei einem zu hohen FID-Wert empfiehlt es sich generell, zunächst die Seitengröße zu verringern. Als Best Practice empfiehlt Google weniger als 500 KB für eine Seite und alle zugehörigen Ressourcen. Anschließend sollte man versuchen, die Auswirkungen von Drittanbieter-Code zu reduzieren, also beispielsweise Google Analytics und andere Tracking-Skripte verzögert laden. Dies lässt sich häufig relativ einfach durch die Verwendung des „defer“-Attributs im Script-Tag umsetzen. Manchmal hilft es auch eine geringe Anzahl von Anfragen und kleine Übertragungsgrößen für den Aufbau der Webseite zu verwenden, um den Browser zu entlasten.

 

Weitere Maßnahmen erfordern in der Regel tiefergehende Veränderungen der eingesetzten Skripte, wie die Verkürzung der JavaScript-Ausführungszeit oder die Minimierung der Arbeit des Haupt-Threads. Wenn du bereits versucht hast, die Menge an JavaScript, die auf deiner Seite geladen wird, zu reduzieren, kann es nützlich sein, langlaufenden Code in kleinere, asynchrone Aufgaben aufzuteilen. Sogenannte „Long Tasks“ sind JavaScript-Ausführungszeiträume, in denen die Benutzer die Benutzeroberfläche als nicht-interaktiv empfinden. Jedes Code-Fragment, das den Haupt-Thread für 50 ms oder länger blockiert, wird als Long Task bezeichnet werden. Lange Tasks sind ein Anzeichen für aufgeblähte JavaScripts. Vermeide also das Laden und Ausführen von mehr Code, als der Benutzer im Moment benötigt. Die Aufteilung langer Tasks kann die Eingabeverzögerung auf der Website ebenfalls verringern.

 

Hier findest du weitere Tipps, wie du den FID-Wert deiner Seite verbessern kannst.

5. Fehlerbehebung überprüfen

Wenn du nun ein Problem mit dem FID behoben hast, solltest du prüfen, ob es auch bei allen URLs behoben wurde. Dazu klickst du einfach auf „Tracking starten“. Dann wird 28 Tage lang überwacht, ob das Problem noch an anderer Stelle auf Ihrer Website vorkommt.

 

Tritt es innerhalb dieses Zeitraums bei keiner URL Ihrer Website auf, gilt es als behoben. Selbst, wenn es nur bei einer einzigen URL auftritt, gilt es als nicht behoben. Der Status einzelner URLs wird jedoch unabhängig davon die gesamten 28 Tage lang analysiert.

 

Über die „Tracking starten“-Funktion wird deine Website weder neu indexiert noch eine andere Aktion durch Google ausgeführt. Es wird lediglich eine vierwöchige Überwachung der CrUX-Daten für deine Website durch die Search Console gestartet.

 

Wenn die Überprüfung fehlschlägt, solltest du erneut versuchen das Problem zu beheben und die Überprüfung erneut starten.

5/5 - (6 votes)