Time to Interactive (TTI)

TL;DR — Time to Interactive (TTI) maß, wie lange eine Seite brauchte, um zuverlässig klickbar zu sein – nicht nur auf dem Bildschirm dargestellt, sondern tatsächlich in der Lage, auf Tippen oder Klicken zu reagieren. Früher war es Teil Ihres Lighthouse-Scores. Das ist es nicht mehr: Google hat es 2023 aus Lighthouse entfernt, weil der Wert zu stark schwankte. Es war nie eine Core Web Vital und hat Ihre Google-Rankings nie beeinflusst.

Was Time to Interactive war

Eine Seite kann fertig aussehen, bevor sie es tatsächlich ist. Der Text ist da, die Schaltflächen sind sichtbar – aber wenn das JavaScript noch nicht vollständig geladen und ausgeführt wurde, bewirkt ein Tippen auf eine Schaltfläche nichts oder verzögert sich um eine Sekunde, bevor etwas passiert. Diese Lücke zwischen „sieht fertig aus“ und „ist fertig“ ist genau das, was TTI erfassen sollte.

TTI markierte den Moment, in dem eine Seite ihre wichtigsten Unterressourcen geladen hatte und zuverlässig auf Ihre Eingaben reagieren konnte. Vor diesem Zeitpunkt konnte die Seite eingefroren sein, obwohl sie fertig aussah.

Warum Sie es möglicherweise noch sehen

Wenn Sie einen älteren Audit, ein veraltetes Tutorial oder ein Legacy-Dashboard lesen, das noch „Time to Interactive“ auflistet, hier die Kurzfassung: Diese Metrik ist eingestellt. Google hat sie in Lighthouse 10, im Jahr 2023, aus dem Lighthouse-Performance-Score entfernt. PageSpeed Insights bewertet sie nicht mehr. Jeder Artikel, der Ihnen sagt, Sie sollen „Ihre TTI unter 3,8 Sekunden bringen“, zitiert eine Bewertungsspanne, die es nicht mehr gibt.

Die zwei Dinge, die Leute falsch verstehen

TTI war nie eine Core Web Vital. Die Core Web Vitals sind LCP, INP und CLS – TTI stand nie auf dieser Liste. Und TTI hat Ihre Google-Rankings nie beeinflusst, nicht einmal damals, als es noch in Lighthouse bewertet wurde. Es war immer eine diagnostische Zahl, kein Ranking-Signal.

Wenn also ein alter Bericht Ihre TTI markiert, müssen Sie nicht in Panik geraten oder ihr hinterherjagen. Das, was TTI messen wollte – ob Ihre Seite schnell auf echte Menschen reagiert – wird jetzt besser durch zwei andere Metriken gemessen: TBT im Labor und INP im Feld.

Möchten Sie die ganze Geschichte – wie TTI berechnet wurde, warum genau es entfernt wurde, wohin seine 10 % Gewichtung ging und warum ein Teil davon immer noch in einer anderen Metrik läuft? Wechseln Sie zum Erweitert-Tab.

TL;DR — TTI ist eine eingestellte Lighthouse-Labormetrik: Zeit vom Ladebeginn bis zu dem Punkt, an dem die wichtigsten Unterressourcen einer Seite geladen sind und sie zuverlässig auf Eingaben reagieren kann. Aus dem Lighthouse-Performance-Score in Lighthouse 10 (2023) entfernt, weil es zu empfindlich auf Ausreißer-Netzwerkanfragen und lange Tasks reagierte; seine 10 % Gewichtung wurde auf CLS (jetzt 25 %) übertragen. Es war nie eine Core Web Vital (diese sind LCP, INP, CLS) und nie ein Ranking-Faktor. Der Rohwert wird weiterhin im JSON-Output von Lighthouse berechnet (der interactive-Audit) mit Gewicht 0, verborgen im HTML-Bericht – Legacy-CI-Skripte funktionieren weiterhin. Und seine „Quiet-Window“-Logik definiert weiterhin, wo das Messfenster der Total Blocking Time endet (FCP → TTI). Bing veröffentlicht überhaupt keine TTI-Anleitung. Verwenden Sie stattdessen TBT (Labor) und INP (Feld).

