First Input Delay (FID)

Philip Walton

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

Trên web, ấn tượng ban đầu tốt có thể tạo ra sự khác biệt giữa 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 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ị mà bạn có thể tạo ra đối với người dùng của mình?

Trên web, ấn tượng đầu tiên có thể có nhiều hình thức khác nhau—chúng tôi có ấn tượng đầu tiên về thiết kế và sức hấp dẫn trực quan của trang web cũng như về tốc độ và khả năng phản hồi của nó.

Mặc dù rất khó để đo lường mức độ người dùng thích thiết kế của trang web bằng API web, đo lường tốc độ và khả năng thích ứng của nó!

Ấn tượng đầu tiên của người dùng về tốc độ tải trang web của bạn có thể được đo lường bằng Nội dung đầu tiên hiển thị (FCP). Nhưng trang web của bạn có thể vẽ pixel nhanh như thế nào lên màn hình chỉ là một phần của câu chuyện. Một điều cũng quan trọng không kém là mức độ phản hồi trang web của bạn là 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ề tính tương tác và khả năng thích ứng của trang web.

FID là gì?

FID đo lường thời gian kể từ khi người dùng tương tác lần đầu với một trang (tức là khi họ nhấp vào một đường liên kết, nhấn vào một nút hoặc sử dụng một chế độ kiểm soát tuỳ chỉnh dựa trên JavaScript) vào thời điểm trình duyệt có thể thực sự bắt đầu xử lý trình xử lý sự kiện để phản hồi hoạt động 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 có Dữ liệu đầu vào đầu tiên Độ trễ từ 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, ngưỡng phù hợp để đ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à thiết bị máy tính.

Chi tiết FID

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

Nói chung, độ trễ đầu vào (còn gọi là độ trễ đầu vào) xảy ra do luồng chính đang bận thực hiện thao tác khác nên (chưa) phản hồi người dùng. Một lý do phổ biến khiến điều này 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. Khi đang thực hiện việc đó, ứng dụng không thể chạy mọi trình nghe sự kiện vì JavaScript mà trình nghe đang tải có thể yêu cầu trình nghe thực hiện 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:

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

Điều này dẫn đến những khoảng thời gian trong đó luồng chính bận trong giây lát, tức là biểu thị bằng chữ màu be việc cần làm chặn.

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

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

Xem xét đ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 khởi đầu nhiệm vụ dài nhất:

Do hoạt động đầu vào xảy ra trong khi trình duyệt đang chạy một tác vụ, nó phải đợi cho đến khi tác vụ hoàn tất trước khi có thể phản hồi thông tin đầu vào. Chiến lược phát hành đĩa đơn 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 mức delta giữa thời điểm nhận được sự kiện đầu vào cho đến khi sự kiện chính luồng tiếp theo ở trạng thái rảnh. Tức là FID được đo lường, ngay cả trong trường hợp một sự kiện trình nghe chưa được đăng ký. Lý do là vì có nhiều tương tác của người dùng không cần có trình nghe sự kiện nhưng có yêu cầu luồng chính ở trạng thái rảnh trong lệ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 người dùng tương tác:

• 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ỉ cân nhắc thông tin đầu vào?

Mặc dù sự chậm trễ từ bất kỳ dữ liệu đầu vào nào cũng có thể dẫn đến trải nghiệm người dùng kém, nhưng chủ yếu bạn nên đo độ trễ đầu vào đầu tiên vì một số lý do sau:

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

Mục nào được tính là thông tin đầu vào?

FID là chỉ số đo lường khả năng phản hồi của trang trong khi tải. Như vậy, chỉ tập trung vào các sự kiện đầu vào từ các hành động rời rạc như nhấp, nhấn và nhấn phím lần nhấn.

