First Input Delay (FID)

Hỗ trợ trình duyệt

  • 76
  • 79
  • 89
  • x

Nguồn

Chúng ta đều biết tầm quan trọng của việc tạo ấn tượng tốt ban đầu. Khi gặp gỡ những người mới và điều này cũng quan trọng khi xây dựng trải nghiệm trên web.

Trên web, ấn tượng đầu tiên tốt có thể tạo nên sự khác biệt giữa việc một người trở thành người dùng trung thành hoặc họ rời đi và không bao giờ quay lại. Câu hỏi đặt ra là điều gì tạo nên ấn tượng tốt và làm cách nào để đo lường loại hiển thị bạn có thể đang tạo ra cho người dùng của mình?

Trên web, lượt hiển thị đầu tiên có thể có nhiều dạng khác nhau — chúng ta có những ấn tượng đầu tiên về thiết kế và độ bắt mắt của trang web, cũng như ấn tượng đầu tiên về tốc độ và khả năng phản hồi của trang web.

Tuy rất khó để đo lường mức độ người dùng như thiết kế của một trang web bằng API web, nhưng việc đo lường tốc độ và khả năng phản hồi của trang web thì không!

Lần hiển thị đầu tiên mà người dùng thấy được về tốc độ tải của trang web có thể được đo bằng Thời gian hiển thị nội dung đầu tiên (FCP). Nhưng tốc độ trang web của bạn có thể vẽ điểm ảnh lên màn hình mới chỉ là một phần của câu chuyện. Một điều quan trọng không kém là mức độ phản hồi của trang web khi người dùng cố gắng tương tác với các pixel đó!

Chỉ số Độ trễ đầu vào đầu tiên (FID) giúp đo lường ấn tượng đầu tiên của người dùng về khả năng tương tác và phản hồi trên trang web của bạn.

FID là gì?

FID đo lường thời gian từ khi người dùng tương tác với một trang lần đầu tiên (tức là khi họ nhấp vào đường liên kết, nhấn vào một nút hoặc sử dụng một tuỳ chọn kiểm soát tuỳ chỉnh dựa trên JavaScript) đến thời điểm trình duyệt thực sự có thể bắt đầu xử lý trình xử lý sự kiện để phản hồi lượt tương tác đó.

Điểm FID tốt là gì?

Để cung cấp trải nghiệm tốt cho người dùng, các trang web nên cố gắng đạt được Độ trễ đầu vào đầu tiên là 100 mili giây trở xuống. Để đảm bảo bạn đạt được mục tiêu này cho hầu hết người dùng của mình, một ngưỡng tốt để đo lường là phân vị thứ 75 của lượt tải trang, được phân đoạn trên thiết bị di động và máy tính để bàn.

Giá trị FID tốt là từ 2,5 giây trở xuống, giá trị thấp hơn lớn hơn 4,0 giây và bất kỳ mức nào ở giữa cần cải thiện

FID chi tiết

Khi các nhà phát triển viết mã phản hồi các sự kiện, chúng tôi thường giả định rằng mã của mình sẽ chạy ngay lập tức, ngay khi sự kiện xảy ra. Nhưng là người dùng, tất cả chúng ta đều thường xuyên gặp phải điều ngược lại – chúng ta tải một trang web trên điện thoại, cố gắng tương tác với trang web và sau đó thấy thất vọng khi không có gì xảy ra.

Nhìn chung, độ trễ đầu vào (còn gọi là độ trễ đầu vào) xảy ra vì luồng chính của trình duyệt đang bận làm việc khác nên không thể phản hồi người dùng. Một lý do phổ biến có thể xảy ra là trình duyệt đang bận phân tích cú pháp và thực thi một tệp JavaScript lớn do ứng dụng của bạn tải. Trong quá trình này, trình duyệt không thể chạy bất kỳ trình nghe sự kiện nào vì JavaScript đang tải có thể yêu cầu trình nghe thực hiện thao tác khác.

Hãy xem xét tiến trình sau đây của một lượt tải trang web thông thường:

Ví dụ về dấu vết tải trang

