First Input Delay (FID) im SEO

TL;DR – First Input Delay (FID) ist eine alte Metrik. Sie maß, wie lange Ihre Seite jemanden warten ließ, bevor sie auf den ersten Klick oder das erste Tippen auch nur reagieren konnte. Google musterte FID im März 2024 aus und ersetzte die Metrik durch INP; im September 2024 verschwand sie vollständig aus den Tools. Hier gibt es also nichts mehr zu beheben. Wer in alten Berichten auf „FID“ stößt, sollte aber wissen, wofür die Metrik stand.

Was First Input Delay war

Wenn Sie auf eine Schaltfläche tippen und einen Moment lang nichts passiert, wirkt die Seite kaputt – selbst wenn sie aussieht, als wäre sie bereits geladen. Mit First Input Delay (FID) gab Google genau dieser Frustration einen Messwert.

FID maß nur einen eng begrenzten Zeitraum: die Lücke zwischen Ihrer ersten Interaktion mit einer Seite (Klick, Tippen oder Tastendruck) und dem Moment, in dem der Browser tatsächlich frei war, darauf zu reagieren. War er beim Tippen gerade mit JavaScript beschäftigt, musste die Eingabe in der Warteschlange warten. Genau diese Wartezeit war die „Verzögerung“.

Zwei Dinge maß FID nicht:

• Wie lange der Code der Schaltfläche nach dem Start zur Ausführung brauchte.
• Wie lange die Seite brauchte, um sich danach visuell zu aktualisieren.

Es ging ausschließlich um die Wartezeit bis zum Beginn der Verarbeitung. Dieser enge Zuschnitt war ein wesentlicher Grund dafür, dass FID später ersetzt wurde.

Was als guter Wert galt

FID wurde in Millisekunden bewertet:

• Gut: 100 ms oder weniger
• Verbesserungsbedürftig: 100–300 ms
• Schlecht: über 300 ms

Warum Sie sich darüber keine Sorgen mehr machen müssen

Hier ist der wichtige Teil für alle, die dies im Jahr 2026 lesen: FID ist ausgemustert. Google ersetzte FID am 12. März 2024 durch INP (Interaction to Next Paint) als Core Web Vital; die Search Console zeigte FID ab demselben Tag nicht mehr an. PageSpeed Insights und die CrUX-API meldeten die Metrik noch etwas länger und entfernten sie am 9. September 2024. Wenn ein Tutorial oder ein altes Dashboard FID immer noch als aktuelles Core Web Vital aufführt, ist der Inhalt veraltet.

INP erfüllt diese Aufgabe besser: Statt nur die Wartezeit der ersten Interaktion zu messen, erfasst es die vollständige Reaktionszeit aller Interaktionen während eines Besuchs. Wenn Ihre Website heute reaktionsschneller werden soll, beobachten Sie INP und nicht FID.

Möchten Sie die vollständige Geschichte – die genauen Schwellenwerte, warum FID so eng ausgelegt war, wo alte FID-Daten noch zu finden sind und wie FID zu INP in Beziehung steht –, wechseln Sie zum Tab Fortgeschritten.

TL;DR – FID war das Core Web Vital für Reaktionsfähigkeit, bis INP die Metrik am 12. März 2024 ersetzte – dem Datum, an dem auch die Search Console sie aus ihrem Bericht entfernte. Chrome-Tools, PageSpeed Insights und die Live-CrUX-API behielten sie etwas länger und entfernten sie am 9. September 2024, jeweils nach eigenem Zeitplan. Sie maß nur die Eingabeverzögerung der ersten Interaktion – nicht die Handler-Laufzeit, nicht das Neuzeichnen – bewusst, um Fehlanreize zu vermeiden. Schwellenwerte: gut ≤100 ms, schlecht >300 ms bei p75, nur Felddaten (Total Blocking Time war der Labor-Proxy – ein korrelierter Diagnosewert, keine Umrechnungsformel). Verwechseln Sie diese Schwellenwerte nicht mit INPs 200/500 ms und versuchen Sie nicht, die Zahl einer Metrik in die andere umzurechnen. Schlechtes FID entstand durch eine blockierte Haupt-Thread-Ausführung – lange JavaScript-Tasks. Genau diese Ursache verschlechtert auch INP und TBT, sodass sich die bisherigen Maßnahmen weiterhin auszahlen. Historische FID-Daten sind im CrUX-BigQuery-Datensatz (bis zum Release 202409) erhalten; live sind sie überall verschwunden.

