Time to Interactive (TTI)

TL;DR — Time to Interactive (TTI) measured how long it took a page to become reliably clickable — not just painted on screen, but actually able to respond when you tap or click. It used to be part of your Lighthouse scoreLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.. It isn’t anymore: Google removed it from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. in 2023 because the number bounced around too much. It was never a Core Web Vital, and it never affected your Google rankings.

What Time to Interactive was

A page can look finished before it actually is. The text is there, the buttons are visible — but if the JavaScript hasn’t finished loading and running yet, tapping a button does nothing, or lags for a second before anything happens. That gap between “looks ready” and “is ready” is exactly what TTI was built to catch.

TTI marked the moment a page had loaded its main sub-resources and could reliably respond to your input. Before that point, the page might be frozen even though it looked done.

Why you might still be seeing it

If you’re reading an older audit, an aging tutorial, or a legacy dashboard that still lists “Time to Interactive,” here’s the short version: that metric is retired. Google removed it from the Lighthouse Performance score in Lighthouse 10, back in 2023. PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. doesn’t score it anymore. Any article telling you to “get your TTI under 3.8 seconds” is quoting a scoring band that no longer exists.

The two things people get wrong

TTI was never a Core Web Vital. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — TTI was never on that list. And TTI never affected your Google rankings, not even back when it was still scored in Lighthouse. It was always a diagnostic number, not a ranking signal.

So if an old report is flagging your TTI, you don’t need to panic or chase it. The thing TTI was trying to measure — whether your page responds quickly to real people — is now measured better by two other metrics: TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. in the lab and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. in the field.

Want the full story — how TTI was calculated, exactly why it was removed, where its 10% weight went, and why a piece of it still runs inside another metric? Switch to the Advanced tab.

TL;DR — TTI is a retired LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab metric: time from load start to when a page’s main sub-resources have loaded and it can reliably respond to input. Removed from the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. Performance score in Lighthouse 10 (2023) for being too sensitive to outlier network requests and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions.; its 10% weight moved to CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (now 25%). It was never a Core Web Vital (those are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) and never a ranking factor. The raw value still computes in Lighthouse’s JSON output (the interactive audit) at weight 0, hidden from the HTML report — legacy CI scripts keep working. And its “quiet window” logic still defines where the Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. measurement window ends (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. → TTI). Bing publishes no TTI guidance at all. Use TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (lab) and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (field) instead.

What TTI actually measured

Google’s definition, from the web.dev TTI page, is precise: “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.” (source)

The problem it was designed to catch is the “looks interactive but isn’t” trap. Techniques like server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. can make a page look ready — links and buttons painted on screen — before its JavaScript has actually loaded, so those controls are visible but non-functional. TTI was the number that told you when the page stopped lying to the user.

The same trap still shows up today, TTI or no TTI: a client-rendered single-page app waiting on hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers., or a heavy third-party script tying up the main thread after the shell has painted, both produce the identical visible-but-not-functional gap. The metric that measured it is gone; the underlying failure mode isn’t.

The old Lighthouse audit doc spelled out a three-part test for “fully interactive”: the page displays useful content (measured by First Contentful Paint), event handlers are registered for most visible page elements, and the page responds to user interactions within 50 milliseconds. (Lighthouse audit doc)

How TTI was calculated (the “quiet window”)

This is the part that matters most for understanding why it was removed — and why a piece of it survives. Lighthouse computed TTI in four steps:

1. Start at First Contentful Paint (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.).
2. Search forward for a quiet window of at least five seconds — defined as no long tasks and no more than two in-flight network GET requests.
3. Search backward from that quiet window for the last long task before it, stopping at FCP if there were no long tasks.
4. TTI is the end time of that last long task before the quiet window (or the same value as FCP if no long tasks were foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.).

Read step 2 again, because it’s the whole problem. TTI depended on finding five seconds of quiet. That makes it fragile: one slow, outlier network request or a single long task landing near the tail of a page load can push the “quiet window” seconds later — swinging TTI dramatically without any real change in how the page felt to a user.

Is TTI a Core Web Vital? No — it never was

