Đo lường lượt tương tác với nội dung hiển thị tiếp theo (INP)

1. Giới thiệu

Đây là một lớp học lập trình giàu tính tương tác, giúp bạn tìm hiểu cách đo lường Lượt tương tác đến nội dung hiển thị tiếp theo (INP) bằng thư viện web-vitals.

Điều kiện tiên quyết

Kiến thức bạn sẽ học được

  • Cách thêm thư viện web-vitals vào trang của bạn và sử dụng dữ liệu phân bổ của thư viện đó.
  • Sử dụng dữ liệu phân bổ để chẩn đoán vị trí và cách bắt đầu cải thiện INP.

Bạn cần có

  • Máy tính có khả năng sao chép mã từ GitHub và chạy các lệnh npm.
  • Một trình chỉnh sửa văn bản.
  • Phiên bản Chrome mới nhất để tất cả các chỉ số đo lường lượt tương tác hoạt động.

2. Bắt đầu thiết lập

Lấy và chạy mã

Bạn có thể tìm thấy mã này trong kho lưu trữ web-vitals-codelabs.

  1. Sao chép kho lưu trữ trong thiết bị đầu cuối: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
  2. Di chuyển vào thư mục được sao chép: cd web-vitals-codelabs/measuring-inp.
  3. Cài đặt các phần phụ thuộc: npm ci.
  4. Khởi động máy chủ web: npm run start.
  5. Truy cập vào http://localhost:8080/ trong trình duyệt.

Dùng thử trang

Lớp học lập trình này sử dụng Gastropodicon (một trang web tham khảo phổ biến về giải phẫu ốc sên) để khám phá các vấn đề tiềm ẩn với INP.

Ảnh chụp màn hình trang minh hoạ Gastropodicon

Hãy thử tương tác với trang để cảm nhận xem những tương tác nào diễn ra chậm.

3. Làm quen với Chrome DevTools

Mở Công cụ cho nhà phát triển trong trình đơn Công cụ khác > Công cụ cho nhà phát triển, bằng cách nhấp chuột phải vào trang rồi chọn Kiểm tra hoặc bằng cách sử dụng tổ hợp phím.

Trong lớp học lập trình này, chúng ta sẽ sử dụng cả bảng điều khiển Hiệu suất và Bảng điều khiển. Bạn có thể chuyển đổi giữa các thẻ này ở đầu Công cụ cho nhà phát triển bất cứ lúc nào.

  • Các vấn đề về INP thường xảy ra trên thiết bị di động, vì vậy, hãy chuyển sang chế độ mô phỏng hiển thị trên thiết bị di động.
  • Nếu bạn đang kiểm thử trên máy tính hoặc máy tính xách tay, thì hiệu suất có thể sẽ cao hơn đáng kể so với trên thiết bị di động thực. Để xem hiệu suất một cách thực tế hơn, hãy nhấn vào biểu tượng bánh răng ở trên cùng bên phải của bảng điều khiển Hiệu suất, sau đó chọn Giảm tốc độ CPU 4 lần.

Ảnh chụp màn hình bảng điều khiển Hiệu suất của Công cụ cho nhà phát triển cùng với ứng dụng, trong đó có lựa chọn giảm tốc độ CPU xuống 4 lần

4. Cài đặt web-vitals

web-vitals là một thư viện JavaScript để đo lường các chỉ số Web Vitals mà người dùng trải nghiệm. Bạn có thể dùng thư viện này để ghi lại các giá trị đó, sau đó truyền chúng đến một điểm cuối phân tích để phân tích sau này, nhằm xác định thời điểm và vị trí xảy ra các lượt tương tác chậm.

Có một số cách để thêm thư viện vào trang. Cách bạn cài đặt thư viện trên trang web của riêng mình sẽ tuỳ thuộc vào cách bạn quản lý các phần phụ thuộc, quy trình xây dựng và các yếu tố khác. Hãy nhớ xem tài liệu của thư viện để biết tất cả các lựa chọn.

Lớp học lập trình này sẽ cài đặt từ npm và tải tập lệnh trực tiếp để tránh đi sâu vào một quy trình xây dựng cụ thể.

Bạn có thể sử dụng 2 phiên bản của web-vitals:

  • Bạn nên sử dụng bản dựng "chuẩn" nếu muốn theo dõi các giá trị chỉ số của Core Web Vitals khi tải trang.
  • Bản dựng "phân bổ" sẽ thêm thông tin gỡ lỗi bổ sung vào từng chỉ số để chẩn đoán lý do một chỉ số có giá trị như vậy.

