Chrome 使用資料顯示,使用者有 90% 的時間在載入網頁「之後」會花費更多時間,因此在網頁生命週期中謹慎評估回應速度相當重要。這是 INP 指標評估的內容。
良好的回應是指網頁能快速回應互動。當網頁回應互動時,瀏覽器會在下一個繪製的頁框中顯示視覺回饋。舉例來說,您可以透過視覺回饋瞭解是否確實將特定項目新增至線上購物車、是否開啟了行動版導覽選單、是否開啟了登入表單的內容等等。
有些互動的處理時間會特別長,但特別複雜的互動方式尤其需要快速呈現一些初步的視覺回饋,讓使用者知道發生了什麼事。瀏覽器繪製的下一個影格是最佳機會。
因此,INP 的用途並非測量互動的「所有」最終效果 (例如其他非同步作業的網路擷取和 UI 更新),而只會測量「下一波」繪製作業遭到封鎖的時間。因此,延遲視覺回饋可能會讓使用者覺得網頁回應速度不夠快,因此設計 INP 可以協助開發人員評估這部分的使用者體驗。
在以下影片中,右例為手掌正在開啟的即時視覺回饋。左例為回應速度慢的例子,說明這類反應會如何造成不良的使用者體驗。
本指南將說明 INP 的運作方式、評估方式,並提供改善 INP 的資源。
什麼是 INP?
INP 指標會觀察使用者在造訪頁面期間,在整個造訪期間發生的所有點擊、輕觸和鍵盤互動延遲,藉此評估網頁對使用者互動的整體反應。最終 INP 值是指觀測到的最長互動時間,忽略離群值。
INP 的計算方式是觀察使用者在網頁進行的所有互動。針對大多數網站,與延遲時間最差的互動會回報為 INP。
不過,如果是含有大量互動的網頁,隨機發生當機問題可能會導致其他回應式網頁發生異常高延遲的互動。單一網頁上發生的互動越多,發生這個情況的可能性就越高。
為了更準確地評估互動次數較多的網頁實際回應速度,系統會忽略每 50 次互動最高的一次互動。大多數的網頁體驗都沒有超過 50 次互動,因此最差的互動通常最常出現。接著,系統會照常記錄所有網頁瀏覽的第 75 個百分位數,藉此進一步排除離群值,為大多數使用者或改善使用者創造價值。
「互動」是一組事件處理常式,可在相同邏輯使用者手勢時觸發。例如「輕觸」在觸控螢幕裝置上,互動包括多個事件,例如 pointerup
、pointerdown
和 click
。互動可能是由 JavaScript、CSS、內建瀏覽器控制項 (例如表單元素) 或兩者的組合所驅動。
互動延遲時間是由一組事件處理常式最長的持續時間組成,這些事件處理常式是由多個事件處理常式促成互動,從使用者開始互動到瀏覽器繪製下一個影格的那一刻起算。
何謂良好的 INP 分數?
固定標籤,例如「良好」或「不佳」回應速度指標並不容易一方面,您可能想要鼓勵開發程序以良好的回應速度為優先。另一方面,您必須考慮到使用者採用的裝置在設定可實現的開發目標方面,其功能會有相當大的變化。
為確保您的使用者體驗獲得良好回應,評估門檻是記錄中網頁載入情形的第 75 個百分位數,並以行動裝置和電腦做為區隔:
- 如果 INP 低於或在 200 毫秒,表示網頁回應速度良好。
- 如果 INP 超過 200 毫秒,且低於或為 500 毫秒,表示網頁的回應速度需要改善。
- 如果 INP 超過 500 毫秒,表示網頁回應速度較慢。
互動是什麼?
互動的主要驅動力通常是 JavaScript,但瀏覽器會透過「非」以 JavaScript 技術提供的控制項 (例如核取方塊、圓形按鈕和 CSS 提供的控制項) 提供互動。
使用 INP 時,系統只會觀測下列互動類型:
- 使用滑鼠點擊。
- 輕觸有觸控螢幕的裝置。
- 按下實體鍵盤或螢幕鍵盤上的按鍵。
互動行為發生在主要文件或內嵌在文件的 iframe 中,例如點擊內嵌影片的次數。使用者不知道 iframe 中的內容,因此必須利用 iframe 中的 INP 評估頂層網頁的使用者體驗。JavaScript Web API 無法存取 iframe 的內容,因此 CrUX 和 RUM 可能存在差異
互動可由多個事件組成。舉例來說,按鍵動作包含 keydown
、keypress
和 keyup
事件。輕觸互動包含 pointerup
和 pointerdown
事件。互動持續時間最長的事件,會影響互動的總延遲時間。
系統會在使用者離開網頁時計算網頁的 INP。顯示的結果是單一值,用來代表網頁在整個生命週期的回應速度。INP 低代表網頁對使用者輸入的回應內容可靠。
INP 與首次輸入延遲時間 (FID) 有何不同?
INP 是首次輸入延遲時間 (FID) 的後續指標。這兩項指標都是回應指標,但 FID 只會測量網頁上「最初」互動的輸入延遲時間。INP 會觀察網頁上的「所有」互動,從輸入延遲開始,到執行事件處理常式所需的時間,最後直到瀏覽器繪製下一個影格為止,藉此改善 FID。
這些差異表示 INP 和 FID 都是不同的回應指標類型。如果 FID 是用來評估使用者第一次瀏覽網頁的載入速度指標,無論網頁互動的期間為何,INP 指標都是評估整體回應速度的可靠指標。
如果系統未顯示 INP 值,該怎麼辦?
網頁可能會傳回沒有 INP 值。這可能由許多因素造成,包括:
- 網頁已載入,但使用者從未點選、輕觸或按下鍵盤上的按鍵。
- 網頁已載入,但使用者透過未測量的手勢與其互動,例如捲動或將滑鼠遊標懸停在元素上。
- 網頁由搜尋檢索器 (例如搜尋檢索器) 或無頭瀏覽器存取,而未編寫指令碼與網頁互動。
如何評估 INP
INP 可在欄位和研究室中評估,協助您模擬實際使用者互動的程度。
實地
理想情況下,最佳化 INP 的流程會從實際資料開始著手。最理想的情況是,即時使用者監控 (RUM) 中的欄位資料不僅提供網頁的 INP 值,還會列出哪些特定互動對 INP 值本身負責、互動期間或之後的互動、互動類型 (點擊、按鍵或輕觸),以及其他有利於您識別互動方面影響回應的寶貴時機。
如果您的網站符合 Chrome 使用者體驗報告 (CrUX) 的納入條件,您可以透過 PageSpeed Insights 中的 CrUX 中的 CrUX 進行操作 (以及其他 Core Web Vitals),迅速取得 INP 的欄位資料。您至少能夠取得網站 INP 的來源層級資料,但在某些情況下,您也可以取得網址層級的資料。
不過,雖然 CrUX 能告訴您是否「是否」發生問題,但無法告訴您問題成因。RUM 解決方案可協助您進一步瞭解出現回應問題的網頁、使用者或使用者互動。能夠將 INP 歸因於個別互動,不僅省時省力,也不必費心處理。
實驗室
理想情況下,一旦有能指出網頁互動速度緩慢的基礎資料,建議您先在研究室中進行測試。現場資料可讓在研究室中重現有問題的互動,讓工作更輕鬆簡單。
不過,您完全可能沒有欄位資料。雖然部分研究室工具「可以」評估 INP,但實驗室測試期間網頁的 INP 值將取決於評估期間發生的互動。使用者行為可能難以預測且變動,也就是說,研究室中的測試可能不會以實際欄位資料的方式呈現問題互動情形。此外,部分研究室工具不會回報網頁的 INP,因為這類工具只會觀測載入網頁時沒有任何互動。在這種情況下,Total Blocking Time (TBT) 或許是 INP 的合理替代指標,但不能取代 INP 本身和其本身。
儘管使用研究室工具評估網頁的 INP 時設有限制,但仍有一些策略可在研究室中重現緩慢的互動。這些策略包括追蹤常見的使用者流程,並在過程中測試各種互動,並在載入網頁時 (主執行緒通常最忙碌時) 與網頁互動,以便找出使用者體驗的關鍵階段中緩慢的互動。
如何改善 INP
我們彙整了最佳化 INP 指南,可引導您逐步找出實際發生中緩慢互動的情況,並根據研究室資料來找出原因並加以改善。
變更記錄
有時用於測量指標的 API 中會發現錯誤,有時在指標本身的定義中也會發現錯誤。因此,有時需要進行變更,這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。
為方便您管理,這些指標導入或定義的所有變更都會顯示在這份變更記錄中。
如果對這些指標有任何意見,請前往 web-vitals-feedback Google 群組提供。
學以致用
INP 指標的主要目標為何?
計算 INP 時,系統會觀察下列哪一種互動類型?(請選取所有適用選項。)
「延遲」如何是否有為 INP 定義的互動?
INP 和 FID 有何差異?
在 PageSpeed Insights 等工具中,哪些網頁可能無法提供網頁的 INP 資料?
在研究室環境中重現緩慢互動而言,哪項最有效策略?
✨ 本測驗是由 Gemini 1.5 生成,並經過人工審查。歡迎提供意見