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 tốt ngay từ đầu. Điều này rất quan trọng khi gặp gỡ những 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 tốt ngay từ đầu có thể quyết định việc người dùng trở thành người dùng trung thành hay rời bỏ 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 ban đầu có thể có nhiều hình thức khác nhau – chúng ta có ấn tượng ban đầu về thiết kế và sức hấp dẫn hình ảnh của trang web cũng như ấn tượng ban đầu về tốc độ và khả năng phản hồi 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ó!

Bạn có thể đo lường ấn tượng ban đầu của người dùng về tốc độ tải trang web bằng Hiển thị nội dung đầu tiên (FCP). Tuy nhiên, tốc độ trang web của bạn có thể vẽ các pixel lên màn hình chỉ là một phần của 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 ban đầu của người dùng về khả năng tương tác và 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à bao nhiêu?

Để đem lại trải nghiệm tốt cho người dùng, các trang web nên cố gắng giảm độ trễ đầu vào đầu tiên xuống còn 100 mili giây trở xuống. Để đảm bảo bạn đang đạ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 số lượt tải trang, được phân đoạn trên thiết bị di động và máy tính.

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. Tuy nhiên, với tư cách là người dùng, chúng ta thường xuyên gặp phải trường hợp 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 đó, nhưng sau đó 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 do luồng chính của trình duyệt đang bận làm việc khác, vì vậy, luồng này (chưa) 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 khi thực hiện việc đó, trình duyệt không thể chạy trình nghe sự kiện nào vì JavaScript đang tải có thể yêu cầu trình duyệt thực hiện một thao tác khác.

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

Hình ảnh trực quan ở 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à 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 các khoảng thời gian mà luồng chính tạm thời bận, được biểu thị bằng các khối tác vụ màu be.

Độ trễ đầu vào dài 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, FCP và TTI đã được thêm vào tiến trình:

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 đầu tác vụ dài nhất:

Vì dữ liệu đầ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 dữ liệu đầu vào. Thời gian phải chờ là giá trị FID của 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. Đ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à 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 cần luồng chính ở trạng thái rảnh để chạy.

Ví dụ: tất cả các phần tử HTML sau đây cần đợ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 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ù độ trễ từ bất kỳ đầ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 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ề 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 các nguyên tắc hiệu suất cụ thể hơn cho nhà phát triển web.

Giá trị nào được tính là giá trị đầu vào đầ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 đó, 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 quy tắc ràng buộc về 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 các thao tác đó trên một luồng riêng).

Nói cách khác, FID tập trung vào R (tính phản hồi) trong mô hình hiệu suất RAIL, trong khi thao tá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 các thao tác này phải được đánh giá riêng biệt.

Đ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 người dùng sẽ diễn ra vào thời điểm không phù hợp (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 người dùng sẽ diễn ra vào thời điểm phù hợp (khi luồng chính hoàn toàn rảnh).

Đ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 khá nhiều so với các chỉ số khác mà bạn có thể đã quen. 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. Chỉ số này không đo lường tổng thời gian xử lý sự kiện, cũng như thời gian 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ù thời gian này rất quan trọng đối với người dùng và có ảnh hưởng đến trải nghiệm, nhưng thời gian này không được đưa vào chỉ số này vì việc này có thể khuyến khích nhà phát triển thêm các giải pháp thực sự làm trải nghiệm trở nên tệ hơn. 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 logic đó khỏi tác vụ liên kết với sự kiện. Kết quả sẽ là điểm số của chỉ số được cải thiện nhưng tốc độ phản hồi chậm hơn theo nhận định 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 chi tiết.

Cách đo lường FID

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

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

• Báo cáo trải nghiệm người dùng trên Chrome
• PageSpeed Insights
• Search Console (báo cáo Các chỉ số quan trọng chính của trang web)
• 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 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});

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 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 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 bạn cũng nên bỏ qua các trang đó khi tính toán FID (hoạt động đầu vào chỉ được xem xét nếu trang ở chế độ nền trước trong 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 lui/tiến, nhưng bạn nên đo lường FID trong những trường hợp này vì người dùng sẽ trải nghiệm 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à phân vị thứ 75, nhưng đối với FID, bạn vẫn nên xem xét phân vị thứ 95–99, vì những phân vị này sẽ tương ứng với trải nghiệm ban đầu đặc biệt tệ mà người dùng có được với trang web của bạn. Đồng thời, báo cáo này 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ị. 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, chúng tôi phát hiện lỗi trong các API dùng để đo lường chỉ số và đôi khi là 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 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ả thay đổi đối với việc 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 có ý kiến phản hồi về các chỉ số này, bạn có thể gửi ý kiến đó trong nhóm Google web-vitals-feedback.