Bringing back TTI to lighthouse until there is a better metric for measuring load-time interactivity network delays (javascript blocking downloads)

> Disclaimer: I am a Qwik core maintainer. We are focused on web performance and we're looking for better ways to measure the Qwik performance gains compared to other web frameworks.

As discussed in the web vitals feedback group (https://groups.google.com/g/web-vitals-feedback/c/aIMFRU7Wgx0/m/eiZYerxlCwAJ), neither the CWVs nor lighthouse currently expose a metric that accounts for javascript blocking downloads which are network delays and not CPU delays.

Unresponsiveness due to blocking downloads is not a rare occurence and having a metric for it allows developers to improve the performance of their apps significantly. As such I think that the sooner we can have at least one metric in lighthouse that accounts for such delays the better.

Because TTI does not rely on user inputs to measure interactivity delays, it **can** detect long delays caused by the first long task and the javascript blocking downloads that preceded it.

Would it be possible for the time being to bring back TTI to lighthouse until there is a better metric to account for javascript blocking downloads? Imo, TTI's sensitivity to outlier network requests and long tasks only makes it harder to reliably measure but is not harmful since it is lab only, and still helpful in a lot of cases. It is not perfect but it is better than nothing.

Currently the only known metric we have at our disposal to explain the Qwik gains is TTI. Having it back in lighthouse would already go a long way for us and I believe would also encourage apps on the other reactive frameworks to improve their user experience. Lighthouse could recommend lazy-loading per routes, shipping less javascript to the client, and maybe even point to selective hydration strategies (e.g. Astro islands, React Server Components, etc.) when relevant.

---

FWIW, the public statements around TTI's removal lead to a google doc that does not advocate much for its removal.

On https://web.dev/articles/tti:
> Time to Interactive (TTI) has proved overly sensitive to outlier network requests and long tasks, resulting in high variability in this metric. TTI was [removed as a metric from Lighthouse 10](https://developer.chrome.com/blog/lighthouse-10-0/#scoring-changes). Newer, alternative, metrics like [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp), [Total Blocking Time (TBT)](https://web.dev/articles/tbt), and [Interaction to Next Paint (INP)](https://web.dev/articles/inp) are usually better metrics to use in place of TTI.

On https://developer.chrome.com/blog/lighthouse-10-0/#scoring-changes:
> The venerable [Time To Interactive (TTI)](https://web.dev/articles/tti) metric is being removed in Lighthouse 10, concluding the [deprecation process started in Lighthouse 8](https://github.com/GoogleChrome/lighthouse/blob/main/docs/v8-perf-faq.md#whats-the-story-with-tti). TTI's 10% score weight is shifting to [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls), which will now account for 25% of the [overall performance score](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#lighthouse_10).

On https://github.com/GoogleChrome/lighthouse/blob/main/docs/v8-perf-faq.md#whats-the-story-with-tti:
> TTI serves a useful role as it's the largest metric value reported (often >10 seconds) and helps anchor perceptions.

> We see TBT as a stronger metric for evaluating the health of your main thread and its impact on interactivity, plus it [has lower variability](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit). TTI serves as a nice complement that captures the cost of long tasks, often from heavy JavaScript. That said, we expect to continue to reduce the weight of TTI and will likely remove it in a future major Lighthouse release.

And finally on the google doc (https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit):
> [Total Blocking Time](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit#heading=h.qt24f17vom8b) is a companion metric to [Time to Interactive](https://drive.google.com/a/chromium.org/open?id=1l50v3ljDeUmj9qBsfdPc3wKe_1CY5KFYI1baye2NhYk). This document introduces the definition and detailed analysis of its behavior.

> Conclusion
To recap the key qualitites of TBT:
TBT is useful at differentiating two sites with similar TTI even if neither have perfect UX.
The [wide distribution of values](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit#bookmark=id.t9mexoq8w17i) at each TTI bucket and [some examples](https://docs.google.com/document/d/1ufvsgvPHd_dTceCJxjn1VQLApZF1hAWr-OLoWVNjPSE/edit#heading=h.68t1ajhca586) we looked at proves that TBT is indeed valuable in differentiating user experience when TTI cannot.
Also, unlike TTI where most sites on the internet do poorly on, many sites have very good TBT. It should be easier understand the value of improving TBT.
TBT can be effective at highlighting cases where UX is bad enough to hurt user engagement.
A 4.2s TBT (value at the [90th percentile on mobile](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit#heading=h.qawp2p3s14gh)) sends a very clear message that there is serious room for improvement, with clear directions for how to make things better and lots of examples of sites that are doing better.
A small improvement to the site results in a small improvement of TBT, unlike TTI where small improvements are often not reflected in metric value.
TBT has reasonably low variability so it's easy to detect performance regressions and improvements.
42% of the time, the metric variation is lower than 200ms.
The metric is [lower relative standard deviation](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit#heading=h.bnew86wtxj1f) than TTI when filtered to high values (either TBT > 200ms, or TTI > 10s)
When metric value is low (<200ms), it has higher relative standard deviation, but 200ms can be considered a reasonable TBT budget for a site, where further improvement has low marginal benefit.

I don't see here much arguments pushing towards TTI's removal.

I do understand that there were internal discussions about this as well, but I wanted to point out that the public statements didn't lead to much argumentation.

---

Please note that we are available on Discord https://discord.gg/dtnXSPKpK if you want to schedule a call to discuss this further. You can DM me there directly.