Tìm các hoạt động tương tác chậm trong trường

Tìm hiểu cách tìm các lượt tương tác chậm trong dữ liệu thực tế của trang web để bạn có thể tìm cơ hội cải thiện chỉ số Lượt tương tác đến nội dung hiển thị tiếp theo.

Jeremy Wagner

Dữ liệu thực tế là dữ liệu cho bạn biết trải nghiệm của người dùng thực tế trên trang web của bạn. Báo cáo này giúp bạn phát hiện những vấn đề mà bạn không thể tìm thấy chỉ bằng dữ liệu trong phòng thí nghiệm. Đối với Lượt tương tác đến nội dung hiển thị tiếp theo (INP), dữ liệu thực địa là yếu tố cần thiết để xác định các lượt tương tác chậm và cung cấp các manh mối quan trọng giúp bạn khắc phục các lượt tương tác đó.

Trong hướng dẫn này, bạn sẽ tìm hiểu cách nhanh chóng đánh giá INP của trang web bằng dữ liệu thực tế từ Báo cáo trải nghiệm người dùng trên Chrome (CrUX) để xem trang web của bạn có gặp vấn đề với INP hay không. Sau đó, bạn sẽ tìm hiểu cách sử dụng bản dựng phân bổ của thư viện JavaScript web-vitals—và thông tin chi tiết mới mà thư viện này cung cấp từ API Khung hoạt hoạ cần nhiều thời gian (LoAF)—để thu thập và diễn giải dữ liệu thực tế cho các lượt tương tác chậm trên trang web của bạn.

Bắt đầu bằng CrUX để đánh giá INP của trang web

Nếu bạn không thu thập dữ liệu thực tế tại trang từ người dùng trên trang web của mình, thì CrUX có thể là một điểm khởi đầu phù hợp. CrUX thu thập dữ liệu thực tế từ những người dùng Chrome thực tế đã chọn gửi dữ liệu đo từ xa.

Dữ liệu CrUX được hiển thị ở một số khu vực khác nhau và tuỳ thuộc vào phạm vi thông tin bạn đang tìm kiếm. CrUX có thể cung cấp dữ liệu về INP và các Core Web Vitals khác cho:

• Từng trang và toàn bộ nguồn gốc bằng PageSpeed Insights.
• Các loại trang. Ví dụ: nhiều trang web thương mại điện tử có các loại Trang chi tiết sản phẩm và Trang thông tin sản phẩm. Bạn có thể xem dữ liệu CrUX cho các loại trang riêng biệt trong Search Console.

Để bắt đầu, bạn có thể nhập URL của trang web vào PageSpeed Insights. Sau khi bạn nhập URL, dữ liệu thực tế của URL đó (nếu có) sẽ xuất hiện cho nhiều chỉ số, bao gồm cả INP. Bạn cũng có thể sử dụng nút bật/tắt để kiểm tra giá trị INP cho phương diện thiết bị di động và máy tính.

Dữ liệu này rất hữu ích vì cho bạn biết liệu bạn có gặp vấn đề hay không. Tuy nhiên, CrUX không thể cho bạn biết nguyên nhân gây ra vấn đề. Có nhiều giải pháp Giám sát người dùng thực (RUM) giúp bạn thu thập dữ liệu thực tế của riêng mình từ người dùng trang web để giúp bạn trả lời câu hỏi đó. Một lựa chọn là tự thu thập dữ liệu thực tế đó bằng thư viện JavaScript web-vitals.

Thu thập dữ liệu thực địa bằng thư viện JavaScript web-vitals

Thư viện JavaScript web-vitals là một tập lệnh mà bạn có thể tải trên trang web của mình để thu thập dữ liệu thực địa từ người dùng trang web. Bạn có thể sử dụng thư viện này để ghi lại một số chỉ số, bao gồm cả INP trong các trình duyệt hỗ trợ chỉ số này.

Bạn có thể dùng bản dựng tiêu chuẩn của thư viện web-vitals để lấy dữ liệu INP cơ bản từ người dùng trong thực tế:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  console.log(name);    // 'INP'
  console.log(value);   // 512
  console.log(rating);  // 'poor'
});

