Temps d’interactivité (TTI)

TL;DR — Temps d’interactivité (TTI) mesuré how long it took une page to become reliably clickable — pas simplement painted on screen, but en réalité able to respond quand vous tap or click. It utilisé to be partie of votre Lighthouse score. It isn’t anymore: Google supprimé it from Lighthouse in 2023 parce que the number bounced autour aussi beaucoup. It was jamais a Core Web Vital, and it jamais affected votre Google rankings.

Ce que Temps d’interactivité was

Une page peut regarder finished avant it en réalité is. The text is là, the buttons are visible — but si the JavaScript hasn’t finished chargement and running yet, tapping a button ne fait pashing, or lags pour a second avant anything se produit. Que gap entre “looks ready” and “is ready” is exactly ce que TTI was construit to catch.

TTI marked the moment une page had chargé its principal sub-resources and pourrait reliably respond to votre input. Avant que point, lune page pourrait be frozen même though it looked fait.

Pourquoi vous pourrait encore be seeing it

Si you’re reading an older audit, an aging tutorial, or a legacy dashboard que encore listes “Time to Interactive,” here’s La version courte: que metric is retired. Google supprimé it from the Lighthouse Performances score in Lighthouse 10, back in 2023. PageSpeed Insights doesn’t score it anymore. Quelconque article telling vous to “get your TTI under 3.8 seconds” is quoting a scoring band que ne … plus exists.

The two choses personnes obtenir incorrect

TTI was jamais a Core Web Vital. The Core Web Vitals are LCP, INP, and CLS — TTI was jamais on que liste. And TTI jamais affected votre Google rankings, pas même back quand it was encore scored in Lighthouse. It was toujours a diagnostic number, pas a ranking signal.

So si an old report is flagging votre TTI, vous don’t besoin to panic or chase it. The chose TTI was trying to mesurer — si votre page responds quickly to réel personnes — is now mesuré meilleur by two autre metrics: TBT in the lab and INP in the field.

Vouloir the complet story — how TTI was calculated, exactly pourquoi it was supprimé, où its 10% weight went, and pourquoi a piece of it encore runs à l’intérieur un autre metric? Switch to the Avancé tab.

TL;DR — TTI is a retired Lighthouse lab metric: temps from charger commencer to quand une page’s principal sub-resources have chargé and it peut reliably respond to input. Supprimé from the Lighthouse Performances score in Lighthouse 10 (2023) pour being aussi sensitive to outlier network requêtes and long tasks; its 10% weight déplacé to CLS (now 25%). It was jamais a Core Web Vital (ceux are LCP, INP, CLS) and jamais a ranking factor. The raw valeur encore computes in Lighthouse’s JSON output (the interactive audit) at weight 0, hidden from the HTML report — legacy CI scripts garder working. And its “quiet window” logic encore defines où the Total Blocking Temps measurement window ends (FCP → TTI). Bing publishes aucun TTI guidance at tout. Utiliser TBT (lab) and INP (field) à la place.

Ce que TTI en réalité mesuré

Google’s definition, from the web.dev TTI page, is precise: “The TTI metric measures the temps from quand lune page starts chargement to quand its principal sub-resources have chargé and it is capable of reliably responding to utilisateur input quickly.” (source)

The problem it was designed to catch is the “looks interactive but isn’t” trap. Techniques comme rendu côté serveur peut faire une page regarder ready — liens and buttons painted on screen — avant its JavaScript has en réalité chargé, so ceux contrôle are visible but non-functional. TTI was the number que told vous quand lune page stopped lying to the utilisateur.

The même trap encore montre up today, TTI or aucun TTI: a client-rendered single-page app waiting on hydration, or a heavy third-party script tying up the principal thread après the shell has painted, les deux produce the identical visible-but-not-functional gap. The metric que mesuré it is gone; the underlying échec mode isn’t.

The old Lighthouse audit doc spelled out a three-part tester pour “fully interactive”: lune page displays utile content (mesuré by Premier affichage de contenu), event handlers are registered pour la plupart visible page elements, and lune page responds to utilisateur interactions dans 50 milliseconds. (Lighthouse audit doc)

How TTI was calculated (the “quiet window”)

Ce is the partie que matters la plupart pour understanding pourquoi it was supprimé — and pourquoi a piece of it survives. Lighthouse computed TTI in four steps:

1. Commencer at Premier affichage de contenu (FCP).
2. Search forward pour a quiet window of au moins five seconds — défini as aucun long tasks and aucun plus que two in-flight network OBTENIR requêtes.
3. Search backward from que quiet window pour the dernier long task avant it, stopping at FCP si là were aucun long tasks.
4. TTI is the fin temps of que dernier long task avant the quiet window (or the même valeur as FCP si aucun long tasks were trouvé).