Was TTI tatsächlich gemessen hat

Googles Definition von der web.dev-TTI-Seite ist präzise: „The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.“ (Übersetzung) „Die TTI-Metrik misst die Zeit vom Beginn des Seitenladens bis zu dem Punkt, an dem ihre wichtigsten Unterressourcen geladen sind und sie in der Lage ist, zuverlässig und schnell auf Benutzereingaben zu reagieren.“ (Quelle)

Das Problem, das es erfassen sollte, ist die Falle „sieht interaktiv aus, ist es aber nicht“. Techniken wie serverseitiges Rendering können eine Seite fertig aussehen lassen – Links und Schaltflächen auf dem Bildschirm dargestellt – bevor ihr JavaScript tatsächlich geladen ist, sodass diese Steuerelemente sichtbar, aber nicht funktionsfähig sind. TTI war die Zahl, die Ihnen sagte, wann die Seite aufhörte, den Benutzer zu belügen.

Die gleiche Falle tritt auch heute noch auf, mit oder ohne TTI: eine client-gerenderte Single-Page-App, die auf Hydration wartet, oder ein schweres Drittanbieter-Skript, das den Hauptthread nach dem ersten Paint blockiert – beides erzeugt dieselbe sichtbare, aber nicht funktionsfähige Lücke. Die Metrik, die sie maß, ist verschwunden; der zugrunde liegende Fehlermodus ist es nicht.

Das alte Lighthouse-Audit-Dokument beschrieb einen dreiteiligen Test für „vollständig interaktiv“: Die Seite zeigt nützliche Inhalte (gemessen am First Contentful Paint), Ereignishandler sind für die meisten sichtbaren Seitenelemente registriert, und die Seite reagiert innerhalb von 50 Millisekunden auf Benutzerinteraktionen. (Lighthouse-Audit-Dokument)

Wie TTI berechnet wurde (das „ruhige Fenster“)

Dies ist der Teil, der am wichtigsten ist, um zu verstehen, warum es entfernt wurde – und warum ein Teil davon überlebt. Lighthouse berechnete TTI in vier Schritten:

1. Beginnen Sie beim First Contentful Paint (FCP).
2. Suchen Sie vorwärts nach einem ruhigen Fenster von mindestens fünf Sekunden – definiert als keine langen Aufgaben und nicht mehr als zwei laufende Netzwerk-GET-Anfragen.
3. Suchen Sie rückwärts von diesem ruhigen Fenster nach der letzten langen Aufgabe davor, und stoppen Sie beim FCP, wenn es keine langen Aufgaben gab.
4. TTI ist die Endzeit dieser letzten langen Aufgabe vor dem ruhigen Fenster (oder der gleiche Wert wie FCP, wenn keine langen Aufgaben gefunden wurden).

Lesen Sie Schritt 2 noch einmal, denn darin liegt das ganze Problem. TTI hing davon ab, fünf Sekunden Ruhe zu finden. Das macht es fragil: Eine langsame, ausreißerische Netzwerkanfrage oder eine einzelne lange Aufgabe, die in der Nähe des Endes eines Seitenladevorgangs landet, kann das „ruhige Fenster“ um Sekunden verschieben – und TTI dramatisch schwanken lassen, ohne dass sich das Gefühl der Seite für den Benutzer wirklich ändert.

Ist TTI eine Core Web Vital? Nein – das war es nie

Direkte Antwort: Nein. Die drei Core Web Vitals sind LCP (Ladezeit), INP (Reaktionsfähigkeit) und CLS (visuelle Stabilität). TTI stammt aus der Zeit vor dieser Gruppe – die Core-Web-Vitals-Initiative startete im Mai 2020, und TTI existierte bereits lange zuvor als allgemeine Lighthouse-Metrik für „Lade-Reaktionsfähigkeit“. Es wurde nie in die Core Web Vitals aufgenommen und wurde vollständig aus Lighthouse entfernt, bevor die Core Web Vitals überhaupt die Chance hatten, es zu übernehmen. (Für die vollständige Taxonomie dessen, was eine Core Web Vital ist und nicht ist, siehe den Web Vitals Hub.)