Was FID tatsächlich maß

Googles Definition war präzise. Laut web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” (Übersetzung) „FID misst die Zeit von der ersten Interaktion eines Nutzers mit einer Seite – etwa einem Klick auf einen Link, dem Tippen auf eine Schaltfläche oder der Bedienung eines eigenen JavaScript-Steuerelements – bis zu dem Zeitpunkt, an dem der Browser tatsächlich mit der Verarbeitung der zugehörigen Event-Handler beginnen kann.“

Lesen Sie das genau, denn der Messumfang ist entscheidend. FID erfasste die Verzögerung, bevor die Verarbeitung beginnen konnte – und nichts danach. Nicht, wie lange der Event-Handler lief. Nicht, wie lange die Seite brauchte, um das Ergebnis darzustellen. Nur die Wartezeit.

Warum konnte der Browser überhaupt „nicht beginnen“? web.dev nennt die Ursache unverblümt: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” (Übersetzung) „Im Allgemeinen entsteht eine Eingabeverzögerung (auch Eingabelatenz genannt), weil der Haupt-Thread des Browsers mit etwas anderem beschäftigt ist und deshalb (noch) nicht auf den Nutzer reagieren kann.“ Es gibt nur einen Haupt-Thread. Wenn er gerade JavaScript parst oder ausführt, während der Nutzer interagiert, bleibt die Interaktion in der Warteschlange, bis der laufende Task beendet ist. Denselben Punkt erläutere ich in meinem Ahrefs-FID-Leitfaden: JavaScript-Tasks konkurrieren um den einzigen Haupt-Thread. Solange ein Task läuft, kann die Seite nicht auf Eingaben reagieren – genau diesen Stillstand spürt der Nutzer.

Warum FID nur die Verzögerung maß (nicht die gesamte Interaktion)

Das wirkt zunächst wie ein Designfehler, war aber beabsichtigt. Google maß nur die Eingabeverzögerung. Hätte die Metrik auch die Ausführungszeit des Handlers und das Neuzeichnen einbezogen, hätten Entwickler sie laut web.dev manipulieren können: Sie hätten die Event-Handler-Logik in einen asynchronen Callback verschoben, damit der Messwert besser aussah, obwohl die tatsächliche Nutzererfahrung schlechter wurde. Deshalb blieb FID eng gefasst.

Dieser enge Zuschnitt war zugleich die entscheidende Schwäche von FID. Eine Seite konnte einen hervorragenden FID-Wert erreichen und sich dennoch träge anfühlen, weil alle Interaktionen nach der ersten ungemessen blieben. Außerdem liegen die langsamen Phasen oft in der Verarbeitung und Darstellung, die FID ignorierte. Genau diese Lücke sollte INP schließen.

Die Schwellenwerte – und der häufigste Irrtum

Gemessen wurde am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. web.dev empfahl schlicht, dass Websites einen First Input Delay von 100 Millisekunden oder weniger anstreben sollten. Mein eigener FID-Artikel verwendet dieselben Zahlen – gut ≤100 ms, verbesserungsbedürftig >100 ms und ≤300 ms, schlecht >300 ms.

Der häufige Fehler: die Schwellenwerte von FID und INP zu verwechseln. Es sind unterschiedliche Werte für unterschiedliche Metriken. FID: 100 ms gut / 300 ms schlecht. INP: 200 ms gut / 500 ms schlecht. Mehrere Zusammenfassungen von Drittanbietern – und sogar automatisierte Content-Durchläufe – vermischen beide. Wer „200 ms“ als guten FID-Schwellenwert nennt, liegt falsch.

FID war eine reine Feldmetrik

FID ließ sich nie mit Lighthouse oder einem anderen Labortool messen, weil dafür die echte erste Interaktion eines realen Nutzers erforderlich war. web.dev sagt ausdrücklich, dass FID nur im Feld gemessen werden kann, weil ein echter Nutzer mit der Seite interagieren muss. Labortools klicken nicht; deshalb gab es dort nichts, dessen Verzögerung FID hätte erfassen können.