Direct answer: no. The three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (loading), INP (responsiveness), and CLS (visual stability). TTI predates that set — the Core Web Vitals initiative launched in May 2020, and TTI already existed as a general Lighthouse “load responsiveness” metric well before then. It was never folded into Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., and it was retired from Lighthouse entirely before Core Web Vitals had any chance to absorb it. (For the full taxonomy of what is and isn’t a Core Web Vital, see the Web Vitals hub.)

Is TTI still in Lighthouse / PageSpeed Insights? No — removed in Lighthouse 10

TTI was a Lighthouse Performance Score metric from Lighthouse’s early versions through Lighthouse 9, then removed in Lighthouse 10 (2023). The Lighthouse 10 release notes are blunt about why: “TTI marks a point in time, but the way it’s defined makes it overly sensitive to outlier network requests and long tasks.” (source) That’s the five-second-quiet-window fragility, stated as the official reason.

The removal wasn’t a single flip switched everywhere at once: it shipped immediately in the npm CLI and Chrome Canary, landed in Chrome Stable with Chrome 112, and reached PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. a few weeks after that. All of those windows closed years ago now, so every surface reflects the change today — but it’s worth knowing if you’re trying to date an old report or explain why two tools disagreed for a stretch in early 2023.

Two important consequences of the removal:

• Its 10% weight moved to Cumulative Layout Shift. CLS’s share of the Lighthouse Performance Score rose to 25%. So TTI’s removal is why CLS weighs more in the score than you might expect. (It did not go to TBT — TBT kept its own weight.)
• The raw value still exists. Lighthouse still computes TTI internally: it lives in the JSON output as the interactive audit, at score weight 0, hidden from the HTML report. Google’s own note is that scripted access of the JSON value should keep working without changes. So if you have a CI performance budget keyed to interactive in the Lighthouse JSON, it won’t break — you’re just tracking an unscored, unweighted number now. That’s a practitioner detail almost no “what is TTI” article mentions, and it’s worth knowing before you rip an assertion out of a pipeline that’s still passing. That JSON-compatibility promise was made in the Lighthouse 10 release notes back in February 2023 — I checked Lighthouse’s release notes through the current v13.4 and found nothing that revisits or revokes it, so treat it as accurate as of that check rather than a permanent guarantee.

What replaced TTI

Google’s TTI doc is explicit about what to use instead: newer 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. (source) Mapping that to what each one does:

• LCP covers the “is it loaded” question more robustly than a count of active network requests.
• TBT is the lab proxy for interactivity — it handles long tasks and main-thread availability more directly, and correlates better with the Core Web Vitals.
• INP is the actual Core Web Vital for responsiveness, measured from real user interactions in the field.

None of these three is a like-for-like TTI substitute — web.dev calls them “usually better metrics to use in place of TTI,” not equivalents, and that wording matters. TTI tried to answer three different questions with one flaky number: is the page visually done (that’s LCP’s job now), is the main thread blocked during load (TBT’s job), and is a real user’s tap or keypress slow (INP’s job). Route your question to the metric built for it instead of looking for a single drop-in replacement.

TTI vs. TBT — the relationship that survives

Here’s the interesting part: TTI isn’t fully gone from Lighthouse’s methodology. Its quiet-window definition is reused to define where the TBT measurement window ends. Total Blocking Time sums the blocking portion (time above 50 ms) of every long task between First Contentful Paint and TTI. So even though TTI is unscored, Lighthouse still calculates a TTI-equivalent value internally just to know when to stop summing TBT. TTI marks a single point in time; TBT sums the blocked time up to that point. They’re related, but they don’t measure the same thing — TBT effectively inherited TTI’s window rather than replacing what TTI measured.

TTI vs. INP

TTI was a lab-only, page-load-time metric. INP is a Core Web Vital measured from real user interactions in the field (via CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), reported at the 75th percentile across visits, and it is a Google ranking signal. TTI never was. If you care about interactivity for SEO, INP is the metric that matters; TBT is the lab diagnostic that stands in for it when you can’t measure real interactions.

Does TTI affect SEO rankings? No