Ist TTI noch in Lighthouse / PageSpeed Insights? Nein – entfernt in Lighthouse 10

TTI war von den frühen Versionen von Lighthouse bis Lighthouse 9 eine Metrik des Lighthouse-Leistungsscores und wurde dann in Lighthouse 10 (2023) entfernt. Die Versionshinweise zu Lighthouse 10 sind unmissverständlich, warum: „TTI markiert einen Zeitpunkt, aber die Art und Weise, wie es definiert ist, macht es übermäßig empfindlich gegenüber Ausreißer-Netzwerkanfragen und langen Aufgaben.“ (Quelle) Das ist die Fragilität des Fünf-Sekunden-Ruhefensters, die als offizieller Grund angegeben wird.

Die Entfernung war kein einzelner Schalter, der überall gleichzeitig umgelegt wurde: Sie wurde sofort in der npm-CLI und in Chrome Canary ausgeliefert, landete mit Chrome 112 in Chrome Stable und erreichte PageSpeed Insights einige Wochen später. Alle diese Fenster sind inzwischen seit Jahren geschlossen, sodass jede Oberfläche die Änderung heute widerspiegelt – aber es ist wissenswert, wenn Sie versuchen, einen alten Bericht zu datieren oder zu erklären, warum zwei Tools Anfang 2023 eine Zeit lang unterschiedlicher Meinung waren.

Zwei wichtige Konsequenzen der Entfernung:

• Sein 10 %-Gewicht wurde auf Cumulative Layout Shift übertragen. Der Anteil von CLS am Lighthouse-Leistungswert stieg auf 25 %. Die Entfernung von TTI ist also der Grund, warum CLS im Score stärker gewichtet wird, als Sie erwarten würden. (Es ging nicht an TBT – TBT behielt sein eigenes Gewicht.)
• Der Rohwert existiert weiterhin. Lighthouse berechnet TTI weiterhin intern: Es erscheint im JSON-Output als interactive-Audit mit Score-Gewicht 0, verborgen im HTML-Report. Googles eigener Hinweis lautet, dass der scriptbasierte Zugriff auf den JSON-Wert ohne Änderungen weiter funktionieren sollte. Wenn Sie also ein CI-Leistungsbudget haben, das an interactive im Lighthouse-JSON gekoppelt ist, bricht es nicht – Sie verfolgen jetzt nur noch eine unbewertete, ungewichtete Zahl. Das ist ein Praktiker-Detail, das fast kein Artikel über „Was ist TTI“ erwähnt, und es ist wissenswert, bevor Sie eine Assertion aus einer Pipeline entfernen, die noch läuft. Dieses JSON-Kompatibilitätsversprechen wurde in den Lighthouse-10-Release-Notes im Februar 2023 gegeben – ich habe die Release-Notes von Lighthouse bis zur aktuellen v13.4 geprüft und nichts gefunden, was es revidiert oder widerruft. Behandeln Sie es also als korrekt zum Zeitpunkt dieser Prüfung, nicht als dauerhafte Garantie.

Was TTI ersetzt hat

Googles TTI-Dokumentation ist explizit, was stattdessen verwendet werden soll: Neuere Metriken wie Largest Contentful Paint (LCP), Total Blocking Time (TBT) und Interaction to Next Paint (INP) sind in der Regel bessere Metriken, die anstelle von TTI verwendet werden sollten. (Quelle) Wenn man das darauf abbildet, was jede einzelne tut:

• LCP beantwortet die Frage „Ist es geladen?“ robuster als eine Zählung aktiver Netzwerkanfragen.
• TBT ist der Labor-Stellvertreter für Interaktivität – es behandelt lange Tasks und Main-Thread-Verfügbarkeit direkter und korreliert besser mit den Core Web Vitals.
• INP ist die tatsächliche Core Web Vital für Reaktionsfähigkeit, gemessen an realen Nutzerinteraktionen im Feld.

