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 ban đầu. Điều này rất quan trọng khi bạn gặp gỡ những người mới và cũng quan trọng khi bạn xây dựng trải nghiệm trên web.

Trên web, ấn tượng tốt ban đầu có thể quyết định việc một người nào đó trở thành người dùng trung thành hay 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 một ấn tượng tốt và làm cách nào để đ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ể xuất hiện dưới 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 thị giác của một 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 các 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 khó!

Ấn tượng ban đầu của người dùng về tốc độ tải trang web của bạn có thể được đo bằng chỉ số Hiển thị nội dung đầu tiên (FCP). Tuy nhiên, tốc độ mà trang web của bạn có thể hiển thị 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à mức độ phản hồi của trang web khi người dùng cố gắng tương tác với những 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 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 chế độ 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 hành động 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ới hạn Độ trễ đầu vào đầu tiên ở mức 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 số lượt tải trang, được phân đoạn trên thiết bị di động và máy tính.

Chi tiết về 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 rằng mã của mình sẽ được chạy ngay lập tức – 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 ta đều 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 đó và sau đó cảm thấy thất vọng khi không có gì xảy ra.

Nhìn chung, độ 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, nên không thể (chưa thể) phản hồi người dùng. Một lý do phổ biến dẫn đến tình trạng này là do 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 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 trình duyệt làm việc khác.

Hãy xem xét dòng thời gian sau đây của một lần tải trang web thông thường:

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 đối với 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 xuống 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 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 đầu tiên dài thường xảy ra trong khoảng thời gian từ Nội dung đầu tiên hiển thị (FCP) đến 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 dòng thời gian:

Bạn có thể nhận thấy rằng có một khoảng thời gian khá dài (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ó một độ 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 nhiệm vụ dài nhất:

Vì hoạt động nhập xảy ra 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 hoạt động nhập. Thời gian mà người dùng phải đợi 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 hoạt động tương tác không có trình nghe sự kiện?

FID đo lường độ trễ giữa thời điểm nhận được một 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à vì 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ó yêu cầu 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 đều 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 kiểm 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 đầu vào đầu tiên?

Mặc dù độ trễ của mọi dữ liệu đầu vào đều có thể dẫn đến trải nghiệm người dùng kém, nhưng chúng tôi chủ yếu đề xuất đo độ 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 của bạn. Ấn tượng đầu tiên đóng vai trò quan trọng trong việc định hình ấn tượng tổng thể của chúng ta về chất lượng và độ tin cậy của một trang web.
• Vấn đề lớn nhất về khả năng tương tác mà chúng tôi nhận 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 ban đầu vào cải thiện tương tác đầu tiên của người dùng lần đầu 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 được đề xuất về cách trang web nên khắc phục độ trễ đầu vào ban đầu cao (phân chia mã, tải ít JavaScript hơn ngay từ đầu, v.v.) không nhất thiết phải là các giải pháp giống nhau để 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 các nhà phát triển web.

Đầu vào đầu tiên là gì?

FID là một chỉ số đo lường khả năng phản hồi của trang trong quá trình tải. Do đó, nó 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ư thao tác cuộn và thu phóng, là các thao tác liên tục và có những hạn chế hoàn toàn khác về hiệu suất (ngoài ra, trình duyệt thường có thể ẩn độ trễ bằng cách chạy các thao tác này trên một luồng riêng).

Nói 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 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 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. 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 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 biệt 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. Nó không đo lường tổng thời gian xử lý sự kiện hoặc 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ù 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 đó có thể khuyến khích nhà phát triển thêm các giải pháp thay thế thực sự làm giảm trải nghiệm – tức là họ có thể bao bọc 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ụ được liên kết với sự kiện. Kết quả là điểm số chỉ số sẽ được cải thiện nhưng người dùng sẽ cảm thấy phản hồi chậm hơn.

Tuy nhiên, trong khi FID chỉ đo lường phần "độ trễ" của độ trễ sự kiện, thì những nhà phát triển muốn theo dõi thêm về vòng đời sự kiện có thể làm như vậy bằng cách sử dụng Event Timing API. 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 trong trường, vì chỉ số này yêu cầu 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ụ thực địa

• Báo cáo trải nghiệm người dùng trên Chrome
• PageSpeed Insights
• Search Console (báo cáo Core Web Vitals)
• web-vitals Thư viện JavaScript

Đo lường FID bằng JavaScript

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

Phần sau đây liệt kê những điểm khác biệt giữa những gì 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 first-input cho những trang được tải trong thẻ nền nhưng bạn nên bỏ qua những trang đó khi tính FID.
• API cũng sẽ gửi các mục nhập first-input nếu trang được chuyển xuống nền trước khi xảy ra lượt nhập đầu tiên, nhưng bạn cũng nên bỏ qua những trang đó khi tính FID (chỉ xem xét các lượt nhập nếu trang ở nền trước trong 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 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 các dữ liệu đầu vào xảy ra trong iframe, nhưng chỉ số này thì có vì chúng là một phần trong trải nghiệm người dùng của trang. Điều này có thể hiển thị dưới dạng sự khác biệt giữa CrUX và RUM. Để đo lường FID một cách chính xác, bạn nên cân nhắc những yếu tố này. Khung phụ có thể sử dụng API này để báo cáo các mục 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 về FID

Do sự khác biệt dự kiến về giá trị FID, điều quan trọng là khi báo cáo về FID, bạn phải xem xét việc 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 về phân vị cho tất cả các ngưỡng Chỉ số quan trọng chính của trang web là phân vị thứ 75, nhưng đặc biệt đối với FID, chúng tôi vẫn thực sự khuyên bạn nên xem xét phân vị thứ 95 đến 99, vì những 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 đang gặp phải với trang web của bạn. Và nó sẽ cho bạn biết những lĩnh vực cần cải thiện nhiều nhất.

Điều này vẫn đú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 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 – 99 của người dùng thiết bị di động.

Cách cải thiện FID

Bạn có thể tham khảo 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, các lỗi được phát hiện trong API dùng để đo lường chỉ số và đôi khi trong chính định nghĩa của 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 giảm trong các báo cáo và trang tổng quan nội bộ của bạn.

Để giúp bạn quản lý việc này, mọi thay đổi đối với việc 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ể cung cấp ý kiến phản hồi trong nhóm Google web-vitals-feedback.