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 trường của trang web để có thể tìm ra cơ hội cải thiện chỉ số Hoạt động tương tác với lần hiển thị tiếp theo.

Jeremy Wagner

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

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 cách sử dụng dữ liệu trường trong Báo cáo trải nghiệm người dùng trên Chrome (CrUX) để xem liệu trang web của bạn có gặp vấn đề về INP hay không. Tiếp theo, 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ừ Long Animation Frames API (LoAF) để thu thập và diễn giải dữ liệu trường cho các lượt tương tác chậm trên trang web của bạn.

Bắt đầu với 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 trang web, 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 sự đã chọn gửi dữ liệu đo từ xa.

Dữ liệu CrUX xuất hiện ở một số khu vực, tuỳ thuộc vào phạm vi của thông tin bạn đang tìm kiếm. CrUX có thể cung cấp dữ liệu về INP và các chỉ số quan trọng khác của trang web cho:

• Các trang riêng lẻ và toàn bộ nguồn gốc bằng PageSpeed Insights.
• 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 trường cho 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 các 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 điều gì đang gây ra sự cố. Có nhiều giải pháp Giám sát người dùng thực (RUM) có thể giúp bạn thu thập dữ liệu trường của riêng mình từ người dùng trang web để trả lời câu hỏi đó. Một lựa chọn là tự thu thập dữ liệu trường đó bằng cách sử dụng thư viện JavaScript web-vitals.

Thu thập dữ liệu trường bằng thư viện JavaScript web-vitals

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

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

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 trường của bạn từ người dùng, bạn sẽ muốn gửi dữ liệu này đến 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 cho bạn biết nhiều thông tin hơn so với CrUX. Đó là lúc bạn cần đến bản dựng phân bổ của thư viện web-vitals.

Khám phá thêm 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 hiệu quả 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 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 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 bị 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 các câu hỏi quan trọng như:

• "Người dùng có tương tác với trang trong khi đ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 có, thì tại thời điểm đó, luồng chính còn đang diễn ra điều gì khác?"
• "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ể nhận được từ thư viện. Dữ liệu này có thể giúp bạn tìm hiểu một số nguyên nhân chính khiến lượt tương tác trên trang web bị chậm:

Kể từ phiên bản 4 của thư viện web-vitals, bạn có thể nhận được thông tin chi tiết hơn nữa 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 theo giai đoạn INP (độ trễ đầu vào, thời lượng xử lý và độ trễ trình bày) và API Khung ảnh động dài (LoAF).

API Khung ảnh động dài (LoAF)

Gỡ lỗi tương tác bằng dữ liệu trường là một nhiệm vụ đầy thách thức. Tuy nhiên, với dữ liệu từ LoAF, giờ đây, bạn có thể hiểu rõ hơn về nguyên nhân gây ra tình trạng 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à vị trí của nguồn sự cố trong mã 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 nhập LoAF trong khoá longAnimationFrameEntries của đối tượng attribution. Bảng sau đây liệt kê một số dữ liệu chính mà bạn có thể tìm thấy trong mỗi mục nhập LoAF:

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

Mỗi mục trong mảng này chứa dữ liệu hiển thị 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 hoạt động tương tác chậm và mức độ chịu trách nhiệm của tập lệnh đó.

Đo lường và xác định các nguyên nhân phổ biến gây ra tình trạng tương tác chậm

Để giúp bạn biết cách sử dụng thông tin này, hướng dẫn này giờ 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 tình trạng tương tác chậm.

Thời gian xử lý dài

Thời gian 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 trình xử lý sự kiện đã đăng ký của tương tác chạy đến khi hoàn tất và bất kỳ điều gì khác có thể xảy ra giữa các lệnh gọi lại đó. Thư viện web-vitals hiển thị thời lượng xử lý cao:

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

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