Keine dieser drei ist ein eins-zu-eins-Ersatz für TTI – web.dev nennt sie „usually better metrics to use in place of TTI“, nicht Äquivalente, und diese Formulierung ist wichtig. TTI versuchte, drei verschiedene Fragen mit einer einzigen unzuverlässigen Zahl zu beantworten: Ist die Seite visuell fertig (das ist jetzt LCPs Aufgabe), ist der Main-Thread während des Ladens blockiert (TBTs Aufgabe) und ist ein echter Tipp- oder Tastendruck eines Nutzers langsam (INPs Aufgabe). Leiten Sie Ihre Frage an die Metrik weiter, die dafür gebaut wurde, anstatt nach einem einzigen Drop-in-Ersatz zu suchen.

TTI vs. TBT – die Beziehung, die überlebt

Hier ist der interessante Teil: TTI ist aus Lighthouses Methodik nicht vollständig verschwunden. Seine Quiet-Window-Definition wird wiederverwendet, um zu definieren, wo das TBT-Messfenster endet. Total Blocking Time summiert den blockierenden Anteil (Zeit über 50 ms) jedes langen Tasks zwischen First Contentful Paint und TTI. Obwohl TTI also unbewertet ist, berechnet Lighthouse intern weiterhin einen TTI-äquivalenten Wert, nur um zu wissen, wann die Summierung von TBT aufhören soll. TTI markiert einen einzelnen Zeitpunkt; TBT summiert die blockierte Zeit bis zu diesem Punkt. Sie sind verwandt, messen aber nicht dasselbe – TBT hat effektiv TTI-Fenster geerbt, anstatt zu ersetzen, was TTI gemessen hat.

TTI vs. INP

TTI war eine reine Labor-Metrik für die Seitenladezeit. INP ist eine Core Web Vital, die aus realen Nutzerinteraktionen im Feld (über CrUX) gemessen wird, auf dem 75. Perzentil über Besuche hinweg berichtet wird, und es ist ein Google-Ranking-Signal. TTI war das nie. Wenn Ihnen Interaktivität für SEO wichtig ist, ist INP die Metrik, die zählt; TBT ist die Labor-Diagnose, die als Stellvertreter dient, wenn Sie keine echten Interaktionen messen können.

Beeinflusst TTI die SEO-Rankings? Nein

Keine offizielle Google-Ranking-Dokumentation hat TTI jemals als Ranking-Faktor bezeichnet – selbst bevor es aus Lighthouse entfernt wurde. Es war immer eine Labordiagnose, nie Teil von Page Experience. Bemerkenswert ist, dass TTI nie die „Ist das ein Ranking-Faktor“-Nachrichtenwelle auslöste, die Core Web Vitals auslösten – keine eigene Search Engine Roundtable-, Search Engine Land- oder Search Engine Journal-Kontroverse über TTI als Signal – gerade weil es immer offensichtlich eine reine Labordiagnose war.

Hier greift meine breitere Sicht auf Interaktivitätsmetriken, und sie greift stärker hier als fast überall sonst. Im Ahrefs Core Web Vitals- Leitfaden habe ich klar gesagt, dass ich nicht glaube, dass Core Web Vitals viel Einfluss auf SEO haben, und – sofern eine Website nicht extrem langsam ist – ich generell nicht priorisieren werde, sie zu beheben – und wenn Sie für Core Web Vitals-Verbesserungen argumentieren wollen, ist das ein schwer zu haltendes Argument allein aus SEO-Sicht. Wenn das für die Metriken gilt, die bestätigte Ranking-Signale sind, gilt es doppelt für TTI, das sowohl zurückgezogen als auch nie ein Ranking-Faktor war. Die Lehre aus TTI ist nicht „optimieren Sie diese Zahl“ – das können Sie buchstäblich nicht, sie wird nicht mehr bewertet. Es ist „jagen Sie keine veralteten, Metriken mit geringem ROI.“ Tun Sie Leistungsarbeit für Nutzer und Conversions und messen Sie sie mit den Metriken, die tatsächlich aktiv sind.

