Chrome Dev Summit 2018 is happening now and streaming live on YouTube. Watch now.

預計輸入延遲時間

爲什麼說此審查非常重要

輸入響應能力對用戶如何看待您應用的性能起着關鍵作用。 應用有 100 毫秒的時間響應用戶輸入。如果超過此時間,用戶就會認爲應用反應遲緩。 如需瞭解詳細信息,請參閱使用 RAIL 模型測量性能

有關爲什麼此審查測試的目標得分是 50 毫秒(而不是 RAIL 模型建議的 100 毫秒)的解釋,請參閱本文檔的此審查測試的目的部分。

如何通過此審查

要使您的應用更快地響應用戶輸入,您需要優化您的代碼在瀏覽器中的運行方式。 請查看渲染性能文檔中列出的一系列技巧。這些技巧包括將計算轉移到網絡工作線程以騰出主線程、重構 CSS 選擇器以執行較少的計算,以及使用 CSS 屬性,其可將瀏覽器密集型的操作數降至最低。

對於此審查,需要特別注意的一點是它不能完整測量輸入延遲時間。 正如本文檔的此審查測試的目的部分所述,此審查不會測量您的應用真正花了多少時間來響應用戶輸入。換句話說,它不會測量您的應用對用戶輸入的響應在視覺上是否完整。

要手動對此進行測量,請使用 Chrome DevTools Timeline 進行錄音。 請參閱如何使用 Timeline 工具以獲取更多幫助。

基本思路是啓動一個錄製、執行您要測量的用戶輸入、停止錄製,然後分析火焰圖以確保像素管道的所有階段都在 50 毫秒內完成。

如何實現此審查

本部分介紹如何實現此審查,以便您可以瞭解計算此審查得分的方式。

RAIL 性能模型建議應用在 100 毫秒內響應用戶輸入,而 Lighthouse 的目標得分是 50 毫秒。 爲什麼呢?

原因是 Lighthouse 使用一個代理指標來測量您的應用在響應用戶輸入方面的表現:主線程的可用性。 Lighthouse 假定您的應用需要 50 毫秒的時間來完全響應用戶的輸入(從實現任意 JavaScript 執行到以物理方式將新像素繪製到屏幕)。

如果主線程的不可用時間達 50 毫秒或更長,那麼,您的應用將沒有足夠的時間完成響應。

用戶遇到 Lighthouse 報告的輸入延遲時間的可能性爲 90% 或以下。 10% 的用戶會出現額外的延遲。