Để phân tích dữ liệu thực địa từ người dùng, bạn cần gửi dữ liệu này đến một nơi nào đó:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  // Prepare JSON to be sent for collection. Note that
  // you can add anything else you'd want to collect here:
  const body = JSON.stringify({name, value, rating});

  // Use `sendBeacon` to send data to an analytics endpoint.
  // For Google Analytics, see https://github.com/GoogleChrome/web-vitals#send-the-results-to-google-analytics.
  navigator.sendBeacon('/analytics', body);
});

Tuy nhiên, dữ liệu này không cung cấp nhiều thông tin hơn so với CrUX. Đó là lúc bạn cần dùng bản dựng phân bổ của thư viện web-vitals.

Tiến xa hơn với bản dựng phân bổ của thư viện web-vitals

Bản dựng phân bổ của thư viện Web Vitals hiển thị dữ liệu bổ sung mà bạn có thể nhận được từ người dùng trong thực tế để giúp bạn khắc phục sự cố tốt hơn các lượt tương tác có vấn đề đang ảnh hưởng đến INP của trang web. Bạn có thể truy cập vào dữ liệu này thông qua đối tượng attribution xuất hiện trong phương thức onINP() của thư viện:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, rating, attribution}) => {
  console.log(name);         // 'INP'
  console.log(value);        // 56
  console.log(rating);       // 'good'
  console.log(attribution);  // Attribution data object
});

Ngoài bản thân INP của trang, bản dựng phân bổ còn cung cấp nhiều dữ liệu mà bạn có thể sử dụng để hiểu lý do khiến lượt tương tác chậm, bao gồm cả phần tương tác mà bạn nên tập trung vào. Báo cáo này có thể giúp bạn trả lời những câu hỏi quan trọng như:

• "Người dùng có tương tác với trang trong khi trang đang tải không?"
• "Trình xử lý sự kiện của hoạt động tương tác có chạy trong thời gian dài không?"
• "Mã trình xử lý sự kiện tương tác có bị trì hoãn khi bắt đầu không? Nếu đúng, thì điều gì khác đang xảy ra trên luồng chính vào thời điểm đó?"
• "Hoạt động tương tác có gây ra nhiều công việc kết xuất khiến khung hình tiếp theo bị trì hoãn không?"

Bảng sau đây cho thấy một số dữ liệu phân bổ cơ bản mà bạn có thể lấy từ thư viện, giúp bạn tìm ra một số nguyên nhân cấp cao khiến lượt tương tác trên trang web của bạn bị chậm:

Kể từ phiên bản 4 của thư viện Web Vitals, bạn có thể hiểu rõ hơn về các lượt tương tác có vấn đề thông qua dữ liệu mà thư viện này cung cấp, cùng với thông tin chi tiết về giai đoạn INP (độ trễ đầu vào, thời gian xử lý và độ trễ hiển thị) và API Khung hoạt hoạ cần nhiều thời gian (LoAF).

API Khung hoạt hoạ cần nhiều thời gian (LoAF)

Việc gỡ lỗi các lượt tương tác bằng dữ liệu thực địa là một nhiệm vụ khó khăn. Tuy nhiên, nhờ dữ liệu từ LoAF, giờ đây bạn có thể hiểu rõ hơn về nguyên nhân gây ra các lượt tương tác chậm, vì LoAF cho thấy một số thời gian chi tiết và dữ liệu khác mà bạn có thể sử dụng để xác định chính xác nguyên nhân và quan trọng hơn là nguồn gốc của vấn đề nằm ở đâu trong mã của trang web.

Bản dựng phân bổ của thư viện web-vitals hiển thị một mảng các mục LoAF trong khoá longAnimationFrameEntries của đối tượng attribution. Bảng sau đây liệt kê một vài dữ liệu quan trọng mà bạn có thể tìm thấy trong mỗi mục LoAF:

Tất cả thông tin này có thể cho bạn biết nhiều điều về nguyên nhân khiến một lượt tương tác bị chậm, nhưng mảng scripts mà các mục LoAF hiển thị sẽ được đặc biệt quan tâm:

Mỗi mục trong mảng này chứa dữ liệu được trình bày trong bảng này, cung cấp cho bạn thông tin về tập lệnh chịu trách nhiệm cho lượt tương tác chậm và cách tập lệnh đó chịu trách nhiệm.

Đo lường và xác định các nguyên nhân phổ biến khiến hoạt động tương tác bị chậm

Để giúp bạn hình dung cách sử dụng thông tin này, hướng dẫn này sẽ trình bày cách bạn có thể sử dụng dữ liệu LoAF xuất hiện trong thư viện web-vitals để xác định một số nguyên nhân gây ra hoạt động tương tác chậm.

Thời gian xử lý dài

Thời lượng xử lý của một lượt tương tác là thời gian cần thiết để các lệnh gọi lại của trình xử lý sự kiện đã đăng ký của lượt tương tác đó chạy đến khi hoàn tất và mọi hoạt động khác có thể xảy ra giữa các lệnh gọi lại đó. Thư viện web-vitals sẽ hiển thị thời gian xử lý cao:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5
});

Thông thường, bạn sẽ nghĩ rằng nguyên nhân chính khiến một lượt tương tác bị chậm là do mã trình xử lý sự kiện mất quá nhiều thời gian để chạy, nhưng không phải lúc nào cũng vậy! Sau khi xác nhận rằng đây là vấn đề, bạn có thể tìm hiểu sâu hơn bằng dữ liệu LoAF:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5

  // Get the longest script from LoAF covering `processingDuration`:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Get attribution for the long-running event handler:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Như bạn có thể thấy trong đoạn mã trước, bạn có thể làm việc với dữ liệu LoAF để tìm ra nguyên nhân chính xác đằng sau một lượt tương tác có giá trị thời lượng xử lý cao, bao gồm:

• Phần tử và trình nghe sự kiện đã đăng ký của phần tử đó.
• Tệp tập lệnh (và vị trí ký tự trong tệp đó) chứa mã trình xử lý sự kiện chạy trong thời gian dài.
• Tên của hàm.

Loại dữ liệu này là vô giá. Bạn không cần phải tốn công tìm hiểu chính xác lượt tương tác nào (hoặc trình xử lý sự kiện nào) chịu trách nhiệm cho các giá trị thời lượng xử lý cao. Ngoài ra, vì các tập lệnh của bên thứ ba thường có thể đăng ký trình xử lý sự kiện của riêng chúng, nên bạn có thể xác định xem mã của bạn có chịu trách nhiệm hay không! Đối với mã mà bạn có quyền kiểm soát, bạn nên xem xét việc tối ưu hoá các tác vụ cần nhiều thời gian.

Độ trễ đầu vào dài

Mặc dù trình xử lý sự kiện chạy trong thời gian dài là phổ biến, nhưng vẫn có những phần khác của hoạt động tương tác cần xem xét. Một phần xảy ra trước thời gian xử lý, được gọi là độ trễ đầu vào. Đây là khoảng thời gian từ khi người dùng bắt đầu tương tác đến thời điểm lệnh gọi lại của trình xử lý sự kiện bắt đầu chạy và xảy ra khi luồng chính đang xử lý một tác vụ khác. Bản dựng phân bổ của thư viện web-vitals có thể cho bạn biết thời lượng của độ trễ đầu vào cho một lượt tương tác:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536
});

Nếu nhận thấy một số lượt tương tác có độ trễ đầu vào cao, thì bạn cần tìm hiểu xem điều gì đã xảy ra trên trang tại thời điểm tương tác gây ra độ trễ đầu vào dài. Điều này thường phụ thuộc vào việc lượt tương tác xảy ra khi trang đang tải hay sau đó.

Có phải trong khi tải trang không?

