---
# System prepended metadata

title: Ch07. TTI (time to interactive) 互動準備時間

---

# Ch07. TTI (time to interactive) 互動準備時間

## 簡介

了解網頁何時可以互動，讓使用者可以不用等待太久即可對網頁進行操作。

### 定義

![](https://web-dev.imgix.net/image/admin/WZM0n4aXah67lEyZugOT.svg)

- 先算 FCP (first content painting): 參考第五章
- FCP 向右搜尋找到至少 5sec 的 quiete window 時間段：
    - 沒有長任務（50ms 以上的是長任務）
        - 代表 main thread 能夠在 100ms 內給予回應，所以每一個任務要保持在 50ms 以內，如果超過就是長任務，也會讓 main thread 沒辦法在 100ms 內給予回應，看起來就會有點卡。
    - 不超過兩個 GET request 
        - 代表可以供互動的關鍵 JavaScript 的載入完成時間點
        - 💡 會排除 GET Request 以外的類型是因為，通常是通過 GET 來請求資源 [^4][^6] 
        - 🤔 只剩下兩個 request，代表子資源已經載入完畢開始進入關鍵 JavaScript 的載入狀態，且通常在網路緩慢的情況下要 5 秒。
            - Lai: [html - Max parallel HTTP connections in a browser? - Stack Overflow](https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser)
- 往左回推找最後一個長任務的結束時間，即為 TTI 「時間點」
- 沒有找到則是一路到 FCP 尾為 TTI 「時間點」
- 💡 指標可能有的問題 [^5]：
	- 可能會讓一些非關鍵 JavaScript 的網頁在指標上表現不佳，但什麼算是非關鍵 JavaScript ? 只能有一個嗎？
	- 這一個指標是回推而不是即時，如果提前終止的網站就收不到此數據，提前終止與可互動性，是不是這個指標應該要考量的範圍？

![](https://web-dev.imgix.net/image/admin/I7HDZ9qGxe0jAzz6PxNq.png?auto=format&w=845)

[^4]: [WICG/time-to-interactive: Repository for hosting TTI specification and discussions around it.](https://github.com/WICG/time-to-interactive) WICG 是 W3C 下孵化新的網站點子的單位
[^5]: [Justify decision of Time to Interactive · Issue #2 · WICG/time-to-interactive](https://github.com/WICG/time-to-interactive/issues/2): 覺得觀點很有趣，指標要思考的是會鼓勵更多什麼樣的網站誕生。
[^6]: [HTTP Archive: Loading Speed](https://httparchive.org/reports/loading-speed#ttci)

## 測量與評估

![](https://i.imgur.com/ezpVeje.png)


- TTI 是在模擬環境下測量的指標，可以透過 lighthouse 測量
	- 💡 在模擬環境比較適合，是因為如果實際測量，使用者提前互動可能會影響到這個時間點 [^1]
- 如果 TTI 時間點往後延，則會影響到 FID (First Input Delay) 而有可能的互動性問題，作者建議要壓在 5 秒內。
	- 💡 為什麼建議 5 秒應是來自於 PR 50 的結果，light house 在 TTI 「分數」計算會參考 HTTP Archive（目前理解成盡可能收集所有網站的一個開源計畫，內含各種指標的計算結果）的資料，取秒數的 PR 值即為分數。 [^2] 其中 5 秒在分數中約中心位置（橘色分數的中間）。

[^1]: [Time to Interactive 可交互时间 (TTI)](https://web.dev/tti/)
[^2]: [Time to Interactive - Chrome Developers](https://developer.chrome.com/docs/lighthouse/performance/interactive/#how-lighthouse-determines-your-tti-score)

## 優化方向

- 目前大多採以 FID, TBT 來改善載入互動性，而非 TTI
	- 💡 TTI 衡量同秒數的體驗效果可能截然不同 [^3] e.g. 10 秒鐘內 3 個 51 ms 任務 vs 單個 10s 任務，TBT 分別是 3ms vs 9950 ms，但 TTI 都是 10s
	- 🤔  FID 也是衡量互動，但定位有別於 TBT 與 TTI 的指標，應該是因為這個指標是需要實際測量的結果，可以與實驗室測試的指標互補。
- 優化方向
	- 縮短主任務時間
	- 減少不必要的程式碼
	- 減少不必要的網路請求

[^3]: [Total Blocking Time 总阻塞时间 (TBT)](https://web.dev/tbt/#tbt-%E4%B8%8E-tti-%E6%9C%89%E4%BB%80%E4%B9%88%E5%85%B3%E7%B3%BB%EF%BC%9F)

## Review 

- 指標的定義？
- 指標的定位是什麼？
- 是個好指標嗎？如果不好有替代指標嗎？