Để đo lường INP trong lớp học lập trình này, chúng ta muốn bản dựng phân bổ.

Thêm web-vitals vào devDependencies của dự án bằng cách chạy npm install -D web-vitals

Thêm web-vitals vào trang:

Thêm phiên bản phân bổ của tập lệnh vào cuối index.html và ghi kết quả vào bảng điều khiển:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log);
</script>

Dùng thử

Hãy thử tương tác lại với trang khi bảng điều khiển đang mở. Khi bạn nhấp vào các phần trên trang, sẽ không có thông tin nào được ghi lại!

INP được đo lường trong toàn bộ vòng đời của một trang. Do đó, theo mặc định, web-vitals sẽ không báo cáo INP cho đến khi người dùng rời khỏi hoặc đóng trang. Đây là hành vi lý tưởng cho việc báo hiệu cho một số mục đích như phân tích, nhưng lại ít lý tưởng hơn cho việc gỡ lỗi một cách tương tác.

web-vitals cung cấp lựa chọn reportAllChanges để báo cáo chi tiết hơn. Khi được bật, không phải mọi lượt tương tác đều được báo cáo, nhưng mỗi khi có một lượt tương tác chậm hơn bất kỳ lượt tương tác nào trước đó, lượt tương tác đó sẽ được báo cáo.

Hãy thử thêm lựa chọn vào tập lệnh và tương tác lại với trang:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log, {reportAllChanges: true});
</script>

Làm mới trang và các lượt tương tác hiện sẽ được báo cáo cho bảng điều khiển, đồng thời được cập nhật bất cứ khi nào có lượt tương tác chậm nhất mới. Ví dụ: thử nhập vào hộp tìm kiếm rồi xoá nội dung nhập.

Ảnh chụp màn hình bảng điều khiển Công cụ cho nhà phát triển có các thông báo INP được in thành công

5. Thông tin gì trong mô hình phân bổ?

Hãy bắt đầu với lượt tương tác đầu tiên mà hầu hết người dùng sẽ có với trang, đó là hộp thoại đồng ý sử dụng cookie.

Nhiều trang sẽ có các tập lệnh cần cookie được kích hoạt đồng bộ khi người dùng chấp nhận cookie, khiến lượt nhấp trở thành một lượt tương tác chậm. Đó là những gì xảy ra ở đây.

Nhấp vào Yes (Có) để chấp nhận cookie (demo) và xem dữ liệu INP hiện đã được ghi vào bảng điều khiển DevTools.

Đối tượng dữ liệu INP được ghi vào bảng điều khiển Công cụ cho nhà phát triển

Thông tin cấp cao nhất này có trong cả bản dựng web-vitals tiêu chuẩn và bản dựng web-vitals dựa trên mô hình phân bổ:

{
  name: 'INP',
  value: 344,
  rating: 'needs-improvement',
  entries: [...],
  id: 'v4-1715732159298-8028729544485',
  navigationType: 'reload',
  attribution: {...},
}

Khoảng thời gian kể từ khi người dùng nhấp vào cho đến khi nội dung hiển thị tiếp theo là 344 mili giây – một chỉ số INP "cần cải thiện". Mảng entries có tất cả các giá trị PerformanceEntry được liên kết với lượt tương tác này – trong trường hợp này, chỉ có một sự kiện nhấp chuột.

Tuy nhiên, để biết điều gì đang xảy ra trong thời gian này, chúng tôi quan tâm nhất đến thuộc tính attribution. Để tạo dữ liệu phân bổ, web-vitals sẽ tìm Long Animations Frame (LoAF) nào trùng lặp với sự kiện nhấp chuột. Sau đó, LoAF có thể cung cấp dữ liệu chi tiết về thời gian đã sử dụng trong khung hình đó, từ các tập lệnh đã chạy cho đến thời gian đã sử dụng trong lệnh gọi lại requestAnimationFrame, kiểu và bố cục.

Mở rộng thuộc tính attribution để xem thêm thông tin. Dữ liệu phong phú hơn nhiều.

attribution: {
  interactionTargetElement: Element,
  interactionTarget: '#confirm',
  interactionType: 'pointer',

  inputDelay: 27,
  processingDuration: 295.6,
  presentationDelay: 21.4,

  processedEventEntries: [...],
  longAnimationFrameEntries: [...],
}