Der Labor-Ersatz war immer Total Blocking Time (TBT). Wie ich in meinem PageSpeed-Insights-Leitfaden schreibe, finden Sie FID oder INP nicht in Labordaten: Beide setzen Klicks auf der Seite voraus, die Labortests nicht reproduzieren. Stattdessen dient Total Blocking Time als Proxy-Metrik. Diese Beziehung überdauerte FID; TBT ist heute der Labor-Proxy für INP.

Eine Einschränkung sollte klar sein: TBT ist ein korrelierter Diagnosewert und keine Umrechnungsformel. Es gab nie eine Gleichung, die einen TBT-Wert in einen exakten FID-Wert umrechnete, und für INP gibt es sie ebenfalls nicht. Ein schlechter TBT-Wert deutet lediglich darauf hin, dass Arbeit auf dem Haupt-Thread wahrscheinlich die Ursache ist; er verrät nicht, wie hoch FID oder INP im Feld gewesen wären.

Warum FID eingestellt wurde: der INP-Übergang

Der Ersatz für FID wurde lange im Voraus angekündigt. Laut web.dev wurde INP am 12. März 2024 offiziell zum Core Web Vital und ersetzte FID; damit wurde FID eingestellt und aus dem Programm entfernt. Google begründete den Wechsel damit, dass eine neue Metrik nötig war, um Aspekte der Interaktivität zu erfassen, die FID nicht abbildete.

Die Zeitleiste umfasst zwei klar getrennte Meilensteine. Sie sollten nicht zu einem einzigen Datum zusammengezogen werden, wie es selbst in automatisierten Inhalten häufig geschieht:

1. 12. März 2024 – als Core Web Vital zurückgezogen. INP übernahm; FID war nicht länger Teil des rankingrelevanten Core-Sets. Die Search Console entfernte FID am selben Tag aus ihrem Core Web Vitals-Bericht.
2. 9. September 2024 – aus den Tools entfernt, nach produktspezifischen Zeitplänen. Laut web.dev wurde FID ab diesem Datum in Chrome-Tools nicht mehr unterstützt. PageSpeed Insights stellte die Anzeige von echten Nutzer-FID-Daten ein, und die CrUX-API stellte die Bereitstellung der Metrik ein; der CrUX-BigQuery-Datensatz fügte ab Release 202409 keine neuen FID-Felder mehr hinzu, obwohl frühere Monate abfragbar blieben.

Es ist daher falsch zu behaupten, alle Google-Oberflächen hätten FID am 9. September entfernt. Der Stichtag der Search Console lag sechs Monate früher und hing mit der Ablösung durch INP zusammen, nicht mit der späteren Bereinigung der Tools.

Der FID-Artikel von web.dev beginnt heute mit dem Hinweis auf die Einstellung: First Input Delay ist kein Core Web Vital mehr und wurde durch die Metrik Interaction to Next Paint (INP) ersetzt. Und die aktuelle Core Web Vitals-Dokumentation von Google Search Central erwähnt FID überhaupt nicht – sie behandelt nur LCP, INP und CLS. Wenn das offizielle Ranking-Dokument eine Metrik nicht mehr nennt, ist sie endgültig ausgemustert.

FID vs. INP: Was hat sich geändert

Die beiden Metriken erfassen grundlegend verschiedene Dinge. Deshalb lassen sich ihre Werte nicht einfach aufeinander abbilden:

Der Zusammenhang: FID maß nur die Eingangstür einer Interaktion; INP misst die gesamte Strecke jeder Interaktion. Keine Formel rechnet einen alten FID-Wert in einen gleichwertigen INP-Wert um. Auch die FID-Platzierung einer Seite im Vergleich zu anderen Seiten sagt ihre relative INP-Platzierung nicht voraus: Die Metriken erfassen unterschiedliche Interaktionsmengen und enden an unterschiedlichen Messpunkten. Ähnliche Werte auf einer bestimmten Seite sind daher Zufall und keine Regel. Eine ausführliche Erklärung der Nachfolgemetrik finden Sie unter Interaction to Next Paint.

Wo alte FID-Daten noch zu finden sind

