Trang này được dịch bởi Cloud Translation API.

First Input Delay (FID)

Philip Walton

Hỗ trợ trình duyệt

Chúng ta đều biết tầm quan trọng của việc tạo ấn tượng tốt ngay từ đầu. Điều này rất quan trọng khi gặp gỡ người mới và cũng 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 nên 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 đặt ra là điều gì tạo nên ấn tượng tốt và làm cách nào để bạn đo lường loại ấn tượng mà bạn có thể tạo ra cho người dùng?

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

Mặc dù khó đo lường mức độ người dùng thích 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 lại không khó!

Ấn tượng đầu tiên của người dùng cho thấy tốc độ tải trang web của bạn có thể đo lường bằng Nội dung hiển thị đầu tiên (FCP). Tuy nhiên, tốc độ hiển thị điểm ảnh trên màn hình chỉ là một phần nhỏ trong câu chuyện. Điều quan trọng không kém là trang web của bạn phản hồi nhanh như thế nào 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à khả năng phản hồi của trang web.

FID là gì?

FID đo lường thời gian 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 tùy chọn kiểm soát tuỳ chỉnh dựa trên JavaScript) cho đến thời điểm 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 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 giảm độ trễ cho lần nhập đầu tiên là 100 mili giây trở xuống. Để đảm bảo hầu hết người dùng của bạn đạt được mục tiêu này, 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.

Giá trị FID tốt là từ 2, 5 giây trở xuống, giá trị kém lớn hơn 4 giây và mọi giá trị ở giữa cần cải thiện

Thông tin chi tiết về FID

Là nhà phát triển viết mã phản hồi sự kiện, chúng ta 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 tôi tải một trang web trên điện thoại, cố tương tác với trang web, nhưng rồi lại 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 thực hiện một công việc khác, vì vậy, trình duyệt chưa thể (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. Trong khi đang làm việc đó, trình duyệt không thể chạy bất kỳ trình nghe sự kiện nào vì JavaScript mà trình duyệt đang tải có thể yêu cầu ứng dụng thực hiện thao tác khác.

Hãy xem xét tiến trình tải trang web thông thường sau đây:

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

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

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

Độ trễ đầu vào lâu thường xảy ra giữa Hiển thị nội dung đầu tiên (FCP) và Thời gian tương tác (TTI) vì trang đã 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, 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 có FCP và TTI

Bạn có thể nhận thấy rằng có một khoảng thời gian hợp lý (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), 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 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 phần đầu của tác vụ lâu nhất:

Ví dụ về dấu vết tải trang có 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 trình duyệt phải đợi cho đến khi tác vụ đó hoàn tất thì mới có thể phản hồi thông tin đầ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.

Điều gì sẽ xảy ra nếu một lượt tương tác không có trình nghe sự kiện?

FID đo lường delta giữa thời điểm nhận được sự kiện đầu vào và thời điểm luồng chính ở trạng thái rảnh tiếp theo. Tức 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à nhiều hoạt động tương tác của người dùng không yêu cầu 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 tiến hành trên luồng chính hoàn tất trước khi phản hồi các hoạt động 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 dữ liệu đầu vào đầu tiên?

Mặc dù sự chậm trễ của bất kỳ dữ liệu đầu vào nào cũng có thể gây ra trải nghiệm kém cho người dùng, nhưng bạn chủ yếu 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ề khả năng phản hồi của trang web. Ấn tượng đầ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 đề tương tác lớn nhất 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 việc tập trung vào việc cải thiện lượt tương tác đầu tiên của người dùng với trang web sẽ có tác động lớn nhất đến việc cải thiện khả năng tương tác tổng thể của web.
Các giải pháp đề xuất về cách trang web khắc phục độ trễ đầu vào cao (phân tách mã, tải ít JavaScript trước, v.v.) không nhất thiết phải là các 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 riêng các chỉ số này, chúng tôi có thể cung cấp hướng dẫn cụ thể hơn về hiệu suất 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. Do đó, lớp này chỉ tập trung vào các sự kiện đầu vào từ các hành động 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à các thao tác liên tục và có các giới hạn hiệu suất hoàn toàn khác nhau (ngoài ra, trình duyệt thường có thể ẩn độ trễ bằng cách chạy các thao tác đó trên một luồng riêng).

Nói theo cách khác, FID tập trung vào R (độ phản hồi) trong mô hình hiệu suất RAW, 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 cần đượ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. Ngoài ra, không phải tất cả các lượt tương tác đều liên quan đến FID (như đã đề cập trong phần trước). Ngoài ra, một số lượt tương tác đầu tiên của một số người dùng sẽ vào thời điểm không tốt (khi luồng chính bận trong một khoảng thời gian dài) và một số lượt tương tác đầu tiên của một số người dùng sẽ vào thời điểm tốt (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 sẽ 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ẽ khác một chút so với các chỉ số khác mà bạn đã quen thuộc. Phần tiếp theo sẽ 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ễ đầu vào?

Như đã đề cập ở trên, FID chỉ đo lường "độ trễ" trong quá trình xử lý sự kiện. Hàm này không đo lường tổng thời lượng 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 các trình xử lý sự kiện.

Mặc dù khoảng thời gian này rất quan trọng đối với người dùng và ả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 lệnh gọi lại không đồng bộ (thông qua setTimeout() hoặc requestAnimationFrame()) để tách biệt với tác vụ liên quan đến sự kiện. Kết quả sẽ giúp cải thiện điểm chỉ số 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 phần "độ trễ" của độ trễ sự kiện, nhưng các nhà phát triển muốn theo dõi thêm vòng đời sự kiện có thể thực hiện việc này bằng cách 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.

Cách đo lường FID

FID là một chỉ số chỉ có thể đo lường tại trường, vì chỉ số này yêu cầu một người dùng thực sự 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 các công cụ sau.

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

Đo lường FID trong JavaScript

Để đo lường FID trong JavaScript, bạn có thể sử dụng Event Timing API (API tính thời gian sự kiện). Ví dụ sau đây cho thấy cách tạo một PerformanceObserver để theo dõi các mục nhập first-input và ghi lại các mục nhập đó 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});

