Core Web Vitals – First Input Delay (FID) verbessern

Core Web Vitals: First Input Delay
Kai SpriestersbachVon Kai Spriestersbach|30. September 2021

So optimierst du deinen FID-Wert

Der erste Eindruck zählt oftmals am meisten und bleibt nachhaltig im Gedächtnis. Ein schlechter erster Eindruck meist noch mehr als ein guter. Gerade der erste Eindruck von der Reaktionsfähigkeit einer Webseite hat einen großen Einfluss darauf, wie deine Webseite wahrgenommen wird. Denn es ist sehr unschön wenn deine User mit deiner Webseite interagieren möchten, diese aber zu lange lädt, verzögert reagiert oder Aktionen nicht richtig ausgeführt werden können.

Der FID Wert beschreibt genau dieses Problem, weswegen wir dir hier zeigen, wie du den FID-Wert optimieren kannst.

1. Was ist der First Input Delay?

Der Firs Input Delay – kurz FID – misst die Zeit, die vergeht, bevor der User auf einer Webseite interagieren kann. Das FID beschreibt also die vergangene Zeit zwischen der ersten Browserinteraktion und der ersten User-Interaktion auf der Webseite. Die Zeitmessung beginnt sozusagen beim Klick auf die Webseite und endet in dem Moment, in dem der Browser die Anfrage verarbeitet und die Weiterleitung öffnet. Diese Zeit 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.

 

Um ein gutes Nutzererlebnis zu bieten, informiert Google über die FID, dass eine gute Webseite eine erste Eingabeverzögerung von 100 Millisekunden oder weniger haben sollte. Zwischen 100 und 300 Millisekunden gilt die Seite als verbesserungswürdig und ab 300 Millisekunden als schlecht. 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.

core Web Vitals - FID

2. Den FID-Wert analysieren

Die Kennzahl des „First Input Delay“ (FID) aus den Core Web Vitals hilft dabei, genau diese Reaktionsfähigkeit deiner 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
Hier siehst du die Interaktionen und Reaktionen auf deiner Webseite

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


TIPP 💡

Zum genauen Verständnis ist es wichtig, 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.

 

 

‼️ Achtung

Insbesondere beim FID ist das jedoch nur für erfahrene Entwickler sinnvoll, denn spätestens bei der Ursachenbehebung ist der Zugang zu Code und die Erfahrung bei der Webentwicklung unbedingt notwendig.

Core Web Vitals FID beobachten
Die FID-Werte beobachten

3. FID 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. FID – 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 solltest du versuchen, die Auswirkungen von Drittanbieter-Code zu reduzieren, also beispielsweise Google Analytics und andere Tracking-Skripte verzögert zu 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.

Für noch mehr Informationen, kannst du dir die Tipps von Google zur Verbesserung der FID-Werte anschauen.

5. FID 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“. Anschließend wird deine Webseite 28 Tage lang überwacht, um herauszufinden, ob das Problem auch noch an einer anderen Stelle deiner Webseite vorkommt.

Tritt es innerhalb dieses Zeitraums bei keiner URL deiner 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.

Kai Spriestersbach

Kai Spriestersbach, B.Sc. E-Commerce, ist Inhaber von SEARCH ONE und Chefredakteur des gleichnamigen Onlinemagazins. Er ist einer der erfahrensten Search Marketing Experten im deutschsprachigen Raum. Er kann dabei auf mehr als 17 Jahren Erfahrung beim Aufbau und der Optimierung webbasierter Vertriebs- und Geschäftsmodelle zurückgreifen. Als Lehrbeauftragter für „SEO in der Praxis“ unterrichtet er an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt und absolviert nebenberuflich ein Masterstudium zum Master of Science (M. Sc.) in Web Science an der TH Köln.

HostPress GmbH hat 4,93 von 5 Sternen 414 Bewertungen auf ProvenExpert.com