Luồng chính thường bận rộn nhất khi trang đang tải. Trong thời gian này, tất cả các loại tác vụ đều được đưa vào hàng đợi và xử lý. Nếu người dùng cố gắng tương tác với trang trong khi tất cả công việc này đang diễn ra, thì việc này có thể làm chậm hoạt động tương tác. Các trang tải nhiều JavaScript có thể bắt đầu công việc biên dịch và đánh giá tập lệnh, cũng như thực thi các hàm giúp trang sẵn sàng cho hoạt động tương tác của người dùng. Công việc này có thể gây cản trở nếu người dùng tương tác khi hoạt động này diễn ra. Bạn có thể tìm hiểu xem người dùng trang web của bạn có gặp phải trường hợp đó hay không:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Invoker types can describe if script eval blocked the main thread:
    const {invokerType} = script;    // 'classic-script' | 'module-script'
    const {sourceLocation} = script; // 'https://example.com/app.js'
  }
});

Nếu bạn ghi lại dữ liệu này trong trường và thấy độ trễ đầu vào cao cũng như các loại trình gọi là 'classic-script' hoặc 'module-script', thì có thể nói rằng các tập lệnh trên trang web của bạn mất nhiều thời gian để đánh giá và đang chặn luồng chính đủ lâu để trì hoãn các lượt tương tác. Bạn có thể giảm thời gian chặn này bằng cách chia nhỏ tập lệnh thành các gói nhỏ hơn, trì hoãn việc tải mã chưa dùng đến ban đầu sang thời điểm sau và kiểm tra trang web để tìm mã chưa dùng đến mà bạn có thể xoá hoàn toàn.

Có phải sau khi tải trang không?

Mặc dù độ trễ đầu vào thường xảy ra trong khi trang đang tải, nhưng cũng có thể xảy ra sau khi trang đã tải, do một nguyên nhân hoàn toàn khác. Nguyên nhân phổ biến gây ra độ trễ đầu vào sau khi tải trang có thể là do mã chạy định kỳ do lệnh gọi setInterval trước đó hoặc thậm chí là lệnh gọi lại sự kiện được đưa vào hàng đợi để chạy sớm hơn và vẫn đang xử lý.

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  if (script) {
    const {invokerType} = script;        // 'user-callback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Tương tự như trường hợp khắc phục sự cố về giá trị thời lượng xử lý cao, độ trễ đầu vào cao do các nguyên nhân nêu trên sẽ cung cấp cho bạn dữ liệu chi tiết về hoạt động phân bổ tập lệnh. Tuy nhiên, điểm khác biệt là loại trình gọi sẽ thay đổi dựa trên bản chất của công việc đã trì hoãn hoạt động tương tác:

• 'user-callback' cho biết tác vụ chặn là từ setInterval, setTimeout hoặc thậm chí là requestAnimationFrame.
• 'event-listener' cho biết tác vụ chặn là từ một dữ liệu đầu vào trước đó đã được đưa vào hàng đợi và vẫn đang xử lý.
• 'resolve-promise' và 'reject-promise' có nghĩa là tác vụ chặn bắt nguồn từ một số công việc không đồng bộ được bắt đầu sớm hơn, đồng thời được giải quyết hoặc từ chối tại thời điểm người dùng cố gắng tương tác với trang, khiến hoạt động tương tác bị trì hoãn.

Trong mọi trường hợp, dữ liệu phân bổ tập lệnh sẽ cho bạn biết nên bắt đầu tìm từ đâu và liệu độ trễ đầu vào là do mã của riêng bạn hay do tập lệnh của bên thứ ba.

Độ trễ khi trình bày dài

Độ trễ hiển thị là giai đoạn cuối cùng của một lượt tương tác, bắt đầu khi trình xử lý sự kiện của lượt tương tác kết thúc, cho đến thời điểm khung hình tiếp theo được vẽ. Những thay đổi này xảy ra khi công việc trong trình xử lý sự kiện do một hoạt động tương tác làm thay đổi trạng thái hình ảnh của giao diện người dùng. Cũng như thời lượng xử lý và độ trễ đầu vào, thư viện web-vitals có thể cho bạn biết độ trễ hiển thị của một lượt tương tác:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691
});

