Mong muốn có ý kiến phản hồi: Một chỉ số thử nghiệm về khả năng phản hồi

Cập nhật về kế hoạch đo lường khả năng phản hồi trên web.

Hongbo Song

Lưu ý quan trọng: Bài viết này được viết trong khoảng thời gian chúng tôi đang phát triển một chỉ số mới về khả năng phản hồi để đo lường độ trễ toàn diện trên các trang web. Chỉ số mới này đã được phát hành và có tên là Lượt tương tác với nội dung hiển thị tiếp theo (INP). Vào ngày 12 tháng 3 năm 2024, INP trở thành Chỉ số quan trọng chính của trang web, thay thế FID.

Đầu năm nay, Nhóm chỉ số tốc độ của Chrome đã chia sẻ một số ý tưởng mà chúng tôi đang cân nhắc về chỉ số phản hồi mới. Chúng tôi muốn thiết kế một chỉ số có thể ghi nhận chính xác hơn độ trễ toàn diện của từng sự kiện riêng lẻ và cung cấp thông tin toàn diện hơn về khả năng phản hồi tổng thể của trang trong suốt thời gian hoạt động.

Chúng tôi đã đạt được rất nhiều tiến bộ về chỉ số này trong vài tháng qua. Chúng tôi muốn chia sẻ thông tin cập nhật về cách chúng tôi dự định đo lường độ trễ tương tác cũng như giới thiệu một số tuỳ chọn tổng hợp cụ thể mà chúng tôi đang xem xét để định lượng khả năng phản hồi tổng thể của trang web.

Chúng tôi muốn nhận được ý kiến phản hồi của các nhà phát triển và chủ sở hữu trang web về việc lựa chọn nào trong số này thể hiện rõ nhất mức độ phản hồi tổng thể khi người dùng nhập thông tin trên các trang của họ.

Đo lường độ trễ tương tác

Khi xem xét, chỉ số Thời gian phản hồi lần tương tác đầu tiên (FID) ghi lại phần độ trễ của độ trễ đầu vào. Tức là khoảng thời gian từ khi người dùng tương tác với trang đến thời điểm trình xử lý sự kiện có thể chạy.

Với chỉ số mới này, chúng tôi dự định mở rộng chỉ số đó để nắm bắt toàn bộ thời lượng sự kiện, từ hoạt động đầu vào ban đầu của người dùng cho đến khi khung tiếp theo được vẽ sau khi tất cả các trình xử lý sự kiện đã chạy.

Chúng tôi cũng dự định đo lường số lượt tương tác thay vì các sự kiện riêng lẻ. Tương tác là các nhóm sự kiện được gửi như một phần của cùng một cử chỉ logic của người dùng (ví dụ: pointerdown, click, pointerup).

Để đo lường tổng độ trễ tương tác từ một nhóm thời lượng sự kiện riêng lẻ, chúng tôi đang xem xét hai phương pháp tiềm năng:

• Thời lượng sự kiện tối đa: độ trễ tương tác bằng với thời lượng sự kiện đơn lẻ lớn nhất từ bất kỳ sự kiện nào trong nhóm tương tác.
• Tổng thời lượng sự kiện: độ trễ tương tác là tổng tất cả thời lượng sự kiện, bỏ qua mọi sự trùng lặp.

Ví dụ: sơ đồ dưới đây cho thấy hoạt động tương tác nhấn phím bao gồm một sự kiện keydown và keyup. Trong ví dụ này, có sự trùng lặp về thời lượng giữa hai sự kiện này. Để đo lường độ trễ của hoạt động tương tác nhấn phím, chúng ta có thể sử dụng max(keydown duration, keyup duration) hoặc sum(keydown duration, keyup duration) - duration overlap:

Mỗi phương pháp đều có ưu và nhược điểm riêng. Chúng tôi muốn thu thập thêm dữ liệu cũng như ý kiến phản hồi trước khi hoàn thiện định nghĩa về độ trễ.