Die Einstellung hat die historischen Daten nicht gelöscht. Folgendes ist verschwunden beziehungsweise weiterhin verfügbar:

• Weg (live/aktuell): Der Core Web Vitals-Bericht der Search Console entfernte FID am 12. März 2024, dem Tag, an dem INP übernahm. Die PageSpeed Insights-Oberfläche und die Live-CrUX-API meldeten die Metrik etwas länger und stellten die Unterstützung am 9. September 2024 ein.
• Weiterhin vorhanden (historisch): FID-Daten von vor dem Stichtag bleiben im öffentlichen CrUX-BigQuery-Datensatz abfragbar – aber nur bis zum Datensatz 202409; BigQuery fügte ab diesem Release keine neuen FID-Felder mehr hinzu, die früheren Monate blieben jedoch abfragbar. Wenn Sie die frühere Reaktionsfähigkeit einer Website rekonstruieren müssen, suchen Sie dort und nicht in den Live-Tools. Geben Sie beim Zitieren eines Werts den Datensatzmonat an, kennzeichnen Sie ihn als historisch und behandeln Sie einen alten FID-Wert nicht als numerisch vergleichbar mit einer aktuellen INP-Zahl – es gibt keine Umrechnung zwischen ihnen (siehe Vergleichstabelle oben).

Ist FID heute noch relevant?

Direkt nicht: Es gibt nichts mehr zu messen oder zu melden und damit auch nichts „zu beheben“. Die Ursachen für schlechte FID- und INP-Werte sind jedoch nahezu identisch: lange JavaScript-Tasks blockieren den Haupt-Thread. Jede Arbeit, die Sie bereits zur Verbesserung von FID geleistet haben, war also nicht umsonst. Wie ich in meinem FID-Leitfaden anmerke: Obwohl FID im März 2024 durch INP ersetzt wurde, lohnt es sich weiterhin, an denselben zugrunde liegenden Problemen zu arbeiten. Viele der Maßnahmen, die TBT und FID verbessern, helfen auch INP.

Die Maßnahmen, die FID verbesserten, helfen heute auch INP und TBT:

• Reduzieren Sie die Menge an JavaScript, die Sie ausliefern.
• Laden Sie JavaScript später, wo möglich (async/defer).
• Teilen Sie lange Aufgaben durch Code-Splitting auf, sodass keine einzelne Aufgabe den Hauptthread monopolisiert.
• Verlagern Sie Arbeit mit Web Workern vom Haupt-Thread.
• Nutzen Sie serverseitiges Rendering oder Prerendering, um clientseitige Arbeit zu reduzieren.

War FID jemals ein großer Ranking-Faktor?

Selbst als FID aktiv war, galt die Metrik als Teil der Core Web Vitals nie als starkes Ranking-Signal. Google-Vertreter beschrieben Core Web Vitals wiederholt eher als Entscheidungshilfe bei Gleichstand denn als primäres Signal – relevant, wenn andere Faktoren ungefähr gleich sind. Zu derselben Einschätzung komme ich in meinem Core-Web-Vitals-Leitfaden: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” (Übersetzung) „Ich glaube nicht, dass Core Web Vitals großen Einfluss auf SEO haben. Solange eine Website nicht extrem langsam ist, räume ich ihrer Optimierung im Allgemeinen keine Priorität ein.“ In Aussagen von Google-Vertretern wurde FID nur selten einzeln hervorgehoben; fast immer ging es um das Core-Web-Vitals-Paket und nicht um einen eigenständigen Ranking-Hebel.

Bing und FID

Einen Bing-spezifischen Aspekt gibt es praktisch nicht. Anders als Google hat Bing Core Web Vitals nie als ausdrücklich benanntes Ranking-Signal übernommen und auch keine eigenen FID- oder INP-Schwellenwerte veröffentlicht. Bing bewertet schnelle, reaktionsfähige Seiten zwar allgemein positiv, doch FID blieb von Anfang bis Ende eine Metrik des Google-Ökosystems.

Wo es weitergeht

FID gehört zur Initiative Web Vitals im Cluster Web Performance. Diese Metriken sind für FID besonders relevant:

• Interaction to Next Paint – das Core Web Vital, das FID ersetzt hat und das Sie heute tatsächlich optimieren sollten.
• Total Blocking Time – der Labor-Stellvertreter, der für FID stand (und jetzt für INP steht), wenn Sie keine echten Interaktionen messen konnten.
• Core Web Vitals – das rankingrelevante Trio (LCP, INP, CLS), dem FID früher angehörte.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• FID = ein ausgemustertes Core Web Vital für Reaktionsfähigkeit. Die Metrik maß nur die Eingabeverzögerung der ersten Interaktion – die Wartezeit, bevor der Browser mit der Verarbeitung des Event-Handlers beginnen konnte – nicht die Laufzeit des Handlers oder das Neuzeichnen.
• Schwellenwerte: gut ≤ 100 ms, Verbesserungsbedarf 100–300 ms, schlecht > 300 ms, beim 75. Perzentil, getrennt nach Mobil/Desktop. Nur Felddaten – in Lighthouse nie messbar; die Total Blocking Time war der Labor-Stellvertreter.
• Verwechseln Sie die Schwellenwerte nicht: FID = 100/300 ms; INP = 200/500 ms. Unterschiedliche Metriken, unterschiedliche Zahlen.
• Ursache für schlechte FID-Werte: ein überlasteter Haupt-Thread durch lange JavaScript-Tasks. Das ist dieselbe Grundursache wie bei schlechten INP- und TBT-Werten.
• Ausmusterungszeitplan: ersetzt durch INP am 12. März 2024 – am selben Tag, an dem die Search Console FID aus ihrem Bericht entfernte. Chrome-Tools, PageSpeed Insights und die Live-CrUX-API stellten die Unterstützung am 9. September 2024 ein, jeweils nach eigenem Zeitplan – kein einheitlicher Stichtag. Das aktuelle CWV-Dokument von Google Search Central erwähnt es nicht mehr.
• FID vs. INP: FID maß die Verzögerung der ersten Interaktion; INP misst die volle Latenz aller Interaktionen (Verzögerung + Verarbeitung + Darstellung). Keine Formel rechnet den Wert der einen Metrik in den der anderen um.
• Alte Daten: aus den Live-Tools verschwunden; FID-Daten vor dem Stichtag leben weiterhin im CrUX-BigQuery-Datensatz bis Release 202409 – geben Sie den Datensatzmonat an und vergleichen Sie ihn nicht numerisch mit dem aktuellen INP.
• Keine Umrechnung: TBT ist ein korrelierter Labor-Proxy für FID und INP, keine Formel zur Umrechnung der Metriken.
• Noch relevant? Direkt nichts zu beheben, aber die JS-Fixes (JS reduzieren/aufschieben, lange Aufgaben aufteilen, Web Worker, SSR) übertragen sich direkt auf INP und TBT.
• Ranking-Gewicht: selbst während der aktiven Zeit gering – CWV galten eher als Tiebreaker. Patrick priorisiert sie nur bei extrem langsamen Seiten. Bing hat kein FID-Äquivalent.

Offizielle Dokumentation

Primärquellen zu FID und zur Einstellung der Metrik.

Google / web.dev

• First Input Delay (FID) – die Definition der Metrik, Schwellenwerte, warum nur die Eingabeverzögerung gemessen wurde, und die Ausmusterungsmitteilung (Philip Walton; aktualisiert am 06.10.2024).
• Chrome stellt die Unterstützung für First Input Delay ein – die Entfernung aus Chrome-Tools, PSI und der CrUX-API im September 2024 (Rick Viscomi).
• Interaction to Next Paint wird am 12. März zu einem Core Web Vital – die Ankündigung, dass INP FID ersetzen würde (Jeremy Wagner, Rick Viscomi).
• Core Web Vitals und Google-Suchergebnisse verstehen – das aktuelle Ranking-Dokument, das jetzt nur noch LCP, INP und CLS auflistet (kein FID).
• Interaction to Next Paint (INP) – die Metrik, die FID ersetzt hat.

MDN

• First Input Delay (FID) glossary – eine kurze Referenzdefinition.

Bing / Microsoft

• Keine FID-spezifische Dokumentation. Bing hat weder eigene FID-Schwellenwerte veröffentlicht noch Core Web Vitals als eigenes Ranking-Signal benannt.

Zitate aus der Quelle