Lire step 2 à nouveau, parce que it’s the whole problem. TTI depended on finding five seconds of quiet. Que rend it fragile: un slow, outlier network requête or a unique long task landing near the tail of une page charger peut push the “quiet window” seconds plus tard — swinging TTI dramatically sans quelconque réel modifier in how lune page felt to a utilisateur.

Is TTI a Core Web Vital? Aucun — it jamais was

Direct réponse: aucun. The three Core Web Vitals are LCP (chargement), INP (responsiveness), and CLS (visual stability). TTI predates que définir — the Core Web Vitals initiative launched in May 2020, and TTI déjà existed as a general Lighthouse “load responsiveness” metric bien avant alors. It was jamais folded into Core Web Vitals, and it was retired from Lighthouse entirely avant Core Web Vitals had quelconque chance to absorb it. (Pour the complet taxonomy of ce que is and isn’t a Core Web Vital, voir the Web Vitals hub.)

Is TTI encore in Lighthouse / PageSpeed Insights? Aucun — supprimé in Lighthouse 10

TTI was a Lighthouse Performances Score metric from Lighthouse’s early versions via Lighthouse 9, alors supprimé in Lighthouse 10 (2023). The Lighthouse 10 release notes are blunt à propos de pourquoi: “TTI marks a point in temps, but the façon it’s défini rend it overly sensitive to outlier network requêtes and long tasks.” (source) That’s the five-second-quiet-window fragility, stated as the official raison.

The removal wasn’t a unique flip switched everywhere at une fois: it shipped immédiatement in the npm CLI and Chrome Canary, landed in Chrome Stable with Chrome 112, and reached PageSpeed Insights a few weeks après que. Tout of ceux windows closed années ago now, so every surface reflects the modifier today — but it’s worth knowing si you’re trying to date an old report or expliquer pourquoi two outils disagreed pour a stretch in early 2023.

Two important consequences of the removal:

• Its 10% weight déplacé to Décalage cumulatif de mise en page. CLS’s share of the Lighthouse Performances Score rose to 25%. So TTI’s removal is pourquoi CLS weighs plus in the score que vous pourrait expect. (It did pas go to TBT — TBT kept its propre weight.)
• The raw valeur encore exists. Lighthouse encore computes TTI internally: it lives in the JSON output as the interactive audit, at score weight 0, hidden from the HTML report. Google’s propre remarque is que scripted accès of the JSON valeur devrait garder working sans changements. So si vous have a CI performances budget keyed to interactive in the Lighthouse JSON, it won’t break — you’re simplement tracking an unscored, unweighted number now. That’s a practitioner detail almost aucun “ce que is TTI” article mentions, and it’s worth knowing avant vous rip an assertion out of a pipeline that’s encore passing. Que JSON-compatibility promise was made in the Lighthouse 10 release notes back in February 2023 — I vérifié Lighthouse’s release notes via the current v13.4 and trouvé nothing que revisits or revokes it, so treat it as accurate as of que vérifier plutôt que a permanent guarantee.

Ce que replaced TTI

Google’s TTI doc is explicit à propos de ce que to utiliser à la place: newer metrics comme Largest Contentful Paint (LCP), Total Blocking Temps (TBT), and Interaction jusqu’au prochain affichage (INP) are usually meilleur metrics to utiliser in placer of TTI. (source) Mapping que to ce que chaque un fait:

• LCP covers the “is it loaded” question plus robustly que a count of active network requêtes.
• TBT is the lab proxy pour interactivity — it handles long tasks and main-thread availability plus directement, and correlates meilleur with the Core Web Vitals.
• INP is the réel Core Web Vital pour responsiveness, mesuré from réel utilisateur interactions in the field.

None of ces three is a like-for-like TTI substitute — web.dev calls les “usually meilleur metrics to utiliser in placer of TTI,” pas equivalents, and que wording matters. TTI tried to réponse three différent questions with un flaky number: is lune page visually fait (that’s LCP’s job now), is the principal thread blocked during charger (TBT’s job), and is a réel user’s tap or keypress slow (INP’s job). Route votre question to the metric construit pour it au lieu de looking pour a unique drop-in replacement.

TTI vs. TBT — the relationship que survives