Lưu ý: Thời lượng sự kiện là khoảng thời gian từ dấu thời gian phần cứng của sự kiện cho đến thời điểm thực hiện thao tác vẽ tiếp theo sau khi sự kiện được xử lý. Tuy nhiên, nếu sự kiện này không gây ra bất kỳ cập nhật nào, thì khoảng thời gian sẽ là khoảng thời gian tính từ dấu thời gian phần cứng của sự kiện cho đến khi chúng tôi chắc chắn sự kiện đó sẽ không gây ra bất kỳ lượt cập nhật nào.

Lưu ý: Đối với các hoạt động tương tác với bàn phím, chúng tôi thường đo lường keydown và keyup. Tuy nhiên, đối với IME, chẳng hạn như phương thức nhập cho tiếng Trung và tiếng Nhật, chúng tôi đo lường các sự kiện input giữa compositionstart và compositionend.

Tổng hợp tất cả lượt tương tác trên mỗi trang

Khi chúng ta có thể đo lường độ trễ toàn diện của tất cả các lượt tương tác, bước tiếp theo là xác định điểm tổng hợp cho một lượt truy cập trang có thể chứa nhiều lượt tương tác.

Sau khi tìm hiểu một số lựa chọn, chúng tôi đã thu hẹp các lựa chọn của mình thành các chiến lược được nêu trong phần sau. Mỗi chiến lược mà chúng tôi hiện đang thu thập dữ liệu người dùng thực trong Chrome. Chúng tôi dự định công bố kết quả tìm kiếm sau khi có thời gian thu thập đủ dữ liệu. Tuy nhiên, chúng tôi cũng muốn nhận được ý kiến phản hồi trực tiếp của chủ sở hữu trang web về chiến lược nào sẽ phản ánh chính xác nhất các mẫu tương tác trên các trang của họ.

Các lựa chọn về chiến lược tổng hợp

Để giúp giải thích từng chiến lược sau đây, hãy xem xét một ví dụ về lượt truy cập trang bao gồm 4 tương tác:

Tương tác	Độ trễ
Nhấp	120 mili giây
Nhấp	20 mili giây
Nhấn phím	60 mili giây
Nhấn phím	80 mili giây

Độ trễ tương tác thấp nhất

Độ trễ tương tác riêng lẻ lớn nhất xảy ra trên một trang. Với các hoạt động tương tác mẫu liệt kê ở trên, độ trễ tương tác xấu nhất sẽ là 120 mili giây.

Chiến lược ngân sách

Nghiên cứu về trải nghiệm người dùng cho thấy rằng người dùng có thể không coi độ trễ dưới một số ngưỡng nhất định là số âm. Dựa trên nghiên cứu này, chúng tôi đang xem xét một số chiến lược ngân sách dựa trên các ngưỡng sau cho từng loại sự kiện:

Loại tương tác	Ngưỡng ngân sách
Nhấp/nhấn	100 mili giây
Phương trình lực cản	100 mili giây
Bàn phím	50 mili giây

Mỗi chiến lược trong số này sẽ chỉ xem xét độ trễ lớn hơn ngưỡng ngân sách cho mỗi lượt tương tác. Sử dụng lượt truy cập trang ví dụ ở trên, số tiền vượt ngân sách sẽ như sau:

Tương tác	Độ trễ	Độ trễ vượt ngân sách
Nhấp	120 mili giây	20 mili giây
Nhấp	20 mili giây	0 mili giây
Nhấn phím	60 mili giây	10 mili giây
Nhấn phím	80 mili giây	30 mili giây

Độ trễ tương tác thấp nhất vượt quá ngân sách

Độ trễ của một lượt tương tác lớn nhất vượt ngân sách. Trong ví dụ trên, điểm số sẽ là max(20, 0, 10, 30) = 30 ms.

Tổng độ trễ tương tác vượt ngân sách

Tổng của tất cả các độ trễ tương tác vượt quá ngân sách. Trong ví dụ trên, điểm số sẽ là (20 + 0 + 10 + 30) = 60 ms.

Độ trễ tương tác trung bình vượt ngân sách

Tổng độ trễ tương tác vượt ngân sách chia cho tổng số lượt tương tác. Trong ví dụ trên, điểm số sẽ là (20 + 0 + 10 + 30) / 4 = 15 ms.