No official Google ranking documentation has ever named TTI as a ranking factor — even before it was removed from Lighthouse. It was always a lab diagnostic, never part of Page Experience. Notably, TTI never generated the “is this a ranking factor” news cycle that Core Web Vitals did — no dedicated Search Engine Roundtable, Search Engine Land, or Search Engine Journal controversy over TTI as a signal — precisely because it was always, obviously, a lab-only diagnostic.

This is where my broader view on interactivity metrics applies, and it applies more strongly here than almost anywhere. In Ahrefs’ Core Web Vitals guide I’ve said plainly that I don’t think Core Web Vitals have much impact on SEO and, unless a site is extremely slow, I generally won’t prioritize fixing them — and if you want to argue for Core Web Vitals improvements, that’s a hard case to make on SEO grounds alone. If that’s true for the metrics that are confirmed ranking signals, it’s doubly true for TTI, which is both retired and was never a ranking factor. The lesson of TTI isn’t “optimize this number” — you literally can’t, it’s not scored anymore. It’s “don’t chase deprecated, low-ROI metrics.” Do performance work for users and conversions, and measure it with the metrics that are actually live.

Does Bing use Time to Interactive? No

There’s no Bing-official TTI stance to cite, because Bing doesn’t talk about TTI at all. No Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. documentation, blog post, or help page references it. When Bing’s own engineering team wrote up how it measures the performance of the bing.com results page (Driving Performance at Microsoft Bing), they described homegrown, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-phase metrics — First Render, First Results Render, and Above Fold Render — and never mentioned TTI, TBT, or Google’s Core Web Vitals vocabulary. That’s a useful gap-fill: don’t assume Bing mirrors Google’s Lighthouse metric stack. It doesn’t.

Legacy TTI thresholds (historical reference only)

If you need to interpret an old report, the pre-Lighthouse-10 mobile scoring bands were: good ≤ 3.8 s, moderate 3.9–7.3 s, poor > 7.3 s, with Google’s general guidance to aim for a Time to Interactive of under 5 seconds on average mobile hardware. That scoring table was last officially updated in 2019. Treat these purely as historical context — there is no current scored “good” band because TTI carries zero score weight today.

Should you still care about TTI?

The honest answer differs by who you are:

• If you’re an SEO or site owner: no. Don’t audit for TTI, don’t set targets for it, and don’t let an old report scare you. It’s not scored, it’s not a Core Web Vital, and it was never a ranking factor.
• If you’re a developer with a legacy CI performance budget: your interactive value in the Lighthouse JSON still works and won’t break your pipeline — but it’s now an unscored number. Consider re-pointing that assertion at TBT (lab interactivity) or a real Core Web Vital.
• For everyone: TTI’s diagnostic instinct — catching pages that look interactive but aren’t — didn’t disappear. It’s now better captured by TBT in the lab and INP in the field. That’s where the real action is.

For where TTI sits among the retired metrics and how the whole Web Vitals program is organized, this article’s siblings — Total Blocking Time, First Contentful Paint, Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor., and the Lighthouse and CrUX explainers — cover the neighboring ground, and the Web Performance cluster ties it together.

AI summary

A condensed take on the Advanced version:

• TTI = a retired LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab metric. It marked the time from load start to when a page’s main sub-resources had loaded and it could reliably respond to input.
• Removed from the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. Performance score in Lighthouse 10 (2023) for being “overly sensitive to outlier network requests and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions..” Its 10% weight moved to CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (now 25%) — not to TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital..
• Never a Core Web Vital (those are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) and never a Google ranking factor.
• The raw value still exists in Lighthouse’s JSON output (the interactive audit) at weight 0, hidden from the HTML report — so legacy CI budgets don’t break, they just track an unscored number.
• The “quiet window” logic survives inside TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.: TBT sums long-task blocking time between FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and TTI, so Lighthouse still computes a TTI-equivalent internally.
• Calculation: start at FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. → search forward for a 5-second quiet window (no long tasks, ≤ 2 in-flight GET requests) → search backward for the last long task before it → TTI = the end of that last long task. That dependence on 5 seconds of quiet is what made it volatile.
• What to use instead: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (loading), TBT (lab interactivity proxy), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (field interactivity, the real Core Web Vital) — not a one-for-one swap, each answers a different question TTI used to blend into one flaky number.
• Bing has no TTI guidance at all; its engineering blog uses homegrown renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-phase metrics (First Render, First Results Render, Above Fold Render).
• Legacy bands (historical only): good ≤ 3.8 s, moderate 3.9–7.3 s, poor > 7.3 s (mobile, pre-2023) — no longer scored.
• Patrick’s take: don’t chase a deprecated, unscored, never-ranking metric — optimize for users, and measure interactivity with TBT and INP.