Verwendet Bing Time to Interactive? Nein

Es gibt keine offizielle Bing-Stellungnahme zu TTI, die man zitieren könnte, weil Bing überhaupt nicht über TTI spricht. Keine Bing Webmaster Tools-Dokumentation, kein Blogbeitrag und keine Hilfeseite verweist darauf. Als Bings eigenes Ingenieursteam beschrieb, wie es die Leistung der bing.com-Ergebnisseite misst (Driving Performance at Microsoft Bing), beschrieben sie selbst entwickelte Metriken der Rendering-Phase – First Render, First Results Render und Above Fold Render – und erwähnten nie TTI, TBT oder Googles Core Web Vitals-Vokabular. Das ist eine nützliche Lückenfüllung: Gehen Sie nicht davon aus, dass Bing Googles Lighthouse-Metrikstapel spiegelt. Das tut es nicht.

Legacy-TTI-Schwellenwerte (nur historische Referenz)

Wenn Sie einen alten Bericht interpretieren müssen, waren die mobilen Bewertungsbereiche vor Lighthouse-10: gut ≤ 3,8 s, mäßig 3,9–7,3 s, schlecht > 7,3 s, mit Googles allgemeiner Anleitung, eine Time to Interactive von unter 5 Sekunden auf durchschnittlicher mobiler Hardware anzustreben. Diese Bewertungstabelle wurde zuletzt 2019 offiziell aktualisiert. Behandeln Sie diese rein als historischen Kontext – es gibt keinen aktuellen bewerteten „gut“-Bereich, weil TTI heute null Gewicht in der Bewertung trägt.

Sollten Sie sich noch um TTI kümmern?

Die ehrliche Antwort hängt davon ab, wer Sie sind:

• Wenn Sie SEO oder Website-Besitzer sind: nein. Prüfen Sie nicht auf TTI, setzen Sie keine Ziele dafür, und lassen Sie sich von einem alten Bericht nicht erschrecken. Es wird nicht bewertet, es ist kein Core Web Vital, und es war nie ein Ranking-Faktor.
• Wenn Sie ein Entwickler mit einem Legacy-CI-Leistungsbudget sind: Ihr interactive- Wert im Lighthouse-JSON funktioniert weiterhin und bricht Ihre Pipeline nicht – aber er ist jetzt eine unbewertete Zahl. Erwägen Sie, diese Assertion auf TBT (Labor-Interaktivität) oder eine echte Core Web Vital umzurichten.
• Für alle: TTIs diagnostischer Instinkt – Seiten zu erkennen, die interaktiv aussehen, es aber nicht sind – ist nicht verschwunden. Er wird jetzt besser durch TBT im Labor und INP im Feld erfasst. Dort findet die eigentliche Action statt.