Trước tiên, đó là thông tin về nội dung đã được tương tác:

  • interactionTargetElement: một tham chiếu trực tiếp đến phần tử đã tương tác (nếu phần tử đó chưa bị xoá khỏi DOM).
  • interactionTarget: một bộ chọn để tìm phần tử trong trang.

Tiếp theo, thời gian được chia nhỏ ở cấp độ cao:

  • inputDelay: thời gian giữa thời điểm người dùng bắt đầu tương tác (ví dụ: nhấp vào chuột) và thời điểm trình nghe sự kiện cho hoạt động tương tác đó bắt đầu chạy. Trong trường hợp này, độ trễ đầu vào chỉ khoảng 27 mili giây, ngay cả khi bật tính năng điều tiết CPU.
  • processingDuration: thời gian cần thiết để trình nghe sự kiện chạy cho đến khi hoàn tất. Thông thường, các trang sẽ có nhiều trình nghe cho một sự kiện (ví dụ: pointerdown, pointerup và click). Nếu tất cả đều chạy trong cùng một khung hình động, thì chúng sẽ được kết hợp vào thời gian này. Trong trường hợp này, thời gian xử lý mất 295,6 mili giây – phần lớn thời gian INP.
  • presentationDelay: thời gian từ khi trình nghe sự kiện hoàn tất cho đến khi trình duyệt kết thúc việc tạo điểm ảnh khung hình tiếp theo. Trong trường hợp này, độ trễ là 21,4 mili giây.

Các giai đoạn INP này có thể là một tín hiệu quan trọng để chẩn đoán những gì cần được tối ưu hoá. Hướng dẫn tối ưu hoá INP có thêm thông tin về chủ đề này.

Đi sâu hơn một chút, processedEventEntries chứa 5 sự kiện, thay vì một sự kiện trong mảng INP entries cấp cao nhất. Hai tính năng này khác nhau thế nào?

processedEventEntries: [
  {
    name: 'mouseover',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {
    name: 'mousedown',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {name: 'mousedown', ...},
  {name: 'mouseup', ...},
  {name: 'click', ...},
],

Mục nhập cấp cao nhất là sự kiện INP, trong trường hợp này là một lượt nhấp. Phân bổ processedEventEntries là tất cả các sự kiện được xử lý trong cùng một khung hình. Xin lưu ý rằng sự kiện này bao gồm các sự kiện khác như mouseover và mousedown, chứ không chỉ có sự kiện nhấp chuột. Việc biết về những sự kiện khác này có thể rất quan trọng nếu chúng cũng diễn ra chậm, vì tất cả đều góp phần làm giảm khả năng phản hồi.

Cuối cùng là mảng longAnimationFrameEntries. Đây có thể là một mục nhập duy nhất, nhưng có những trường hợp một lượt tương tác có thể trải rộng trên nhiều khung hình. Ở đây, chúng ta có trường hợp đơn giản nhất với một khung hoạt hoạ cần nhiều thời gian duy nhất.

longAnimationFrameEntries

Mở rộng mục LoAF:

longAnimationFrameEntries: [{
  name: 'long-animation-frame',
  startTime: 1823,
  duration: 319,

  renderStart: 2139.5,
  styleAndLayoutStart: 2139.7,
  firstUIEventTimestamp: 1801.6,
  blockingDuration: 268,

  scripts: [{...}]
}],

Có một số giá trị hữu ích ở đây, chẳng hạn như thời gian dành cho việc tạo kiểu. Bài viết về Long Animation Frames API (API Khung hình động dài) sẽ trình bày chi tiết hơn về các thuộc tính này. Hiện tại, chúng ta chủ yếu quan tâm đến thuộc tính scripts. Thuộc tính này chứa các mục cung cấp thông tin chi tiết về những tập lệnh chịu trách nhiệm cho khung hình chạy trong thời gian dài:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 1828.6,
  executionStart: 1828.6,
  duration: 294,

  sourceURL: 'http://localhost:8080/third-party/cmp.js',
  sourceFunctionName: '',
  sourceCharPosition: 1144
}]

Trong trường hợp này, chúng ta có thể biết thời gian chủ yếu được dành cho một event-listener duy nhất, được gọi trên BUTTON#confirm.onclick. Chúng ta thậm chí có thể thấy URL nguồn tập lệnh và vị trí ký tự nơi hàm được xác định!

Điểm cần ghi nhớ

