我們都知道建立良好的第一印象非常重要。這很重要 因此在認識新朋友時也同樣重要 在網路上。
在網路上曝光良好的第一印象可能會影響 或是成為忠實使用者,或是選擇不再回訪問題是 如何評估廣告曝光 你提供的資訊可能為何?
在網路上,初次曝光可能會有許多不同的形式 網站設計和視覺吸引力的 第一印象 載入速度和回應速度。
雖然使用網路 API 很難評估使用者對網站設計有多滿意 但評估速度和回應速度並不容易!
系統可評估網站載入速度的使用者 First Contentful Paint (FCP)。但網站繪製像素的速度 但螢幕只是報導的一部分回應式設計也同樣重要 就是使用者嘗試與這些像素互動!
「首次輸入延遲時間」(FID) 指標有助於評估使用者在 網站的互動性和回應速度
什麼是 FID?
FID 會評估使用者首次與網頁互動的時間 (亦即 使用者點選連結、輕觸按鈕或使用以 JavaScript 為基礎的自訂控制項) 瀏覽器實際開始處理事件處理常式的時間 回應。
FID 分數良好的是什麼?
為了提供良好的使用者體驗,網站應力求使用第一個輸入來源 延遲時間不超過 100 毫秒。為確保您能在 在大多數使用者中,理想的評估門檻是以下項目的第 75 個百分位數 載入網頁,並區隔行動裝置和電腦裝置。
FID 詳細資訊
身為編寫會回應事件的開發人員,我們通常會假設程式碼 要在事件發生時立即執行但身為使用者 我們都常遇到相反的情況,我們已在 曾嘗試與手機互動,但無時無刻都很沮喪 。
一般來說,輸入延遲 (又稱輸入延遲時間) 是因為瀏覽器的 主執行緒忙於處理其他事務,因此無法回覆使用者。 發生這個問題的常見原因之一,是瀏覽器忙於剖析及執行 是由應用程式載入的大型 JavaScript 檔案這項操作無法執行 任何事件監聽器,因為載入的 JavaScript 可能會指示執行該動作 其他內容
以下是一般網頁載入速度的時間表:
上方圖表顯示一個網頁正在發出數個網路要求 這些資源 (最有可能是 CSS 和 JS 檔案) 以及這些資源後面 下載完畢,會透過主執行緒處理
這會導致主執行緒短暫忙碌中, 以米色標示 工作 方塊。
首次輸入延遲通常發生在首次顯示內容所需時間之間 (FCP) 和 Time to Interactive (TTI),因為網頁含有 部分內容仍無法穩定互動。說明 這可能表示,我們已在時間軸中加入 FCP 和 TTI:
您可能已經注意到,系統時間較長 (包括三個 工作) 這段期間與網頁的互動 (例如點擊連結) 會出現 從接收點擊到主要執行緒能擷取回應的延遲時間 回應。
試想當使用者嘗試與位於 從時間最長的任務開始:
因為輸入內容是在瀏覽器執行工作時進行 必須等工作完成後才能回應輸入內容 則需要等待的時間是這位使用者在此網頁的 FID 值。
如果互動沒有事件監聽器,該怎麼辦?
FID 會測量接收輸入事件到接收輸入事件的時間差異 執行緒處於閒置狀態。這表示即使在發生事件時,系統也會評估 FID 則尚未註冊。這是因為許多使用者互動 不需要事件監聽器,但「確實」要求主執行緒在以下位置處於閒置狀態: 在此先執行
舉例來說,以下所有 HTML 元素都必須等待 主要執行緒上未完成的工作,才能回應使用者 互動:
- 文字欄位、核取方塊和圓形按鈕 (
<input>
、<textarea>
) - 選取下拉式選單 (
<select>
) - 連結 (
<a>
)
為何只考慮第一個意見?
雖然任何輸入的延遲都可能導致使用者體驗不佳,但我們主要是 建議您先評估第一次輸入延遲時間,原因如下:
- 首次輸入延遲時間會是使用者對網站的第一印象 回應速度和初次曝光都是影響我們整體 提高網站品質和可靠性的重要程度
- 網頁反應中,目前網路上最嚴重的互動問題 載入。因此,我們認為一開始就著重於改善網站的第一位使用者 最能有效提升整體 以及網路上的互動
- 建議網站如何修正首次輸入延遲時間過長 (程式碼分割、需預先載入較少 JavaScript 等) 不一定 都是解決網頁載入後輸入延遲問題的解決方案透過 這樣就能針對這些指標 指導方針。
哪些項目會視為第一次輸入?
FID 是一種指標,用於評估網頁在載入期間的回應速度。因此 只著重在點選、輕觸和按鍵等獨立動作的輸入事件 按下按鈕。
捲動和縮放等其他互動屬於連續動作, 完全不同的效能限制 (此外,瀏覽器通常可以 可隱藏延遲時間,方法是在另一個執行緒上執行這些程式碼)。
換句話說,FID 特別著重在 RAIL 中的 R (反應性) 表演 模型,而 相較於 A (動畫) 及其成效 性質應該分開評估。
要是使用者從來沒有與您的網站互動,該怎麼辦?
不是所有使用者每次造訪您的網站時,都會與網站互動。並非全部 互動情形與 FID 相關 (如上一節所述)。於 此外,部分使用者初次互動 會在不恰當的時機 您長時間處於忙碌狀態,部分使用者優先 互動會在適當時機 (主執行緒完全閒置時)。
這表示部分使用者不會有 FID 值,有些使用者的 FID 值較低 而部分使用者的 FID 值可能較高。
追蹤、記錄及分析 FID 的方式可能略有不同 也不會影響您熟悉的其他指標下一節將說明最佳作法。 而負責任的 AI 技術做法 有助於達成這項目標
為何只考慮輸入延遲?
如上所述,FID 只會測量「延遲」事件處理程序。會 不會自行評估整個事件處理時間 執行事件處理常式後,瀏覽器更新使用者介面。
雖然這個時間對使用者來說非常重要,而且「確實」會影響使用體驗
未納入這項指標,因為這麼做可能會鼓勵開發人員
找出導致體驗更嚴重的解決方法
可以將事件處理常式邏輯納入非同步回呼中 (透過
setTimeout()
或 requestAnimationFrame()
),才能與
與事件相關聯的任務如此一來,指標成效將有所提升
但使用者感知得到的回應速度較慢
然而,FID 只會測量「延遲」部分事件延遲時間,開發人員 廣告客戶還可以使用事件載入時間 API。請參閱自訂 指標。
如何評估 FID
FID 是一種評估指標, 欄位,因為後者需要真實 使用者與網頁互動的方式。您可以使用下列工具評估 FID。
現場工具
在 JavaScript 中評估 FID
如想在 JavaScript 中評估 FID,您可以使用事件載入時間
API。以下範例說明如何
建立
PerformanceObserver
敬上
會監聽
first-input
項目並記錄到控制台:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
const delay = entry.processingStart - entry.startTime;
console.log('FID candidate:', delay, entry);
}
}).observe({type: 'first-input', buffered: true});
在上述範例中,first-input
項目的延遲時間值是以
採用項目 startTime
和 processingStart
之間的差距
時間戳記。在大多數情況下都會是 FID 的值:不過,並非全部
有 first-input
個項目可用於評估 FID。
下節將說明 API 報表與方法之間的差異 要計算的指標
指標和 API 之間的差異
- API 將會為載入的頁面分派
first-input
項目 ,但系統在計算 FID 時,應忽略這些網頁。 - 如果頁面在背景執行,API 也會分派
first-input
個項目 進行檢查,但系統也應該忽略這些網頁 ,則只有在網頁位於 前景)。 - 當頁面還原來源時,API 不會回報
first-input
項目 往返快取,但 FID 應該 就必須以不同方式評估,因為使用者會將他們視為不同網頁 造訪次數。 - API 不會回報在 iframe 內發生的輸入內容,但指標卻
因為這類訊息會融入網頁的使用者體驗。這可以
表示 CrUX 和 RUM 的差異。
為了正確評估 FID,您應該將 FID 納入考量。子頁框可以使用 API
向父項頁框回報其
first-input
項目以進行匯總。
開發人員可以使用
web-vitals
JavaScript 程式庫,以便
測量 FID,並盡可能為您處理這些差異 (請注意,本文不包含 iframe 的問題):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
您可以參考
onFID()
,查看如何在 JavaScript 中評估 FID 的完整範例。
分析 FID 資料並製作相關報表
由於 FID 值的預期差異,因此在製作報表時 FID 會檢視值的分佈情形,並著重在較高百分位數。
無論 所有使用者的百分位數 Core Web Vitals 門檻是第 75 天。以 FID 來說,我們仍然非常強 建議您查看第 95-99 個百分位數,這些百分位數會對應到 特別是使用者在您網站的初次使用體驗中,這特別糟糕。 指出哪些部分需要改善。
就算是按裝置類別或類型區隔報表也一樣。適用對象 例如,如果您分別針對電腦和行動裝置製作報表,就會傳回您擷取的 FID 值 最在電腦使用者最在乎的因素應為電腦使用者的第 95 至 99 個百分位數 您應該在行動裝置最重視的 FID 值應為 95–99 。
如何改善 FID
想瞭解如何改善這項指標,請參閱最佳化 FID 的完整指南。
變更記錄
有時用於測量指標的 API 中會發現錯誤,有時在指標本身的定義中也會發現錯誤。因此,有時需要進行變更,這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。
為方便您管理,這些指標導入或定義的所有變更都會顯示在這份變更記錄中。
如果對這些指標有任何意見,歡迎透過 web-vitals-feedback Google 群組提供。