Các tương tác khác, như cuộn và thu phóng, là các hành động liên tục và có những hạn chế hiệu suất hoàn toàn khác (ngoài ra, 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 theo cách khác, FID tập trung vào R (tính phản hồi) trong RAIL hiệu suất mô hình, trong khi cuộn và thu phóng có liên quan nhiều hơn đến A (ảnh động) và hiệu suất của chúng mỗi khía cạnh phải được đánh giá riêng.

Điều gì sẽ xảy ra nếu người dùng không bao giờ tương tác với trang web của bạn?

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

Tức là một số người dùng sẽ không có giá trị FID, một số người dùng sẽ có 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ẽ khá khác biệt từ 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 này.

Tại sao chỉ xem xét độ trễ đầu vào?

Như đã đề cập ở trên, FID chỉ đo lường "độ trễ" trong quá trình xử lý sự kiện. Có không đo lường tổng thời lượng xử lý sự kiện cũng như thời gian cần thiết trình duyệt để 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ù khoảng thời gian này quan trọng đối với người dùng và ảnh hưởng đến trải nghiệm, 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 hơn—tức là 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 biệt khỏi công việc liên quan đến sự kiện. Kết quả là chỉ số này sẽ được cải thiện nhưng phản hồi chậm hơn theo cảm nhận của người dùng.

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

Cách đo lường FID

FID là chỉ số chỉ có thể đo lường ở vì trường này yêu cầu một trường dữ liệu người dùng tương tác với trang của bạn. Bạn có thể đo lường FID (Độ trễ đầu vào đầu tiên) bằng những công cụ sau.

Công cụ tại hiện trường

• Trải nghiệm người dùng trên Chrome Báo cáo
• PageSpeed Insights
• Search Console (Các chỉ số quan trọng về trang web báo cáo)
• Thư viện JavaScript web-vitals

Đo lường FID trong JavaScript

Để đo lường FID trong JavaScript, bạn có thể sử dụng hàm Event Timing . Ví dụ sau đây trình bày cách tạo một PerformanceObserver chuyên nghe first-input các thông tin và ghi lại chúng 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 lấy delta giữa startTime và processingStart của mục nhập dấu thời gian. Trong hầu hết các trường hợp, đây sẽ là giá trị FID; tuy nhiên, không phải tất cả Các mục nhập first-input 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 thức chỉ số được tính.

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

• API sẽ gửi mục nhập first-input cho các trang đã 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 lần nhập đầu tiên xuất hiện, nhưng các trang đó cũng nên được bỏ qua. khi tính FID (thông tin đầu vào chỉ được xem xét nếu trang ở nền trước toàn bộ thời gian).
• API không báo cáo các mục nhập first-input khi trang được khôi phục từ bộ nhớ đệm cho thao tác tiến/lùi, nhưng FID phải trong các trường hợp này vì người dùng trải nghiệm chúng dưới dạng một trang riêng biệt truy cập.
• API không báo cáo dữ liệu đầu vào xảy ra trong iframe nhưng chỉ số này 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ể hiển thị dưới dạng điểm khác biệt giữa CrUX và RUM. Để đo lường chính xác FID, bạn nên cân nhắc đến các yếu tố này. Các khung hình 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ẹ nhằ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 sang đo lường FID, giúp xử lý các khác biệt này cho bạn (nếu có thể, hãy lưu ý vấn đề iframe 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 cho onFID() để xem 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 về các giá trị FID, điều quan trọng là khi báo cáo về FID (Độ trễ đầu vào đầu tiên) bạn xem xét sự phân phối giá trị và tập trung vào các phân vị cao hơn.

Trong khi 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à ngưỡng thứ 75, đặc biệt đối với FID, chúng tôi vẫn bạn nên xem xét tỷ lệ phần trăm thứ 95 đến 99, vì các phân vị đó sẽ tương ứng với trải nghiệm đầu tiên đặc biệt tệ mà người dùng gặp phải với trang web của bạn. Và nó sẽ cho bạn biết những khía cạnh cần cải thiện nhiều nhất.

Điều này đúng ngay cả khi bạn phân đoạn báo cáo theo danh mục hoặc loại thiết bị. Cho 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, giá trị FID mà bạn quan tâm nhiều nhất trên máy tính sẽ là phân vị thứ 95–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 nên là số từ 95 đến 99 phân vị của người dùng thiết bị di động.

Cách cải thiện FID (Độ trễ đầu vào đầu tiên)

Bạn có thể xem hướng dẫn đầy đủ về cách tối ưu hoá FID để hướng dẫn 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 cần phải thực hiện thay đổi và những thay đổi này có thể xuất hiện 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.

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

Nếu muốn gửi ý 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 phản hồi web-vitals-feedback.