Bạn có thể xác định được điều gì về trường hợp này dựa trên dữ liệu phân bổ này?

  • Lượt tương tác được kích hoạt bằng một lượt nhấp vào phần tử button#confirm (từ attribution.interactionTarget và thuộc tính invoker trên một mục nhập phân bổ tập lệnh).
  • Thời gian chủ yếu được dùng để thực thi trình nghe sự kiện (từ attribution.processingDuration so với tổng số liệu value).
  • Mã trình nghe sự kiện chậm bắt đầu từ một trình nghe lượt nhấp được xác định trong third-party/cmp.js (từ scripts.sourceURL).

Đó là đủ dữ liệu để biết chúng ta cần tối ưu hoá ở đâu!

6. Nhiều trình xử lý sự kiện

Làm mới trang để bảng điều khiển Công cụ cho nhà phát triển không còn hiển thị và hoạt động tương tác về sự đồng ý sử dụng cookie không còn là hoạt động tương tác dài nhất nữa.

Bắt đầu nhập vào hộp tìm kiếm. Dữ liệu phân bổ cho biết điều gì? Bạn nghĩ chuyện gì đang xảy ra?

Dữ liệu phân bổ

Trước tiên, hãy quét sơ bộ một ví dụ về cách kiểm thử bản minh hoạ:

{
  name: 'INP',
  value: 1072,
  rating: 'poor',
  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'keyboard',

    inputDelay: 3.3,
    processingDuration: 1060.6,
    presentationDelay: 8.1,

    processedEventEntries: [...],
    longAnimationFrameEntries: [...],
  }
}

Đây là giá trị INP kém (khi bật tính năng điều tiết CPU) từ một lượt tương tác bằng bàn phím với phần tử input#search-terms. Phần lớn thời gian (1061 mili giây trong tổng số 1072 mili giây INP) được dùng để xử lý thời lượng.

Tuy nhiên, các mục scripts thú vị hơn.

Tình trạng giật bố cục

Mục đầu tiên của mảng scripts cung cấp cho chúng ta một số bối cảnh có giá trị:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 4875.6,
  executionStart: 4875.6,
  duration: 497,
  forcedStyleAndLayoutDuration: 388,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'handleSearch',
  sourceCharPosition: 940
},
...]

Phần lớn thời gian xử lý xảy ra trong quá trình thực thi tập lệnh này, đây là một trình nghe input (trình gọi là INPUT#search-terms.oninput). Tên hàm được cung cấp (handleSearch), cũng như vị trí ký tự bên trong tệp nguồn index.js.

Tuy nhiên, có một thuộc tính mới: forcedStyleAndLayoutDuration. Đây là thời gian dành cho lệnh gọi tập lệnh này, trong đó trình duyệt buộc phải bố trí lại trang. Nói cách khác, 78% thời gian (388 mili giây trong tổng số 497 mili giây) dành cho việc thực thi trình nghe sự kiện này thực sự là thời gian dành cho tình trạng đơ máy bố cục.

Đây là vấn đề cần được ưu tiên hàng đầu để khắc phục.

Người nghe liên tục

Nhìn chung, hai mục nhập kịch bản tiếp theo không có gì đặc biệt đáng chú ý:

scripts: [...,
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5375.3,
  executionStart: 5375.3,
  duration: 124,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526,
},
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5673.9,
  executionStart: 5673.9,
  duration: 95,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526
}]

Cả hai mục đều là trình nghe keyup, thực thi lần lượt. Các trình nghe là các hàm ẩn danh (do đó, không có gì được báo cáo trong thuộc tính sourceFunctionName), nhưng chúng ta vẫn có một tệp nguồn và vị trí ký tự, vì vậy, chúng ta có thể tìm thấy vị trí của mã.

Điều kỳ lạ là cả hai đều đến từ cùng một tệp nguồn và vị trí ký tự.

Trình duyệt đã xử lý nhiều lần nhấn phím trong một khung hình động duy nhất, dẫn đến trình nghe sự kiện này chạy hai lần trước khi có thể vẽ bất cứ thứ gì!

Hiệu ứng này cũng có thể tăng lên, trong đó thời gian hoàn thành của trình nghe sự kiện càng lâu thì càng có nhiều sự kiện đầu vào bổ sung có thể xuất hiện, kéo dài thời gian tương tác chậm hơn nhiều.

Vì đây là một hoạt động tương tác tìm kiếm/tự động hoàn thành, nên việc loại bỏ các lần nhập trùng lặp sẽ là một chiến lược hiệu quả để xử lý tối đa một lần nhấn phím cho mỗi khung hình.

7. Độ trễ khi nhập thông tin