Für die Frage, wo TTI unter den zurückgezogenen Metriken steht und wie das gesamte Web Vitals-Programm organisiert ist, decken die Schwesterartikel dieses Artikels – Total Blocking Time, First Contentful Paint, Speed Index sowie die Lighthouse- und CrUX-Erklärungen – das angrenzende Gebiet ab, und der Web Performance-Cluster fügt es zusammen.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• TTI = eine zurückgezogene Lighthouse-Labormetrik. Sie markierte die Zeit vom Ladebeginn bis zu dem Punkt, an dem die wichtigsten Unterressourcen einer Seite geladen waren und sie zuverlässig auf Eingaben reagieren konnte.
• Aus dem Lighthouse-Performance-Score in Lighthouse 10 (2023) entfernt, weil sie “übermäßig empfindlich auf Ausreißer-Netzwerkanfragen und lange Tasks” reagierte. Ihr 10-%-Gewicht wurde auf CLS (jetzt 25 %) übertragen – nicht auf TBT.
• Nie eine Core Web Vital (das sind LCP, INP, CLS) und nie ein Google-Ranking-Faktor.
• Der Rohwert existiert weiterhin in der JSON-Ausgabe von Lighthouse (der interactive-Audit) mit Gewicht 0, versteckt im HTML-Report – damit alte CI-Budgets nicht brechen, sondern nur eine unbewertete Zahl verfolgen.
• Die “Quiet-Window”-Logik lebt in TBT weiter: TBT summiert die Blockierzeit langer Tasks zwischen FCP und TTI, sodass Lighthouse intern weiterhin ein TTI-Äquivalent berechnet.
• Berechnung: Start bei FCP → vorwärts nach einem 5-Sekunden-Quiet-Window suchen (keine langen Tasks, ≤ 2 laufende GET-Anfragen) → rückwärts nach dem letzten langen Task davor suchen → TTI = das Ende dieses letzten langen Tasks. Diese Abhängigkeit von 5 Sekunden Ruhe machte die Metrik volatil.
• Was stattdessen verwenden: LCP (Laden), TBT (Lab-Interaktivitätsproxy), INP (Feld-Interaktivität, die echte Core Web Vital) – kein 1:1-Ersatz, jede beantwortet eine andere Frage, die TTI zu einer einzigen unzuverlässigen Zahl vermischte.
• Bing hat keinerlei TTI-Anleitung; sein Engineering-Blog verwendet eigene Rendering-Phasen-Metriken (First Render, First Results Render, Above Fold Render).
• Legacy-Bereiche (nur historisch): gut ≤ 3,8 s, mittel 3,9–7,3 s, schlecht > 7,3 s (mobil, vor 2023) – nicht mehr bewertet.
• Patricks Einschätzung: Jagen Sie keiner veralteten, unbewerteten, nie gerankten Metrik hinterher – optimieren Sie für Nutzer und messen Sie Interaktivität mit TBT und INP.

Offizielle Dokumentation

Primärquellen-Dokumentation zu TTI und seinen Ersatzmetriken.

Google / web.dev / Chrome

• Time to Interactive (TTI) – die kanonische Definition, das Problem “sieht interaktiv aus, ist es aber nicht”, die Quiet-Window-Berechnung, der Entfernungsvermerk und die Empfehlung, stattdessen LCP/TBT/INP zu verwenden.
• Time to Interactive (Lighthouse-Audit-Dokumentation) – die Legacy-Audit-Seite mit dem dreiteiligen “vollständig interaktiv”-Test und der Bewertungstabelle vor 2023 (jetzt mit Warnhinweis).
• What’s new in Lighthouse 10 – die Entfernungsankündigung: warum TTI entfernt wurde, wohin sein 10-%-Gewicht ging (CLS), und der Hinweis, dass der Rohwert mit Gewicht 0 in der JSON-Ausgabe bleibt.
• Total Blocking Time (TBT) – die Metrik, deren Messfenster weiterhin bei TTI endet.
• Web Vitals – bestätigt die drei Core Web Vitals (LCP, INP, CLS); TTI gehört nicht dazu.
• Are long JavaScript tasks delaying your Time to Interactive? – Addy Osmani darüber, wie lange Tasks den Hauptthread blockieren und TTI aufblähen.

Bing / Microsoft (zum Vergleich – es gibt keine TTI-spezifische Anleitung)

• Driving Performance at Microsoft Bing – Bings eigene Website verwendet First Render / First Results Render / Above Fold Render, nicht die TTI- oder Core-Web-Vitals-Terminologie.

Zitate aus der Quelle

Öffentliche Aussagen von Googles Ingenieuren und aus der Dokumentation. Jeder Link ist ein Deep Link, der direkt zur zitierten Passage auf der Quellseite springt.

Google / web.dev – was TTI gemessen hat

• “The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.” (Übersetzung) „Die TTI-Metrik misst die Zeit vom Beginn des Seitenladens bis zu dem Punkt, an dem die wichtigsten Unterressourcen geladen sind und die Seite zuverlässig schnell auf Benutzereingaben reagieren kann.“ – web.dev, Philip Walton. Zum Zitat springen

Google – warum es entfernt wurde (Lighthouse 10)