Hình ảnh trên cho thấy một trang đang gửi một vài yêu cầu mạng về tài nguyên (rất có thể là tệp CSS và JS) và sau khi các tài nguyên đó được tải xuống xong, chúng sẽ được xử lý trên luồng chính.

Điều này dẫn đến tình trạng luồng chính đang bận trong giây lát, điều này được biểu thị bằng các khối tác vụ có màu be.

Độ trễ đầu vào đầu tiên thường xảy ra giữa Thời gian hiển thị nội dung đầu tiên (FCP)Thời gian tương tác (TTI) vì trang đã hiển thị một số nội dung nhưng chưa có mức độ tương tác đáng tin cậy. Để minh hoạ cho điều này, chúng tôi đã thêm FCP và TTI vào tiến trình:

Ví dụ về dấu vết tải trang bằng FCP và TTI

Bạn có thể nhận thấy có một khoảng thời gian khá lớn (bao gồm cả 3 tác vụ dài) giữa FCP và TTI, nếu người dùng cố gắng tương tác với trang trong khoảng thời gian đó (ví dụ: bằng cách nhấp vào một đường liên kết), thì sẽ có độ trễ giữa thời điểm nhận được lượt nhấp và thời điểm luồng chính có thể phản hồi.

Hãy cân nhắc điều gì sẽ xảy ra nếu người dùng cố gắng tương tác với trang ở gần điểm bắt đầu thực hiện thao tác dài nhất:

Ví dụ về dấu vết tải trang bằng FCP, TTI và FID

Vì hoạt động đầu vào xảy ra trong khi trình duyệt đang chạy một tác vụ, nên phải đợi cho đến khi tác vụ đó hoàn tất thì mới có thể phản hồi hoạt động đầu vào. Thời gian phải chờ là giá trị FID cho người dùng này trên trang này.

Nếu một lượt tương tác không có trình nghe sự kiện thì sao?

FID đo lường delta giữa thời điểm nhận được một sự kiện đầu vào cho đến khi luồng chính chuyển sang trạng thái rảnh tiếp theo. Điều này có nghĩa là FID được đo lường ngay cả trong trường hợp trình nghe sự kiện chưa được đăng ký. Lý do là vì nhiều hoạt động tương tác của người dùng không cần đến trình nghe sự kiện nhưng yêu cầu luồng chính phải ở trạng thái rảnh để chạy.

Ví dụ: tất cả các phần tử HTML sau đây cần phải đợi các tác vụ đang diễn ra trên luồng chính hoàn tất trước khi phản hồi tương tác của người dùng:

  • Trường văn bản, hộp đánh dấu và nút chọn (<input>, <textarea>)
  • Chọn trình đơn thả xuống (<select>)
  • đường liên kết (<a>)

Tại sao chỉ xem xét nội dung đầu tiên?

Mặc dù độ trễ từ dữ liệu đầu vào bất kỳ đều có thể gây ra trải nghiệm không tốt cho người dùng, nhưng bạn nên đo lường độ trễ đầu vào đầu tiên vì một số lý do:

  • Độ trễ đầu vào đầu tiên sẽ là ấn tượng đầu tiên của người dùng về mức độ phản hồi của trang web. Lượt hiển thị đầu tiên rất quan trọng trong việc định hình ấn tượng tổng thể của chúng tôi về chất lượng và độ tin cậy của trang web.
  • Các vấn đề lớn nhất về tính tương tác mà chúng ta thấy trên web hiện nay xảy ra trong quá trình tải trang. Do đó, chúng tôi tin rằng ban đầu việc tập trung vào việc cải thiện mức độ tương tác đầu tiên của người dùng trang web sẽ có tác động lớn nhất đến việc cải thiện mức độ tương tác tổng thể của web.
  • Các giải pháp đề xuất về cách các trang web cần khắc phục độ trễ đầu vào cao (phân chia mã, tải ít JavaScript trước, v.v.) không nhất thiết phải là giải pháp để khắc phục độ trễ đầu vào chậm sau khi tải trang. Bằng cách tách biệt các chỉ số này, chúng tôi có thể cung cấp nguyên tắc về hiệu suất cụ thể hơn cho nhà phát triển web.

Mục nào được tính là lượt nhập đầu tiên?