Nếu bạn ghi lại dữ liệu này và thấy độ trễ hiển thị cao đối với các lượt tương tác góp phần vào INP của trang web, thì thủ phạm có thể khác nhau, nhưng dưới đây là một số nguyên nhân cần lưu ý.

Công việc bố cục và kiểu tốn kém

Sự chậm trễ kéo dài trong quá trình trình bày có thể là do công việc tính toán lại kiểu và bố cục tốn kém, phát sinh từ một số nguyên nhân, bao gồm cả bộ chọn CSS phức tạp và kích thước DOM lớn. Bạn có thể đo lường thời lượng của công việc này bằng thời gian LoAF xuất hiện trong thư viện web-vitals:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  // Get necessary timings:
  const {startTime} = loaf; // 2120.5
  const {duration} = loaf;  // 1002

  // Figure out the ending timestamp of the frame (approximate):
  const endTime = startTime + duration; // 3122.5

  // Get the start timestamp of the frame's style/layout work:
  const {styleAndLayoutStart} = loaf; // 3011.17692309

  // Calculate the total style/layout duration:
  const styleLayoutDuration = endTime - styleAndLayoutStart; // 111.32307691

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running style and layout operation:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

LoAF sẽ không cho bạn biết thời lượng của kiểu và bố cục cho một khung hình, nhưng sẽ cho bạn biết thời điểm bắt đầu. Với dấu thời gian bắt đầu này, bạn có thể sử dụng dữ liệu khác từ LoAF để tính toán thời lượng chính xác của công việc đó bằng cách xác định thời gian kết thúc của khung hình và trừ đi dấu thời gian bắt đầu của công việc về kiểu và bố cục.

Lệnh gọi lại requestAnimationFrame chạy trong thời gian dài

Một nguyên nhân có thể gây ra độ trễ hiển thị dài là do thực hiện quá nhiều công việc trong lệnh gọi lại requestAnimationFrame. Nội dung của lệnh gọi lại này được thực thi sau khi trình xử lý sự kiện chạy xong, nhưng ngay trước khi tính toán lại kiểu và bố cục.

Các lệnh gọi lại này có thể mất nhiều thời gian để hoàn tất nếu công việc được thực hiện trong đó phức tạp. Nếu nghi ngờ giá trị độ trễ hiển thị cao là do công việc bạn đang thực hiện với requestAnimationFrame, bạn có thể sử dụng dữ liệu LoAF do thư viện web-vitals hiển thị để xác định các trường hợp sau:

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 543.1999999880791

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.toSorted((a, b) => b.duration - a.duration)[0];

  // Get the render start time and when style and layout began:
  const {renderStart} = loaf;         // 2489
  const {styleAndLayoutStart} = loaf; // 2989.5999999940395

  // Calculate the `requestAnimationFrame` callback's duration:
  const rafDuration = styleAndLayoutStart - renderStart; // 500.59999999403954

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running requestAnimationFrame callback:
    const {invokerType} = script;        // 'user-callback'
    const {invoker} = script;            // 'FrameRequestCallback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

Nếu bạn thấy rằng một phần đáng kể thời gian trễ khi trình bày được dành cho lệnh gọi lại requestAnimationFrame, hãy đảm bảo công việc bạn đang thực hiện trong các lệnh gọi lại này chỉ giới hạn ở việc thực hiện công việc dẫn đến bản cập nhật thực tế cho giao diện người dùng. Bất kỳ công việc nào khác không chạm vào DOM hoặc cập nhật kiểu sẽ làm chậm khung hình tiếp theo một cách không cần thiết, vì vậy hãy cẩn thận!

Kết luận

Dữ liệu thực địa là nguồn thông tin tốt nhất mà bạn có thể dựa vào để hiểu được những lượt tương tác nào gây rắc rối cho người dùng thực tế trong thực địa. Bằng cách dựa vào các công cụ thu thập dữ liệu thực địa như thư viện JavaScript web-vitals (hoặc nhà cung cấp RUM), bạn có thể tự tin hơn về những lượt tương tác có vấn đề nhất, sau đó chuyển sang tái tạo các lượt tương tác có vấn đề trong phòng thí nghiệm rồi tiến hành khắc phục.