Official documentation

Primary-source documentation on TTI and its replacements.

Google / web.dev / Chrome

• Time to Interactive (TTI) — the canonical definition, the “looks interactive but isn’t” problem, the quiet-window calculation, the removal note, and the recommendation to use LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. instead.
• Time to Interactive (Lighthouse audit doc) — the legacy audit page with the three-part “fully interactive” test and the pre-2023 scoring table (now carries a caution banner).
• What’s new in Lighthouse 10 — the removal announcement: why TTI was dropped, where its 10% weight went (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.), and the note that the raw value stays in the JSON output at weight 0.
• Total Blocking Time (TBT) — the metric whose measurement window still ends at TTI.
• Web Vitals — confirms the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.); TTI is not among them.
• Are long JavaScript tasks delaying your Time to Interactive? — Addy Osmani on how long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. tie up the main thread and inflate TTI.

Bing / Microsoft (for contrast — no TTI-specific guidance exists)

• Driving Performance at Microsoft Bing — Bing’s own site uses First Render / First Results Render / Above Fold Render, not TTI or Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. vocabulary.

Quotes from the source

On-the-record statements from Google’s engineers and docs. Each link is a deep link that jumps to the quoted passage on the source page.

Google / web.dev — what TTI measured

• “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 — why it was removed (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10)

• “TTI marks a point in time, but the way it’s defined makes it overly sensitive to outlier network requests and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions..” — What’s new in LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10. Jump to quote

Google — what to use instead

• “Newer, alternative, metrics like Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.), Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.), and Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) 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?” Read the article

Reading an old audit that mentions TTI — checklist

A quick pass for when “Time to Interactive” shows up in a report, tool, or CI script:

• Confirm the source date — if it predates 2023, its TTI framing is pre-removal and its scoring bands are stale.
• Don’t treat any “good TTI ≤ 3.8 s” band as current — LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. no longer scores TTI (0% weight since LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10).
• Don’t report TTI to a client as a Core Web Vital — it never was one.
• Don’t report TTI as a ranking factor — it never was one.
• If it’s a CI budget keyed to interactive in the Lighthouse JSON: it still works, but it’s an unscored number — consider re-pointing it at TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. or a real Core Web Vital.
• To actually diagnose interactivity, look at TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (lab) and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (field) instead.
• If long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. are the culprit, that’s the same fix as TBT/INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.: break up long JS tasks, code-split, defer or remove unused JS, and cut third-party script cost.

TTI cheat sheet

Status at a glance

How it was calculated (the quiet window)

1. Start at First Contentful Paint (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.).
2. Search forward for a ≥ 5-second quiet window (no long tasksAny main-thread task over 50 ms — the primary cause of INP regressions., ≤ 2 in-flight GET requests).
3. Search backward for the last long task before that window.
4. TTI = end of that last long task (or FCP if none). The 5-second-quiet dependence is why it was volatile.

Legacy mobile thresholds (historical only — no longer scored)

• Good: ≤ 3.8 s · Moderate: 3.9–7.3 s · Poor: > 7.3 s
• Google’s old general guidance: under 5 s on average mobile hardware.

Use instead

• Loading → LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. · Lab interactivity → TBT · Field interactivity (the real CWV) → INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.

Mistakes to avoid with Time to Interactive

Calling TTI a Core Web Vital

TTI was never a Core Web Vital or a Search ranking input. Do not turn an old LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. label into a current SEO requirement.

Chasing a retired Lighthouse score

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 removed TTI’s score weight because the metric was overly sensitive to outlier requests and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions.. Use TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. for repeatable lab diagnosis and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. for real-user responsiveness instead.