FID là chỉ số đo lường khả năng phản hồi của trang trong khi tải. Do đó, ứng dụng này chỉ tập trung vào các sự kiện đầu vào từ các thao tác riêng biệt như lượt nhấp, lượt nhấn và lượt nhấn phím.

Các hoạt động tương tác khác, chẳng hạn như cuộn và thu phóng, là những hành động liên tục và có những hạn chế về hiệu suất hoàn toàn khác nhau (ngoài ra, các trình duyệt thường có thể ẩn độ trễ bằng cách chạy chúng trên một luồng riêng).

Nói một cách khác, FID tập trung vào R (khả năng phản hồi) trong mô hình hiệu suất RAIL, trong khi việc cuộn và thu phóng liên quan nhiều hơn đến A (ảnh động) và chất lượng hiệu suất của chúng phải được đánh giá riêng.

Nếu người dùng không bao giờ tương tác với trang web của bạn thì sao?

Không phải tất cả người dùng đều sẽ tương tác với trang web của bạn mỗi khi họ truy cập. Và không phải lượt tương tác nào cũng liên quan đến FID (như đã đề cập trong phần trước). Ngoài ra, các lượt tương tác đầu tiên của một số người dùng sẽ diễn ra không tốt (khi luồng chính bận trong một khoảng thời gian dài) và các lượt tương tác đầu tiên của một số người dùng sẽ diễn ra thuận tiện (khi luồng chính hoàn toàn không hoạt động).

Điều này có nghĩa là một số người dùng sẽ không có giá trị FID, một số người dùng có giá trị FID thấp và một số người dùng có thể sẽ có giá trị FID cao.

Cách bạn theo dõi, báo cáo và phân tích FID có thể sẽ hơi khác so với các chỉ số khác mà bạn có thể đã quen thuộc. Phần tiếp theo giải thích cách tốt nhất để thực hiện việc này.

Tại sao chỉ xem xét độ trễ khi nhập dữ liệu?

Như đã đề cập ở trên, FID chỉ đo lường "độ trễ" trong quá trình xử lý sự kiện. Mô hình này không tự đo lường thời gian xử lý sự kiện cũng như thời gian trình duyệt cần để cập nhật giao diện người dùng sau khi chạy trình xử lý sự kiện.

Mặc dù thời gian này quan trọng đối với người dùng và có ảnh hưởng đến trải nghiệm, nhưng nó không được đưa vào chỉ số này vì làm như vậy có thể khuyến khích nhà phát triển thêm giải pháp thực sự khiến trải nghiệm kém đi – tức là họ có thể gói logic trình xử lý sự kiện trong một lệnh gọi lại không đồng bộ (thông qua setTimeout() hoặc requestAnimationFrame()) để tách riêng nó khỏi tác vụ liên kết với sự kiện. Kết quả sẽ là điểm số chỉ số cải thiện nhưng phản hồi chậm hơn theo nhận thấy của người dùng.

Tuy nhiên, mặc dù FID chỉ đo lường phần "độ trễ" của độ trễ sự kiện, nhưng những nhà phát triển muốn theo dõi thêm vòng đời sự kiện có thể sử dụng API Thời gian sự kiện. Hãy xem hướng dẫn về chỉ số tuỳ chỉnh để biết thêm thông tin chi tiết.

Cách đo lường FID

FID là một chỉ số chỉ có thể đo lường trong trường hợp, vì chỉ số này đòi hỏi một người dùng thực để tương tác với trang của bạn. Bạn có thể đo lường FID bằng những công cụ sau.

Công cụ thực địa

Đo lường FID trong JavaScript

Để đo lường FID trong JavaScript, bạn có thể sử dụng API Thời gian sự kiện. Ví dụ sau cho biết cách tạo một PerformanceObserver giúp theo dõi các mục first-input và ghi nhật ký các mục đó vào bảng điều khiển:

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});

Trong ví dụ trên, giá trị độ trễ của mục nhập first-input được đo bằng cách lấy delta giữa các dấu thời gian startTimeprocessingStart của mục nhập. Trong hầu hết trường hợp, đây sẽ là giá trị FID; tuy nhiên, không phải mục nhập first-input nào cũng hợp lệ để đo lường FID.