• “TTI marks a point in time, but the way it’s defined makes it overly sensitive to outlier network requests and long tasks.” (Übersetzung) „TTI markiert einen Zeitpunkt, aber seine Definition macht es übermäßig empfindlich gegenüber Ausreißern bei Netzwerkanfragen und langen Aufgaben.“ — What’s new in Lighthouse 10. Zum Zitat springen

Google – was stattdessen verwenden

• “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (Übersetzung) „Neuere, alternative Metriken wie Largest Contentful Paint (LCP), Total Blocking Time (TBT) und Interaction to Next Paint (INP) sind in der Regel bessere Metriken, die anstelle von TTI verwendet werden sollten.“ — web.dev, Philip Walton. Zum Zitat springen

Addy Osmani, Google – lange Aufgaben und TTI

• “Long Tasks can greatly increase your Time to Interactive.” (Übersetzung) „Lange Aufgaben können Ihre Time to Interactive erheblich erhöhen.“ — web.dev, „Are long JavaScript tasks delaying your Time to Interactive?“ Artikel lesen

Altes Audit lesen, das TTI erwähnt – Checkliste

Ein schneller Durchlauf, wenn „Time to Interactive“ in einem Bericht, Tool oder CI-Skript auftaucht:

• Bestätigen Sie das Quellendatum – wenn es vor 2023 liegt, ist seine TTI-Darstellung vor der Entfernung und seine Scoring-Bänder sind veraltet.
• Behandeln Sie kein Band „gutes TTI ≤ 3,8 s“ als aktuell – Lighthouse bewertet TTI nicht mehr (0 % Gewicht seit Lighthouse 10).
• Melden Sie TTI nicht als Core Web Vital an einen Kunden – das war es nie.
• Melden Sie TTI nicht als Ranking-Faktor – das war es nie.
• Wenn es ein CI-Budget ist, das auf interactive im Lighthouse-JSON ausgerichtet ist: Es funktioniert weiterhin, aber es ist eine unbewertete Zahl – erwägen Sie, es auf TBT oder eine echte Core Web Vital umzurichten.
• Um Interaktivität tatsächlich zu diagnostizieren, schauen Sie stattdessen auf TBT (Labor) und INP (Feld).
• Wenn lange Aufgaben die Ursache sind, ist das derselbe Fix wie bei TBT/INP: Lange JS-Aufgaben aufteilen, Code-Splitting, ungenutztes JS verzögern oder entfernen und Kosten für Drittanbieter-Skripte senken.

TTI-Spickzettel

Status auf einen Blick

Wie es berechnet wurde (das ruhige Fenster)

1. Beginnen Sie bei First Contentful Paint (FCP).
2. Suchen Sie vorwärts nach einem ≥ 5-Sekunden-ruhigen Fenster (keine langen Aufgaben, ≤ 2 laufende GET-Anfragen).
3. Suchen Sie rückwärts nach der letzten langen Aufgabe vor diesem Fenster.
4. TTI = Ende dieser letzten langen Aufgabe (oder FCP, wenn keine). Die Abhängigkeit von 5 Sekunden Ruhe ist der Grund, warum es volatil war.

Legacy-Mobile-Schwellenwerte (nur historisch – nicht mehr bewertet)

• Gut: ≤ 3,8 s · Mittel: 3,9–7,3 s · Schlecht: > 7,3 s
• Googles alte allgemeine Richtlinie: unter 5 s auf durchschnittlicher mobiler Hardware.

Stattdessen verwenden

• Laden → LCP · Labor-Interaktivität → TBT · Feld-Interaktivität (die echte CWV) → INP

Fehler vermeiden bei Time to Interactive

TTI als Core Web Vital bezeichnen

TTI war nie eine Core Web Vital oder ein Search-Ranking-Eingang. Machen Sie kein altes Lighthouse-Label zu einer aktuellen SEO-Anforderung.

Einem ausgemusterten Lighthouse-Score hinterherjagen

Lighthouse 10 hat die Gewichtung des TTI-Scores entfernt, da die Metrik übermäßig empfindlich auf Ausreißeranfragen und lange Tasks reagierte. Verwenden Sie stattdessen TBT für die wiederholbare Labordiagnose und INP für die Responsiveness realer Nutzer.

