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

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

Hongbo Song

Đầu năm nay, Nhóm Chỉ số tốc độ của Chrome đã chia sẻ một số mà chúng tôi đang cân nhắc cho một chỉ số phản hồi mới. Chúng tôi muốn thiết kế một chỉ số nắm bắt tốt hơn độ trễ hai đầu của từng sự kiện 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 một trang trong suốt thời gian hoạt động của trang.

Chúng tôi đã có rất nhiều tiến bộ về chỉ số này trong vài tháng qua và 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 như giới thiệu một vài tuỳ chọn tổng hợp cụ thể mà chúng tôi đang cân nhắc để đị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 phản hồi của nhà phát triển và chủ sở hữu trang web về lựa chọn nào sau đây thể hiện đúng nhất thông tin đầu vào tổng thể khả năng thích ứng của trang.

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

Khi xem xét, chỉ số Độ trễ đầu vào đầu tiên (FID) ghi lại độ trễ của độ trễ đầu vào. Tức là thời gian giữa khi người dùng tương tác với trang vào 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 phạm vi đó để nắm bắt được toàn bộ sự kiện thời lượng, từ hoạt động đầu vào ban đầu của người dùng cho đến khi khung tiếp theo được hiển thị sau tất cả các trình xử lý sự kiện đã chạy.

Chúng tôi cũng có kế hoạch đo lường lượt tương tác thay vì các sự kiện riêng lẻ. Lượt tương tác là các nhóm sự kiện được gửi đi trong 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 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 tối đa của sự kiện: độ trễ tương tác bằng thời lượng lớn nhất thời lượng sự kiện duy 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 của tất cả sự kiện thời lượng, bỏ qua mọi trùng lặp.

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

Có những ưu và nhược điểm của mỗi phương pháp tiếp cận và chúng tôi muốn thu thập thêm dữ liệu và phản hồi trước khi hoàn tất định nghĩa độ trễ.

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

Sau khi 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 là xác định điểm số tổng hợp cho một lượt truy cập trang, có thể chứa dữ liệu nhiều lượt tương tác.

Sau khi khám phá một số lựa chọn, chúng tôi đã thu hẹp các lựa chọn của mình xuống còn được trình bày trong phần sau, mỗi chiến lược mà chúng tôi hiện đang thu thập dữ liệu của người dùng thực trên Chrome. Chúng tôi dự định xuất bản các kết quả của phát hiện khi có thời gian để thu thập đủ dữ liệu, nhưng chúng tôi cũng đang tìm cách để nhận ý kiến phản hồi trực tiếp từ 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 kiể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, hãy xem xét một lượt truy cập trang ví dụ bao gồm 4 lượt tương tác:

Độ trễ tương tác kém nhất

Độ trễ tương tác riêng lẻ lớn nhất xảy ra trên một trang. Do ví dụ về tương tác được liệt kê ở trên, thì độ trễ tương tác kém nhất sẽ là 120 mili giây

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

Trải nghiệm người dùng nghiên cứu cho thấy người dùng có thể không nhận thấy độ trễ dưới ngưỡng nhất định như phủ định. 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:

Mỗi chiến lược 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 ví dụ về lượt truy cập trang ở trên, số tiền vượt ngân sách sẽ như sau:

Độ trễ của lượt tương tác kém nhất so với ngân sách

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

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

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

Độ trễ trung bình của tương tác so với ngân sách

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

Giá trị gần đúng có số lượng cao

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

• Cách 1: Theo dõi các lượt tương tác lớn nhất và lớn thứ hai qua 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 khỏi tập 50 trước đó và thêm tương tác lớn nhất từ tập 50 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 so với ngân sách.
• Cách 2: Tính toán 10 lượt tương tác lớn nhất so với ngân sách rồi chọn một từ danh sách đó tuỳ thuộc vào tổng số lượt tương tác. Cho trước N tổng số tương tác, chọn giá trị lớn nhất (N / 50 + 1) hoặc giá trị thứ 10 cho các trang có hơn 500 lượt tương tác.

Đo lường các lựa chọn này trong JavaScript

Bạn có thể sử dụng ví dụ về mã sau đây để xác định giá trị của biến ba chiến lược nêu trên. Lưu ý rằng chưa thể đo lường tổng số lượt tương tác trên một trang trong JavaScript, nên ví dụ này không bao gồm 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 gần đúng số lượng.

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});

Phản hồi

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

Gửi email mọi phản hồi chung về các phương pháp tiếp cận được nêu tại đây web-vitals-feedback Google bằng "[Chỉ số về mức độ phản ứng]" trong dòng tiêu đề. Chúng tôi thực sự đang tìm kiếm muốn lắng nghe suy nghĩ của bạn!