Phần sau đây liệt kê sự khác biệt giữa nội dung API báo cáo và cách tính chỉ số.

Sự khác biệt giữa chỉ số và API

  • API sẽ gửi các mục nhập first-input cho các trang được tải trong thẻ nền nhưng bạn nên bỏ qua các trang đó khi tính FID.
  • API cũng sẽ gửi các mục nhập first-input nếu trang đã chạy ở chế độ nền trước khi hoạt động đầu vào đầu tiên xảy ra, nhưng bạn cũng nên bỏ qua các trang đó khi tính FID (dữ liệu đầu vào chỉ được xem xét nếu trang ở nền trước toàn bộ thời gian).
  • API này không báo cáo các mục first-input khi trang được khôi phục từ bộ nhớ đệm cho thao tác tiến/lùi, nhưng bạn nên đo lường FID trong những trường hợp này vì người dùng trải nghiệm chúng dưới dạng lượt truy cập trang riêng biệt.
  • API không báo cáo dữ liệu đầu vào xảy ra trong iframe, nhưng chỉ số thì báo cáo vì chúng là một phần trong trải nghiệm người dùng trên trang. Điều này có thể cho thấy sự khác biệt giữa CrUX và rum. Để đo lường FID đúng cách, bạn nên xem xét các chỉ số này. Các khung phụ có thể sử dụng API để báo cáo các mục nhập first-input của chúng cho khung mẹ để tổng hợp.

Thay vì ghi nhớ tất cả những khác biệt nhỏ này, nhà phát triển có thể sử dụng thư viện JavaScript web-vitals để đo lường FID, giúp xử lý những khác biệt này cho bạn (nếu có thể, xin lưu ý rằng vấn đề về iframe sẽ không được đề cập):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Bạn có thể tham khảo mã nguồn của onFID() để biết ví dụ đầy đủ về cách đo lường FID trong JavaScript.

Phân tích và báo cáo về dữ liệu FID

Do sự chênh lệch dự kiến của các giá trị FID, điều quan trọng là khi báo cáo về FID, bạn phải xem xét tình trạng phân phối các giá trị và tập trung vào các phân vị cao hơn.

Mặc dù lựa chọn phân vị cho tất cả ngưỡng Chỉ số quan trọng chính của trang web là thứ 75, nhưng đối với FID cụ thể, bạn vẫn nên xem xét phân vị thứ 95 đến 99, vì các phân vị đó sẽ tương ứng với những trải nghiệm đặc biệt kém mà người dùng gặp phải lần đầu tiên trên trang web. Đồng thời, mô hình này sẽ cho bạn biết những khía cạnh cần cải thiện nhất.

Điều này vẫn áp dụng ngay cả khi bạn phân đoạn báo cáo theo loại hoặc danh mục thiết bị. Ví dụ: nếu bạn chạy các báo cáo riêng cho máy tính và thiết bị di động, thì giá trị FID mà bạn quan tâm nhất trên máy tính phải là phân vị thứ 95 đến 99 của người dùng máy tính và giá trị FID mà bạn quan tâm nhất trên thiết bị di động phải là phân vị thứ 95 đến 99 của người dùng thiết bị di động.

Cách cải thiện FID

Bạn có thể xem hướng dẫn đầy đủ về cách tối ưu hoá FID để biết các kỹ thuật giúp cải thiện chỉ số này.

Nhật ký thay đổi

Đôi khi, lỗi được phát hiện trong các API dùng để đo lường chỉ số và đôi khi trong định nghĩa của chính các chỉ số. Do đó, đôi khi, bạn phải thực hiện thay đổi và những thay đổi này có thể hiển thị dưới dạng sự cải thiện hoặc hồi quy trong báo cáo nội bộ và trang tổng quan của bạn.

Để giúp bạn quản lý vấn đề này, tất cả các thay đổi đối với cách triển khai hoặc định nghĩa các chỉ số này sẽ xuất hiện trong Nhật ký thay đổi này.

Nếu có ý kiến phản hồi về các chỉ số này, bạn có thể gửi ý kiến phản hồi trong nhóm Google quan trọng về phản hồi trên web.