Öffentliche Aussagen aus der offiziellen web.dev-Dokumentation von Google. Jeder Link ist ein Deep Link, der zur zitierten Passage auf der Quellseite springt.

Google / web.dev – was FID gemessen hat

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” (Übersetzung) „FID misst die Zeit vom ersten Moment, in dem ein Nutzer mit einer Seite interagiert (also wenn er einen Link anklickt, auf einen Button tippt oder ein benutzerdefiniertes, JavaScript-gestütztes Bedienelement verwendet), bis zu dem Zeitpunkt, an dem der Browser tatsächlich in der Lage ist, mit der Verarbeitung von Event-Handlern als Reaktion auf diese Interaktion zu beginnen.“ Zum Zitat springen
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” (Übersetzung) „Im Allgemeinen entsteht Eingabeverzögerung (auch als Eingabelatenz bezeichnet), weil der Hauptthread des Browsers mit etwas anderem beschäftigt ist und daher (noch) nicht auf den Nutzer reagieren kann.“ Zum Zitat springen

Google / web.dev – der Schwellenwert für „gut“

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” (Übersetzung) „Um eine gute Nutzererfahrung zu bieten, sollten Websites einen First Input Delay von 100 Millisekunden oder weniger anstreben.“ Zum Zitat springen

First Input Delay-Spickzettel

Status: eingestellt. Nutzen Sie diesen Spickzettel zum Lesen historischer Daten und alter Berichte, nicht als Optimierungsziel.

FID auf einen Blick

FID vs. INP – nicht verwechseln

Wichtige Daten

• 12. März 2024 – INP ersetzt FID als Core Web Vital; Search Console entfernt FID am selben Tag aus ihrem Bericht.
• 9. September 2024 – Chrome-Tools, PageSpeed Insights und die Live-CrUX-API stellen die Unterstützung für FID nach eigenem Zeitplan ein (nicht am selben Datum wie GSC).

Wo FID-Daten jetzt zu finden sind

• Live-Tools (PSI-UI, GSC, CrUX-API): entfernt (GSC seit 12. März 2024; PSI/CrUX seit 9. September 2024).
• Historie vor dem Stichtag: CrUX-BigQuery-Datensatz, bis einschließlich Release 202409. Vergleichen Sie die Werte nicht direkt mit aktuellen INP-Werten; es gibt keine Umrechnung.

Behebung des zugrunde liegenden Problems (hilft jetzt INP/TBT)

• JavaScript reduzieren · verzögert oder asynchron laden · lange Tasks aufteilen (Code-Splitting) · Web Worker einsetzen · SSR/Prerendering nutzen.

Fehler, die Sie bei Legacy-FID-Daten vermeiden sollten

FID als aktuelles Core Web Vital behandeln

FID wurde im März 2024 durch INP ersetzt und später im selben Jahr aus den aktuellen Chrome-Berichtsoberflächen entfernt. Nutzen Sie INP für die heutige Optimierung der Reaktionsfähigkeit und FID nur zur Interpretation historischer Datensätze.

FID und INP mit denselben Schwellenwerten vergleichen

Die historischen Gut/Schlecht-Schwellenwerte von FID lagen bei 100/300 ms; die von INP bei 200/500 ms. Die Zahlen sind nicht austauschbar, da FID nur die Verzögerung vor dem Handler maß, während INP die Interaktion bis zum nächsten Paint abdeckt.

FID in einem Labortest suchen

FID erforderte die echte erste Eingabe eines Nutzers und ließ sich nur im Feld messen. Total Blocking Time war der Labor-Proxy; ein Lighthouse-Ergebnis stellte nie eine direkte FID-Messung dar.

Einen ausgemusterten Messwert statt des Nutzerproblems optimieren

Machen Sie ein FID-Dashboard nicht weiter zum Ziel. Teilen Sie lange Main-Thread-Tasks auf, reduzieren Sie blockierendes JavaScript und messen Sie die aktuelle Reaktionsfähigkeit anschließend mit INP im Feld.

Testen Sie sich selbst: First Input Delay (FID)

Fünf kurze Fragen dazu, was FID gemessen hat und warum die Metrik ausgemustert wurde. Wählen Sie jeweils eine Antwort und kontrollieren Sie anschließend Ihre Auswahl.

Änderungsprotokoll