Bạn có thể nghĩ rằng nguyên nhân chính dẫn đến việc tương tác chậm là do mã trình xử lý sự kiện của bạn mất quá nhiều thời gian để chạy, nhưng điều này không phải lúc nào cũng đúng! 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.sort((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ể xử lý 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 rất có giá trị. Bạn không cần phải tự tìm hiểu xem chính xác hoạt động tương tác nào hoặc trình xử lý sự kiện nào chịu trách nhiệm về các giá trị thời lượng xử lý cao nữa. 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 mình, nên bạn có thể xác định xem mã của mình 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 tìm hiểu cách tối ưu hoá các tác vụ dài.

Độ 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 bạn cũng cần xem xét các phần khác của hoạt động tương tác. Một phần xảy ra trước thời lượng xử lý, còn 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 cho đến thời điểm lệnh gọi lại 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 độ 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ì đang xảy ra trên trang tại thời điểm tương tác gây ra độ trễ đầu vào lâu. Điều này thường tóm gọn là liệu lượt tương tác có xảy ra khi trang đang tải hay sau đó.

Lỗi này có xảy ra trong khi tải trang không?

Luồng chính thường bận rộn nhất khi một trang đang tải. Trong thời gian này, tất cả các loại tác vụ đang được xếp hàng đợi cũng như được xử lý và nếu người dùng cố tương tác với trang trong khi tất cả công việc này đang diễn ra, điều đó có thể làm chậm 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 các hoạt động tương tác của người dùng. Công việc này có thể gây trở ngại nếu người dùng tình cờ 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 mình 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.sort((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 và 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 đang 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 các tập lệnh thành các gói nhỏ hơn, trì hoãn việc tải mã không dùng đến ban đầu vào một thời điểm khác và kiểm tra trang web của bạn để tìm mã không 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 xong, do một nguyên nhân hoàn toàn khác. Các nguyên nhân phổ biến gây ra độ trễ đầu vào sau khi tải trang có thể là mã chạy định kỳ do lệnh gọi setInterval trước đó hoặc thậm chí là các lệnh gọi lại sự kiện đã được xếp hàng đợi để chạy trước đó 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.sort((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'
  }
});

Giống 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 được đề cập trước đó sẽ cung cấp cho bạn dữ liệu phân bổ tập lệnh chi tiết. Tuy nhiên, điểm khác biệt là loại phương thức 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 bắt nguồn 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 là từ một số công việc không đồng bộ đã bắt đầu trước đó và được giải quyết hoặc bị từ chối tại thời điểm người dùng cố gắng tương tác với trang, làm chậm quá trình tương tác.

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 ở đâu và liệu độ trễ đầu vào có phải là do mã của riêng bạn hay của tập lệnh bên thứ ba.

Độ trễ khi trình bày lâu

Độ trễ trình bày là chặng cuối cùng của một tương tác và bắt đầu khi trình xử lý sự kiện của tương tác kết thúc, tới thời điểm khung tiếp theo được vẽ. Chúng xảy ra khi công việc trong trình xử lý sự kiện do một lượt 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 đóng góp vào INP của trang web, thì nguyên nhân có thể khác nhau, nhưng sau đây là một số nguyên nhân cần lưu ý.

Chi phí cao cho việc thiết kế kiểu và bố cục

Việc trình bày bị trễ lâu có thể là do 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.sort((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 công việc về kiểu và bố cục cho một khung, nhưng sẽ cho bạn biết thời điểm bắt đầu công việc đó. 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 và trừ dấu thời gian bắt đầu của công việc về kiểu và bố cục khỏi thời lượng đó.

Các lệnh gọi lại requestAnimationFrame lâu dài

Một nguyên nhân tiềm ẩn gây ra độ trễ khi trình bày lâu 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ờ các 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 những 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.sort((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ễ của bản trình bày được dành cho lệnh gọi lại requestAnimationFrame, hãy đảm bảo rằng 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 việc cập nhật thực tế cho giao diện người dùng. Bất kỳ tác vụ nào khác không chạm vào DOM hoặc cập nhật kiểu sẽ làm chậm trễ khung tiếp theo được vẽ 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ể tham khảo khi tìm hiểu những hoạt động tương tác nào gây ra vấn đề 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, chẳng hạn 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 hoạt động tương tác gây ra nhiều vấn đề nhất, sau đó chuyển sang tái tạo những hoạt động tương tác có vấn đề trong phòng thí nghiệm rồi tiến hành khắc phục các hoạt động tương tác đó.

Hình ảnh chính trên Unsplash, của Federico Respini.