Cảnh báo: Mã này cho biết cách ghi lại các mục nhập first-input vào bảng điều khiển và tính toán độ trễ của các mục nhập đó. Tuy nhiên, việc đo lường FID trong JavaScript phức tạp hơn. Xem thông tin chi tiết bên dưới:

Trong ví dụ trên, giá trị độ trễ của mục first-input được đo lường bằng cách lấy delta giữa các dấu thời gian startTime và processingStart của mục nhập. 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 đều hợp lệ để đo lường FID.

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

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

API sẽ gửi các mục 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 này cũng sẽ gửi các mục nhập first-input nếu trang đã chạy ở chế độ nền trước khi xảy ra hoạt động đầu vào đầu tiên, nhưng các trang đó cũng nên bị bỏ qua khi tính toán 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 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 được đo lường trong những trường hợp này vì người dùng trải nghiệm chúng dưới dạng các 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ố này lại báo cáo vì dữ liệu đầu vào là một phần của 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 cân nhắc những yếu tố này. Khung con 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.

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

Do sự khác biệt dự kiến trong 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 mức phân phối của 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ể là 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 trải nghiệm đặc biệt xấu mà người dùng gặp phải đầu tiên với trang web của bạn. Báo cáo này sẽ chỉ cho bạn 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ị. Ví dụ: nếu bạn chạy các báo cáo riêng biệt 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–99 của người dùng máy tính, còn 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–99 của người dùng thiết bị di động.

Cách cải thiện FID

Chúng tôi có hướng dẫn đầy đủ về cách tối ưu hoá FID để hướng dẫn bạn các kỹ thuật 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 các thay đổi và những thay đổi này có thể xuất hiện dưới dạng điểm cải thiện hoặc điểm hồi quy trong các báo cáo và trang tổng quan nội bộ.

Để 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.