Lý do thường gặp gây ra độ trễ đầu vào (khoảng thời gian từ khi người dùng tương tác đến khi trình nghe sự kiện có thể bắt đầu xử lý hoạt động tương tác) là do luồng chính đang bận. Điều này có thể do nhiều nguyên nhân:

  • Trang đang tải và luồng chính đang bận thực hiện công việc ban đầu là thiết lập DOM, bố trí và tạo kiểu cho trang, đồng thời đánh giá và chạy tập lệnh.
  • Trang thường bận – ví dụ: đang chạy các phép tính, ảnh động dựa trên tập lệnh hoặc quảng cáo.
  • Các lượt tương tác trước đó mất quá nhiều thời gian để xử lý, khiến các lượt tương tác trong tương lai bị chậm trễ, như trong ví dụ cuối cùng.

Trang minh hoạ có một tính năng bí mật: nếu bạn nhấp vào biểu trưng con ốc sên ở đầu trang, biểu trưng này sẽ bắt đầu chuyển động và thực hiện một số thao tác JavaScript nặng trên luồng chính.

  • Nhấp vào biểu trưng hình con ốc sên để bắt đầu ảnh động.
  • Các tác vụ JavaScript sẽ được kích hoạt khi con ốc sên ở cuối lần bật. Hãy cố gắng tương tác với trang càng gần cuối lượt truy cập càng tốt và xem bạn có thể kích hoạt INP cao đến mức nào.

Ví dụ: ngay cả khi bạn không kích hoạt trình nghe sự kiện nào khác (chẳng hạn như khi nhấp và lấy tiêu điểm vào hộp tìm kiếm ngay khi con ốc sên bật lên), thì hoạt động trên luồng chính sẽ khiến trang không phản hồi trong một khoảng thời gian đáng kể.

Trên nhiều trang, hoạt động của luồng chính sẽ không diễn ra suôn sẻ như vậy, nhưng đây là một ví dụ minh hoạ hay để xem cách xác định hoạt động này trong dữ liệu phân bổ INP.

Sau đây là ví dụ về thuộc tính chỉ tập trung vào hộp tìm kiếm trong quá trình chuyển động nảy của con trỏ:

{
  name: 'INP',
  value: 728,
  rating: 'poor',

  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'pointer',

    inputDelay: 702.3,
    processingDuration: 4.9,
    presentationDelay: 20.8,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 2064.8,
      duration: 790,

      renderStart: 2065,
      styleAndLayoutStart: 2854.2,
      firstUIEventTimestamp: 0,
      blockingDuration: 740,

      scripts: [{...}]
    }]
  }
}

Như dự đoán, các trình nghe sự kiện đã thực thi nhanh chóng, cho thấy thời gian xử lý là 4,9 mili giây và phần lớn tương tác kém là do độ trễ đầu vào, chiếm 702,3 mili giây trong tổng số 728 mili giây.

Bạn có thể gặp khó khăn khi gỡ lỗi trong trường hợp này. Mặc dù biết người dùng đã tương tác với nội dung nào và tương tác như thế nào, nhưng chúng tôi cũng biết rằng phần tương tác đó đã hoàn tất nhanh chóng và không gặp vấn đề gì. Thay vào đó, có một thành phần khác trên trang đã trì hoãn quá trình bắt đầu xử lý hoạt động tương tác, nhưng làm sao chúng ta biết được nên bắt đầu tìm kiếm từ đâu?

Các mục trong tập lệnh LoAF sẽ giúp bạn giải quyết vấn đề:

scripts: [{
  name: 'script',
  invoker: 'SPAN.onanimationiteration',
  invokerType: 'event-listener',

  startTime: 2065,
  executionStart: 2065,
  duration: 788,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'cryptodaphneCoinHandler',
  sourceCharPosition: 1831
}]

Mặc dù hàm này không liên quan gì đến hoạt động tương tác, nhưng nó đã làm chậm khung hình động và do đó được đưa vào dữ liệu LoAF được kết hợp với sự kiện tương tác.

Từ đây, chúng ta có thể thấy cách hàm trì hoãn quá trình xử lý tương tác được kích hoạt (bởi một trình nghe animationiteration), chính xác hàm nào chịu trách nhiệm và hàm đó nằm ở đâu trong các tệp nguồn của chúng ta.

8. Độ trễ khi trình bày: khi một bản cập nhật không hiển thị

Độ trễ trình bày đo lường thời gian từ khi trình nghe sự kiện hoàn tất quá trình chạy cho đến khi trình duyệt có thể vẽ một khung hình mới lên màn hình, cho thấy phản hồi mà người dùng có thể thấy.