Den rohen JSON-Wert als aktive Empfehlung behandeln

Die Legacy-Ausgabe kann einen TTI-Wert mit Gewicht null aus Kompatibilitätsgründen beibehalten. Seine Präsenz bedeutet nicht, dass Lighthouse ihn bewertet oder dass ein Team ein neues TTI-Ziel festlegen sollte.

TTI und INP vergleichen, als ob sie dasselbe Ereignis messen würden

TTI suchte während des Seitenladens nach einem ruhigen Fenster; INP misst tatsächliche Nutzerinteraktionen im Feld. Ordnen Sie alte TTI-Erkenntnisse dem zugrunde liegenden Problem mit langen Tasks oder dem Ladevorgang zu und messen Sie dieses Problem dann mit aktuellen Metriken.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• What Are Core Web Vitals (CWVs) & How To Improve Them — meine Einschätzung, wie viel (wenig) Core Web Vitals SEO bewegen, was auf eine ausgemusterte, nie rankende Metrik wie TTI noch stärker zutrifft.
• The Beginner’s Guide to Technical SEO — wo Page-Speed-Metriken im größeren Zusammenhang einzuordnen sind.

Meine Vorträge

• How Search Works (SlideShare) — meine Erläuterung von Crawling, Rendering, Indexierung und Ranking, als Kontext, in dem Page Speed lebt. (Mein üblicher Haftungsausschluss gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Dies ist mein Verständnis von Systemen … es wird nicht zu 100 % vollständig oder genau sein.“)

Aus der Branche

• Time to Interactive (TTI) (web.dev, Philip Walton) — die kanonische Definition, Berechnung, Entfernungsnotiz und Ersatzmetriken.
• What’s new in Lighthouse 10 (Chrome DevRel) — die offizielle Entfernungsankündigung und die Gewichtsverschiebung von CLS.
• Time to Interactive (Lighthouse audit doc) (Chrome) — die Legacy-Audit-Seite mit dem dreiteiligen Test für „vollständig interaktiv“.
• Are long JavaScript tasks delaying your Time to Interactive? (web.dev, Addy Osmani) — der Blickwinkel der langen Tasks hinter schlechtem TTI.
• Time to Interactive (DebugBear) — die beste technische Behandlung von Drittanbietern; stellt TTIs anhaltende Relevanz über TBT dar.
• Time to interactive (MDN Web Docs Glossary) — prägnant, wörterbuchartig; weist darauf hin, dass TTI nicht standardisiert ist.
• Driving Performance at Microsoft Bing (Microsoft Bing) — wie Bing seine eigene Website misst, mit eigenen Metriken statt TTI oder Core Web Vitals.

Statistiken, die sich zu zitieren lohnen

• TTIs 10 % Lighthouse-Gewicht wurde auf CLS übertragen (das nun 25 % trägt), als TTI in Lighthouse 10 (2023) entfernt wurde. Es wurde nicht auf TBT übertragen. Quelle
• Der rohe TTI-Wert wird weiterhin mit Score-Gewicht 0 berechnet, im HTML-Bericht verborgen, aber im Lighthouse-JSON-Output als interactive-Audit vorhanden — damit funktionieren Legacy-CI-Skripte weiterhin. Quelle
• Legacy-Mobile-Schwellenwerte (vor 2023, nicht mehr bewertet): gut ≤ 3,8 s, mittel 3,9–7,3 s, schlecht > 7,3 s; Googles altes allgemeines Ziel war unter 5 Sekunden auf durchschnittlicher Mobile-Hardware. Quelle
• TTIs Berechnung erfordert ein 5-Sekunden-„ruhiges Fenster“ (keine langen Tasks, ≤ 2 laufende GET-Anfragen) nach FCP — die Abhängigkeit, die es volatil machte und zu seiner Entfernung führte. Quelle

Testen Sie sich: Time to Interactive

Fünf kurze Fragen dazu, was TTI war, warum es entfernt wurde und was übrig bleibt. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Änderungsprotokoll