Here’s the interesting partie: TTI isn’t entièrement gone from Lighthouse’s methodology. Its quiet-window definition is reused to define où the TBT measurement window ends. Total Blocking Temps sums the blocking portion (temps ci-dessus 50 ms) of every long task entre Premier affichage de contenu and TTI. So même though TTI is unscored, Lighthouse encore calculates a TTI-equivalent valeur internally simplement to know quand to arrêter summing TBT. TTI marks a unique point in temps; TBT sums the blocked temps up to que point. They’re connexe, but ils don’t mesurer the même chose — TBT effectively inherited TTI’s window plutôt que replacing ce que TTI mesuré.

TTI vs. INP

TTI was a lab-only, page-load-time metric. INP is a Core Web Vital mesuré from réel utilisateur interactions in the field (via CrUX), reported at the 75th percentile à travers visits, and it is a Google ranking signal. TTI jamais was. Si vous care à propos de interactivity pour le SEO, INP is the metric que matters; TBT is the lab diagnostic que stands in pour it quand vous pouvez’t mesurer réel interactions.

Fait TTI affecter SEO rankings? Aucun

Aucun official Google ranking documentation has ever named TTI as a ranking factor — même avant it was supprimé from Lighthouse. It was toujours a lab diagnostic, jamais partie of Page Experience. Notably, TTI jamais generated the “is this a ranking factor” news cycle que Core Web Vitals did — aucun dedicated Moteur de recherche Roundtable, Moteur de recherche Land, or Moteur de recherche Journal controversy over TTI as a signal — precisely parce que it was toujours, obviously, a lab-only diagnostic.

Ce is où my broader view on interactivity metrics s’applique, and it s’applique plus strongly ici que almost anywhere. In Ahrefs’ Core Web Vitals guide I’ve said plainly que I don’t think Core Web Vitals have beaucoup impact on SEO and, unless a site is extremely slow, I généralement won’t prioritize fixing les — and si vous vouloir to argue pour Core Web Vitals improvements, that’s a hard cas to faire on SEO grounds alone. Si that’s vrai pour the metrics que are confirmed ranking signals, it’s doubly vrai pour TTI, qui is les deux retired and was jamais a ranking factor. The lesson of TTI isn’t “optimize ce number” — you literally can’t, it’s not scored anymore. It’s “don’t chase deprecated, low-ROI metrics.” Do performances fonctionner pour utilisateurs and conversions, and mesurer it with the metrics que are en réalité live.

Fait Bing utiliser Temps d’interactivité? Aucun

There’s aucun Bing-official TTI stance to cite, parce que Bing doesn’t talk à propos de TTI at tout. Aucun Bing Webmaster Outils documentation, blog post, or aider page références it. Quand Bing’s propre engineering team wrote up how it measures the performances of the bing.com results page (Driving Performances at Microsoft Bing), ils décrit homegrown, rendering-phase metrics — Premier Render, Premier Results Render, and Ci-dessus Fold Render — and jamais mentioned TTI, TBT, or Google’s Core Web Vitals vocabulary. That’s a utile gap-fill: don’t assume Bing mirrors Google’s Lighthouse metric stack. It doesn’t.

Legacy TTI thresholds (historical référence seulement)

Si vous devez interpret an old report, the pre-Lighthouse-10 mobile scoring bands were: bon ≤ 3,8 s, moderate 3,9–7,3 s, poor > 7,3 s, with Google’s general guidance to aim pour a Temps d’interactivité of sous 5 seconds on average mobile hardware. Que scoring table was dernier officially mis à jour in 2019. Treat ces purely as historical context — là is aucun current scored “good” band parce que TTI carries zero score weight today.

Devrait vous encore care à propos de TTI?

The honest réponse differs by who vous are:

• Si you’re an SEO or site owner: aucun. Don’t audit pour TTI, don’t définir targets pour it, and don’t let an old report scare vous. It’s pas scored, it’s pas a Core Web Vital, and it was jamais a ranking factor.
• Si you’re a developer with a legacy CI performances budget: votre interactive valeur in the Lighthouse JSON encore fonctionne and won’t break votre pipeline — but it’s now an unscored number. Considérer re-pointing que assertion at TBT (lab interactivity) or a réel Core Web Vital.
• Pour everyone: TTI’s diagnostic instinct — catching pages que regarder interactive but aren’t — didn’t disappear. It’s now meilleur captured by TBT in the lab and INP in the field. That’s où the réel action is.

Pour où TTI sits among the retired metrics and how the whole Web Vitals program is organized, ce article’s siblings — Total Blocking Temps, Premier affichage de contenu, Speed Index, and the Lighthouse and CrUX explainers — cover the neighboring ground, and the Web Performances cluster ties it ensemble.

AI summary

A condensed prendre on the Avancé version:

• TTI = a retired Lighthouse lab metric. It marked the temps from charger commencer to quand une page’s principal sub-resources had chargé and it pourrait reliably respond to input.
• Supprimé from the Lighthouse Performances score in Lighthouse 10 (2023) pour being “overly sensitive to outlier network requests and long tasks.” Its 10% weight déplacé to CLS (now 25%) — pas to TBT.
• Jamais a Core Web Vital (ceux are LCP, INP, CLS) and jamais a Google ranking factor.
• The raw valeur encore exists in Lighthouse’s JSON output (the interactive audit) at weight 0, hidden from the HTML report — so legacy CI budgets don’t break, ils simplement track an unscored number.
• The “quiet window” logic survives à l’intérieur TBT: TBT sums long-task blocking temps entre FCP and TTI, so Lighthouse encore computes a TTI-equivalent internally.
• Calculation: commencer at FCP → search forward pour a 5-second quiet window (aucun long tasks, ≤ 2 in-flight OBTENIR requêtes) → search backward pour the dernier long task avant it → TTI = the fin of que dernier long task. Que dependence on 5 seconds of quiet is ce que made it volatile.
• Ce que to utiliser à la place: LCP (chargement), TBT (lab interactivity proxy), INP (field interactivity, the réel Core Web Vital) — pas a one-for-one swap, chaque réponses a différent question TTI utilisé to blend into un flaky number.
• Bing has aucun TTI guidance at tout; its engineering blog uses homegrown rendering-phase metrics (Premier Render, Premier Results Render, Ci-dessus Fold Render).
• Legacy bands (historical seulement): bon ≤ 3,8 s, moderate 3,9–7,3 s, poor > 7,3 s (mobile, pre-2023) — ne … plus scored.
• Patrick’s prendre: don’t chase a deprecated, unscored, never-ranking metric — optimize pour utilisateurs, and mesurer interactivity with TBT and INP.

Documentation officielle

Primary-source documentation on TTI and its replacements.

Google / web.dev / Chrome

• Temps d’interactivité (TTI) — the canonical definition, the “looks interactive but isn’t” problem, the quiet-window calculation, the removal remarque, and the recommendation to utiliser LCP/TBT/INP à la place.
• Temps d’interactivité (Lighthouse audit doc) — the legacy audit page with the three-part “fully interactive” tester and the pre-2023 scoring table (now carries a caution banner).
• What’s nouveau in Lighthouse 10 — the removal announcement: pourquoi TTI was dropped, où its 10% weight went (CLS), and the remarque que the raw valeur stays in the JSON output at weight 0.
• Total Blocking Temps (TBT) — the metric whose measurement window encore ends at TTI.
• Web Vitals — confirms the three Core Web Vitals (LCP, INP, CLS); TTI n’est pas among les.
• Are long JavaScript tasks delaying votre Temps d’interactivité? — Addy Osmani on how long tasks tie up the principal thread and inflate TTI.

Bing / Microsoft (pour contrast — aucun TTI-specific guidance exists)

• Driving Performances at Microsoft Bing — Bing’s propre site uses Premier Render / Premier Results Render / Ci-dessus Fold Render, pas TTI or Core Web Vitals vocabulary.

Quotes from the source

On-the-record statements from Google’s engineers and docs. Chaque lien is a deep lien que jumps to the quoted passage on the source page.

Google / web.dev — ce que TTI mesuré

• “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.” — web.dev, Philip Walton. Jump to quote