Giá trị gần đúng số phân vị cao

Thay vì tính toán độ trễ tương tác lớn nhất trong phạm vi ngân sách, chúng tôi cũng cân nhắc việc sử dụng phép ước tính số lượng cao, phương pháp này sẽ công bằng hơn đối với các trang web có nhiều lượt tương tác và có nhiều khả năng có mức chênh lệch lớn. Chúng tôi đã xác định hai chiến lược gần đúng lượng lượng cao tiềm năng mà chúng tôi muốn:

• Lựa chọn 1: Theo dõi các lượt tương tác lớn nhất và lớn thứ hai, vượt ngân sách. Sau mỗi 50 lượt tương tác mới, hãy bỏ lượt tương tác lớn nhất từ tập hợp 50 lượt tương tác trước đó và thêm lượt tương tác lớn nhất từ tập hợp 50 lượt tương tác hiện tại. Giá trị cuối cùng sẽ là lượt tương tác còn lại lớn nhất vượt quá ngân sách.
• Lựa chọn 2: Tính toán 10 lượt tương tác lớn nhất theo ngân sách, rồi chọn một giá trị từ danh sách đó tuỳ thuộc vào tổng số lượt tương tác. Với tổng số lượt tương tác N, hãy chọn giá trị lớn nhất thứ 10 (N / 50 + 1) hoặc giá trị thứ 10 đối với các trang có hơn 500 lượt tương tác.

Đo lường các tuỳ chọn này trong JavaScript

Bạn có thể sử dụng mã ví dụ sau đây để xác định giá trị của 3 chiến lược đầu tiên như trình bày ở trên. Xin lưu ý rằng hệ thống chưa thể đo lường tổng số lượt tương tác trên một trang bằng JavaScript. Vì vậy, ví dụ này không bao gồm số lượt tương tác trung bình so với chiến lược ngân sách hoặc chiến lược ước lượng số lượng cao.

const interactionMap = new Map();

let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;

new PerformanceObserver((entries) => {
  for (const entry of entries.getEntries()) {
    // Ignore entries without an interaction ID.
    if (entry.interactionId > 0) {
      // Get the interaction for this entry, or create one if it doesn't exist.
      let interaction = interactionMap.get(entry.interactionId);
      if (!interaction) {
        interaction = {latency: 0, entries: []};
        interactionMap.set(entry.interactionId, interaction);
      }
      interaction.entries.push(entry);

      const latency = Math.max(entry.duration, interaction.latency);
      worstLatency = Math.max(worstLatency, latency);

      const budget = entry.name.includes('key') ? 50 : 100;
      const latencyOverBudget = Math.max(latency - budget, 0);
      worstLatencyOverBudget = Math.max(
        latencyOverBudget,
        worstLatencyOverBudget,
      );

      if (latencyOverBudget) {
        const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
        totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
      }

      // Set the latency on the interaction so future events can reference.
      interaction.latency = latency;

      // Log the updated metric values.
      console.log({
        worstLatency,
        worstLatencyOverBudget,
        totalLatencyOverBudget,
      });
    }
  }
  // Set the `durationThreshold` to 50 to capture keyboard interactions
  // that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});

Thận trọng: Hiện tại, Chrome có một số lỗi ảnh hưởng đến độ chính xác của dấu thời gian tương tác được báo cáo. Những lỗi này đã được khắc phục trong phiên bản 98. Vì vậy, nhà phát triển nên thử nghiệm các chiến lược này trong Chrome Canary để có kết quả chính xác nhất.

Ý kiến phản hồi

Chúng tôi muốn khuyến khích các nhà phát triển dùng thử các chỉ số mới về khả năng phản hồi này trên trang web của họ và cho chúng tôi biết nếu bạn phát hiện thấy bất kỳ vấn đề nào.

Gửi mọi ý kiến phản hồi chung về các phương pháp được nêu tại đây tới nhóm web-vitals-feedback của Google kèm theo "[Chỉ số về mức độ phản hồi]" trong dòng tiêu đề. Chúng tôi rất mong được lắng nghe ý kiến của bạn!