Treating the raw JSON value as an active recommendation

Legacy output may retain a weight-zero TTI value for compatibility. Its presence does not mean Lighthouse scores it or that a team should set a new TTI target.

Comparing TTI and INP as if they measured the same event

TTI searched for a quiet window during page load; INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. measures actual user interactions in the field. Map old TTI findings to the underlying long-task or loading problem, then measure that problem with current metrics.

Resources worth your time

My related writing

• What Are Core Web Vitals (CWVs) & How To Improve Them — my take on how much (little) Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. move SEO, which applies even more strongly to a retired, never-ranking metric like TTI.
• The Beginner’s Guide to Technical SEO — where page-speed metrics fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, for the context page speed lives inside. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Time to Interactive (TTI) (web.dev, Philip Walton) — the canonical definition, calculation, removal note, and replacements.
• What’s new in Lighthouse 10 (Chrome DevRel) — the official removal announcement and the CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. weight shift.
• Time to Interactive (Lighthouse audit doc) (Chrome) — the legacy audit page with the three-part “fully interactive” test.
• Are long JavaScript tasks delaying your Time to Interactive? (web.dev, Addy Osmani) — the long-tasks angle behind poor TTI.
• Time to Interactive (DebugBear) — the best third-party technical treatment; frames TTI’s ongoing relevance through TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital..
• Time to interactive (MDN Web Docs Glossary) — concise, dictionary-style; notes TTI is non-standardized.
• Driving Performance at Microsoft Bing (Microsoft Bing) — how Bing measures its own site, using homegrown metrics rather than TTI or Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..

Stats worth citing

• TTI’s 10% LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. weight moved to CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (which now carries 25%) when TTI was removed in LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 (2023). It did not move to TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.. Source
• The raw TTI value still computes at score weight 0, hidden from the HTML report but present in the Lighthouse JSON output as the interactive audit — so legacy CI scripts keep working. Source
• Legacy mobile thresholds (pre-2023, no longer scored): good ≤ 3.8 s, moderate 3.9–7.3 s, poor > 7.3 s; Google’s old general target was under 5 seconds on average mobile hardware. Source
• TTI’s calculation requires a 5-second “quiet window” (no long tasksAny main-thread task over 50 ms — the primary cause of INP regressions., ≤ 2 in-flight GET requests) after FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. — the dependence that made it volatile and got it removed. Source

Test yourself: Time to Interactive

Five quick questions on what TTI was, why it’s gone, and what survives. Pick an answer for each, then check.

Time to Interactive (TTI)

Time to Interactive — a retired Lighthouse lab metric marking the point a page's main sub-resources have loaded and it can reliably respond to input. It was removed from the Lighthouse Performance score in Lighthouse 10 (2023) for being too volatile, was never a Core Web Vital, and still defines the end of the Total Blocking Time measurement window.

Related: TBT, Lighthouse, FCP

Time to Interactive (TTI)

Time to Interactive (TTI) measures the time from when a page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly. It was built to catch one specific failure: a page that looks ready — content painted, buttons visible — but isn’t, because the JavaScript hasn’t finished loading and executing, so clicks do nothing or lag.

TTI is a lab-only metric. You only ever got it from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.; it was never field-measured, never in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., and never in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. It is not, and never was, a Core Web Vital — the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. It was also never a Google ranking factor.

TTI was a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. Performance Score metric through Lighthouse 9, then removed in Lighthouse 10 (2023) because it proved overly sensitive to outlier network requests and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions., producing high variability. Its 10% score weight shifted to Cumulative Layout Shift (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.), which now carries 25%. The raw value still computes in Lighthouse’s JSON output (the interactive audit) at score weight 0, hidden from the HTML report, so legacy CI scripts that read it don’t break — they’re just tracking an unscored number.

TTI isn’t fully gone from Lighthouse’s methodology, though. Its “quiet window” logic still defines where the Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.) measurement window ends: TBT sums the blocking portion of every long task between First Contentful Paint and TTI. That’s TTI’s real legacy — the ghost of it lives on inside TBT’s math. To measure interactivity today, use TBT in the lab and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. in the field.

Related: TBT, Lighthouse, FCP

Changelog