Google — pourquoi it was supprimé (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.” — What’s nouveau in Lighthouse 10. Jump to quote

Google — ce que to utiliser à la place

• “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.” — web.dev, Philip Walton. Jump to quote

Addy Osmani, Google — long tasks and TTI

• “Long Tasks can greatly increase your Time to Interactive.” — web.dev, “Are long JavaScript tasks delaying your Time to Interactive?” Lire the article

Reading an old audit que mentions TTI — checklist

A rapide réussir pour quand “Time to Interactive” montre up in a report, outil, or CI script:

• Confirmer the source date — si it predates 2023, its TTI framing is pre-removal and its scoring bands are stale.
• Don’t treat quelconque “good TTI ≤ 3.8 s” band as current — Lighthouse ne … plus scores TTI (0% weight since Lighthouse 10).
• Don’t report TTI to a client as a Core Web Vital — it jamais was un.
• Don’t report TTI as a ranking factor — it jamais was un.
• Si it’s a CI budget keyed to interactive in the Lighthouse JSON: it encore fonctionne, but it’s an unscored number — considérer re-pointing it at TBT or a réel Core Web Vital.
• To en réalité diagnose interactivity, regarder at TBT (lab) and INP (field) à la place.
• Si long tasks are the culprit, that’s the même fix as TBT/INP: break up long JS tasks, code-split, defer or supprimer unused JS, and cut third-party script cost.

TTI cheat sheet

Status En un coup d’œil

How it was calculated (the quiet window)

1. Commencer at Premier affichage de contenu (FCP).
2. Search forward pour a ≥ 5-second quiet window (aucun long tasks, ≤ 2 in-flight OBTENIR requêtes).
3. Search backward pour the dernier long task avant que window.
4. TTI = fin of que dernier long task (or FCP si none). The 5-second-quiet dependence is pourquoi it was volatile.

Legacy mobile thresholds (historical seulement — ne … plus scored)

• Bon: ≤ 3,8 s · Moderate: 3,9–7,3 s · Poor: > 7,3 s
• Google’s old general guidance: sous 5 s on average mobile hardware.

Utiliser à la place

• Chargement → LCP · Lab interactivity → TBT · Field interactivity (the réel CWV) → INP

Mistakes to éviter with Temps d’interactivité

Appel TTI a Core Web Vital

TTI was jamais a Core Web Vital or a Search ranking input. Ne faites pas turn an old Lighthouse étiquette into a current SEO requirement.

Chasing a retired Lighthouse score

Lighthouse 10 supprimé TTI’s score weight parce que the metric was overly sensitive to outlier requêtes and long tasks. Utiliser TBT pour repeatable lab diagnosis and INP pour real-user responsiveness à la place.

Treating the raw JSON valeur as an active recommendation

Legacy output may retain a weight-zero TTI valeur pour compatibility. Its presence fait pas mean Lighthouse scores it or que a team devrait définir a nouveau TTI target.

Comparing TTI and INP as si ils mesuré the même event

TTI searched pour a quiet window during page charger; INP measures réel utilisateur interactions in the field. Map old TTI findings to the underlying long-task or chargement problem, alors mesurer que problem with current metrics.

Ressources utiles

My connexe writing

• Ce que Are Core Web Vitals (CWVs) & How To Améliorer Les — my prendre on how beaucoup (little) Core Web Vitals déplacer SEO, qui s’applique même plus strongly to a retired, never-ranking metric comme TTI.
• The Beginner’s Guide to SEO technique — où page-speed metrics fit in the bigger picture.

My speaking

• How Search Fonctionne (SlideShare) — my walkthrough of exploration, rendering, indexation, and ranking, pour the context vitesse de page lives à l’intérieur. (My standing disclaimer s’applique: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From autour the industry

• Temps d’interactivité (TTI) (web.dev, Philip Walton) — the canonical definition, calculation, removal remarque, and replacements.
• What’s nouveau in Lighthouse 10 (Chrome DevRel) — the official removal announcement and the CLS weight shift.
• Temps d’interactivité (Lighthouse audit doc) (Chrome) — the legacy audit page with the three-part “fully interactive” tester.
• Are long JavaScript tasks delaying votre Temps d’interactivité? (web.dev, Addy Osmani) — the long-tasks angle behind poor TTI.
• Temps d’interactivité (DebugBear) — the meilleur third-party technical treatment; frames TTI’s ongoing relevance via TBT.
• Temps d’interactivité (MDN Web Docs Glossary) — concise, dictionary-style; notes TTI is non-standardized.
• Driving Performances at Microsoft Bing (Microsoft Bing) — how Bing measures its propre site, en utilisant homegrown metrics plutôt que TTI or Core Web Vitals.

Stats worth citing

• TTI’s 10% Lighthouse weight déplacé to CLS (qui now carries 25%) quand TTI was supprimé in Lighthouse 10 (2023). It did pas déplacer to TBT. Source
• The raw TTI valeur encore computes at score weight 0, hidden from the HTML report but présent in the Lighthouse JSON output as the interactive audit — so legacy CI scripts garder working. Source
• Legacy mobile thresholds (pre-2023, ne … plus scored): bon ≤ 3,8 s, moderate 3,9–7,3 s, poor > 7,3 s; Google’s old general target was sous 5 seconds on average mobile hardware. Source
• TTI’s calculation exige a 5-second “quiet window” (aucun long tasks, ≤ 2 in-flight OBTENIR requêtes) après FCP — the dependence que made it volatile and got it supprimé. Source

Testez vos connaissances: Temps d’interactivité

Five rapide questions on ce que TTI was, pourquoi it’s gone, and ce que survives. Pick an réponse pour chaque, alors vérifier.

Journal des modifications