Làm mới trang để đặt lại giá trị INP, sau đó mở trình đơn có biểu tượng ba dấu gạch ngang. Có một vấn đề rõ ràng khi mở.

Điều này diễn ra như thế nào?

{
  name: 'INP',
  value: 376,
  rating: 'needs-improvement',
  delta: 352,

  attribution: {
    interactionTarget: '#sidenav-button>svg',
    interactionType: 'pointer',

    inputDelay: 12.8,
    processingDuration: 14.7,
    presentationDelay: 348.5,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 651,
      duration: 365,

      renderStart: 673.2,
      styleAndLayoutStart: 1004.3,
      firstUIEventTimestamp: 138.6,
      blockingDuration: 315,

      scripts: [{...}]
    }]
  }
}

Lần này, độ trễ trình bày chiếm phần lớn trong lượt tương tác chậm. Điều đó có nghĩa là bất cứ điều gì chặn luồng chính đều xảy ra sau khi trình nghe sự kiện hoàn tất.

scripts: [{
  entryType: 'script',
  invoker: 'FrameRequestCallback',
  invokerType: 'user-callback',

  startTime: 673.8,
  executionStart: 673.8,
  duration: 330,

  sourceURL: 'http://localhost:8080/js/side-nav.js',
  sourceFunctionName: '',
  sourceCharPosition: 1193,
}]

Nhìn vào mục nhập duy nhất trong mảng scripts, chúng ta thấy thời gian được dùng trong một user-callback từ một FrameRequestCallback. Lần này, độ trễ trình chiếu là do lệnh gọi lại requestAnimationFrame gây ra.

9. Kết luận

Tổng hợp dữ liệu trường

Bạn nên nhận ra rằng mọi thứ sẽ dễ dàng hơn khi xem xét một mục phân bổ INP duy nhất từ một lần tải trang duy nhất. Làm cách nào để tổng hợp dữ liệu này nhằm gỡ lỗi INP dựa trên dữ liệu trường? Lượng thông tin chi tiết hữu ích thực sự khiến việc này trở nên khó khăn hơn.

Ví dụ: bạn nên biết phần tử trang nào là nguồn gốc phổ biến của các lượt tương tác chậm. Tuy nhiên, nếu trang của bạn có tên lớp CSS đã biên dịch thay đổi theo từng bản dựng, thì bộ chọn web-vitals của cùng một phần tử có thể khác nhau giữa các bản dựng.

Thay vào đó, bạn phải nghĩ đến ứng dụng cụ thể của mình để xác định những gì hữu ích nhất và cách tổng hợp dữ liệu. Ví dụ: trước khi gửi dữ liệu phân bổ bằng beacon, bạn có thể thay thế bộ chọn web-vitals bằng một giá trị nhận dạng của riêng mình, dựa trên thành phần mà mục tiêu nằm trong đó hoặc vai trò ARIA mà mục tiêu đáp ứng.

Tương tự, các mục scripts có thể có hàm băm dựa trên tệp trong đường dẫn sourceURL khiến chúng khó kết hợp, nhưng bạn có thể loại bỏ các hàm băm dựa trên quy trình xây dựng đã biết trước khi truyền dữ liệu trở lại.

Rất tiếc là không có cách nào dễ dàng để xử lý dữ liệu phức tạp như vậy, nhưng ngay cả khi sử dụng một phần dữ liệu, bạn vẫn có giá trị hơn là không có dữ liệu phân bổ nào cho quy trình gỡ lỗi.

Phân bổ ở mọi nơi!

Tính năng phân bổ INP dựa trên LoAF là một công cụ gỡ lỗi hiệu quả. Công cụ này cung cấp dữ liệu thật chi tiết về những gì đã xảy ra trong một INP. Trong nhiều trường hợp, thông tin này có thể chỉ cho bạn vị trí chính xác trong một tập lệnh mà bạn nên bắt đầu nỗ lực tối ưu hoá.

Giờ đây, bạn đã sẵn sàng sử dụng dữ liệu phân bổ INP trên mọi trang web!

Ngay cả khi không có quyền chỉnh sửa trang, bạn vẫn có thể tạo lại quy trình trong lớp học lập trình này bằng cách chạy đoạn mã sau trong bảng điều khiển Công cụ cho nhà phát triển để xem những gì bạn có thể tìm thấy:

const script = document.createElement('script');
script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';
script.onload = function () {
  webVitals.onINP(console.log, {reportAllChanges: true});
};
document.head.appendChild(script);

Tìm hiểu thêm