Chẩn đoán thủ công các tương tác chậm trong phòng thí nghiệm

Tìm hiểu cách đưa dữ liệu thực địa vào phòng thí nghiệm để tái hiện và xác định nguyên nhân gây ra các lượt tương tác chậm thông qua kiểm thử thủ công.

Jeremy Wagner
Jeremy Wagner

Ngày phát hành: 9 tháng 5 năm 2023

Một phần khó khăn trong việc tối ưu hoá Lượt tương tác đến nội dung hiển thị tiếp theo (INP) là tìm hiểu nguyên nhân khiến INP kém. Có nhiều nguyên nhân tiềm ẩn, chẳng hạn như tập lệnh của bên thứ ba lên lịch nhiều tác vụ trên luồng chính, kích thước DOM lớn, lệnh gọi lại sự kiện tốn kém và các nguyên nhân khác.

Việc cải thiện INP có thể rất khó khăn. Để bắt đầu, bạn phải biết những lượt tương tác nào có xu hướng chịu trách nhiệm cho INP của một trang. Nếu bạn không biết những lượt tương tác nào trên trang web của mình thường chậm nhất theo quan điểm của người dùng thực, hãy đọc bài viết Tìm lượt tương tác chậm trong thực tế. Sau khi có dữ liệu thực địa để làm cơ sở, bạn có thể kiểm thử các lượt tương tác cụ thể đó theo cách thủ công trong các công cụ thử nghiệm để tìm hiểu lý do khiến các lượt tương tác đó diễn ra chậm.

Nếu bạn không có dữ liệu trường thì sao?

Việc có dữ liệu thực địa là rất quan trọng vì giúp bạn tiết kiệm nhiều thời gian để tìm ra những lượt tương tác cần được tối ưu hoá. Tuy nhiên, có thể bạn không có dữ liệu thực địa. Nếu đó là trường hợp của bạn, bạn vẫn có thể tìm thấy các lượt tương tác để cải thiện, mặc dù điều này đòi hỏi bạn phải nỗ lực nhiều hơn một chút và áp dụng một phương pháp khác.

Tổng thời gian chặn (TBT) là một chỉ số trong phòng thí nghiệm giúp đánh giá khả năng phản hồi của trang trong khi tải và có mối tương quan tốt với INP. Nếu trang của bạn có TBT cao, thì đó có thể là tín hiệu cho thấy trang của bạn có thể không phản hồi tốt các lượt tương tác của người dùng khi tải trang.

Để tìm hiểu TBT của trang, bạn có thể sử dụng Lighthouse. Nếu TBT của một trang cao, thì có thể luồng chính quá bận trong quá trình tải trang. Điều này có thể ảnh hưởng đến khả năng phản hồi của trang trong thời điểm quan trọng đó trong vòng đời của trang.

Để tìm các lượt tương tác chậm sau khi trang tải xong, bạn có thể cần các loại dữ liệu khác, chẳng hạn như luồng người dùng phổ biến mà bạn có thể đã xác định được trong số liệu phân tích của trang web. Ví dụ: nếu bạn làm việc trên một trang web thương mại điện tử, luồng người dùng phổ biến sẽ là những hành động mà người dùng thực hiện khi thêm mặt hàng vào giỏ hàng trực tuyến và thanh toán.

Cho dù bạn có dữ liệu trường hay không, bước tiếp theo là kiểm tra và tái tạo các tương tác chậm theo cách thủ công — bởi vì chỉ khi bạn có thể tái tạo một tương tác chậm thì bạn mới có thể khắc phục vấn đề đó.

Tái hiện các lượt tương tác chậm trong phòng thí nghiệm

Có một số cách để bạn có thể tái tạo các lượt tương tác chậm trong phòng thí nghiệm thông qua kiểm thử thủ công, nhưng sau đây là một khung mà bạn có thể thử.

Chỉ số trực tiếp của bảng điều khiển Hiệu suất trong Công cụ cho nhà phát triển

Trình phân tích hiệu suất của DevTools là phương pháp được đề xuất để chẩn đoán các lượt tương tác được biết là chậm, nhưng có thể mất thời gian để xác định các lượt tương tác chậm khi bạn không biết lượt tương tác nào là vấn đề.

Tuy nhiên, trong lần đầu mở bảng điều khiển Hiệu suất, bạn sẽ thấy một chế độ xem chỉ số trực tiếp. Bạn có thể dùng tính năng này để nhanh chóng thử một số lượt tương tác nhằm tìm ra những lượt tương tác có vấn đề, trước khi chuyển sang trình phân tích hiệu suất chi tiết hơn. Khi bạn tương tác, dữ liệu chẩn đoán sẽ xuất hiện trong nhật ký Tương tác (với lượt tương tác INP được làm nổi bật). Bạn có thể mở rộng các lượt tương tác này để xem thông tin chi tiết về giai đoạn:

Cách nhật ký về lượt tương tác xuất hiện trong màn hình chỉ số trực tiếp của bảng điều khiển Hiệu suất.
Màn hình chỉ số trực tiếp của bảng điều khiển Hiệu suất.

Mặc dù tiện ích Web Vitals giúp xác định các lượt tương tác chậm và cung cấp một số thông tin chi tiết để giúp bạn gỡ lỗi INP, nhưng bạn vẫn có thể cần sử dụng trình phân tích hiệu suất để chẩn đoán các lượt tương tác chậm, vì trình phân tích này cung cấp dữ liệu chi tiết mà bạn cần để xem xét mã phát hành chính thức của trang web nhằm tìm ra nguyên nhân gây ra các lượt tương tác chậm.

Ghi lại dấu vết

Trình phân tích hiệu suất của Chrome là công cụ bạn nên dùng để chẩn đoán và khắc phục sự cố tương tác chậm. Để phân tích một lượt tương tác trong trình phân tích hiệu suất của Chrome, hãy làm theo các bước sau:

  1. Mở trang mà bạn muốn kiểm thử.
  2. Mở Công cụ của Chrome cho nhà phát triển rồi chuyển đến bảng điều khiển Hiệu suất.
  3. Nhấp vào nút Ghi lại ở phía trên bên trái của bảng điều khiển để bắt đầu theo dõi.
  4. Thực hiện(các) tương tác mà bạn muốn khắc phục sự cố.
  5. Nhấp lại vào nút Record (Ghi) để dừng theo dõi.

Khi trình phân tích tài nguyên điền sẵn, nơi đầu tiên bạn nên xem là phần tóm tắt hoạt động ở đầu trình phân tích tài nguyên. Phần tóm tắt hoạt động sẽ hiển thị các thanh màu đỏ ở trên cùng nơi diễn ra các tác vụ dài trong bản ghi. Thao tác này giúp bạn nhanh chóng phóng to các khu vực có vấn đề.

Bảng tóm tắt hoạt động xuất hiện ở gần đầu bảng điều khiển hiệu suất của Công cụ của Chrome cho nhà phát triển. Hoạt động hiển thị chủ yếu là từ JavaScript gây ra một tác vụ dài, được đánh dấu bằng màu đỏ phía trên biểu đồ hình ngọn lửa.
Phần tóm tắt về hoạt động ở đầu trình phân tích hiệu suất của Chrome. Các tác vụ dài được đánh dấu màu đỏ phía trên biểu đồ hình ngọn lửa hoạt động. Trong trường hợp này, nhiều công việc viết tập lệnh là trách nhiệm của hầu hết các công việc trong tác vụ dài.

Bạn có thể nhanh chóng tập trung vào các khu vực có vấn đề bằng cách kéo và chọn một khu vực trong phần tóm tắt hoạt động. Bạn có thể tuỳ ý sử dụng tính năng đường dẫn trong trình phân tích tài nguyên để thu hẹp dòng thời gian và bỏ qua hoạt động không liên quan.

Khi bạn đã tập trung vào vị trí xảy ra lượt tương tác, kênh Lượt tương tác sẽ giúp bạn căn chỉnh lượt tương tác và hoạt động xảy ra trong luồng chính bên dưới lượt tương tác đó:

Một lượt tương tác được minh hoạ trong bảng hiệu suất của Công cụ của Chrome cho nhà phát triển. Một kênh tương tác phía trên kênh luồng chính cho biết thời lượng của một lượt tương tác. Lượt tương tác này có thể được căn chỉnh với hoạt động luồng chính bên dưới.
Một lượt tương tác được phân tích trong trình phân tích hiệu suất trong DevTools của Chrome. Theo dõi Sự tương tác cho thấy một loạt sự kiện tương ứng với một lượt tương tác nhấp. Các mục theo dõi Hoạt động tương tác trải dài trên các tác vụ chịu trách nhiệm thúc đẩy hoạt động tương tác.

Bạn có thể xem thêm thông tin chi tiết về phần tương tác dài nhất bằng cách di chuột qua phần tương tác đó trong kênh tương tác:

Chú giải công cụ khi di chuột cho một lượt tương tác như trong bảng điều khiển hiệu suất của Chrome DevTools. Chú giải công cụ cho biết thời gian tương tác và phần tương tác, bao gồm độ trễ đầu vào, thời lượng xử lý và độ trễ hiển thị của lượt tương tác.
Chú thích này xuất hiện khi bạn di chuột qua một lượt tương tác trong tính năng theo dõi lượt tương tác của bảng hiệu suất. Chú giải công cụ hiển thị lượng thời gian dành cho mỗi phần của hoạt động tương tác.

Phần có đường kẻ của lượt tương tác cho biết thời lượng của lượt tương tác vượt quá 200 mili giây, đây là giới hạn trên của ngưỡng "tốt" đối với INP của trang. Các phần của lượt tương tác được liệt kê bao gồm:

  1. Độ trễ đầu vào – được minh hoạ bằng ria mép bên trái.
  2. Thời lượng xử lý – được hình dung bằng khối đồng giữa các râu bên trái và bên phải.
  3. Độ trễ hiển thị – được hiển thị bởi người vẽ đúng.

Từ đây, bạn cần tìm hiểu sâu hơn về (các) vấn đề gây ra tình trạng tương tác chậm. Chúng tôi sẽ đề cập đến vấn đề này ở phần sau của hướng dẫn này.

Cách xác định phần nào của lượt tương tác bị chậm

Hoạt động tương tác gồm ba phần: độ trễ đầu vào, thời lượng xử lý và độ trễ khi trình bày. Cách bạn tối ưu hoá một lượt tương tác để giảm INP của trang phụ thuộc vào phần nào của lượt tương tác đó mất nhiều thời gian nhất.

Cách xác định độ trễ đầu vào lâu

Độ trễ đầu vào có thể gây ra độ trễ tương tác cao. Độ trễ đầu vào là phần đầu tiên của một lượt tương tác. Đây là khoảng thời gian từ khi hệ điều hành nhận được hành động của người dùng lần đầu tiên cho đến thời điểm trình duyệt có thể bắt đầu xử lý lệnh gọi lại trình xử lý sự kiện đầu tiên của lượt tương tác đó.

Bạn có thể xác định độ trễ đầu vào trong trình phân tích hiệu suất của Chrome bằng cách xác định lượt tương tác trong kênh tương tác. Chiều dài của ria mép trái cho biết phần độ trễ đầu vào của lượt tương tác. Bạn có thể tìm thấy giá trị chính xác trong chú giải công cụ bằng cách di chuột qua lượt tương tác trong trình phân tích hiệu suất.

Độ trễ đầu vào không bao giờ có thể bằng 0, nhưng bạn có thể kiểm soát một số thời lượng độ trễ đầu vào. Điểm mấu chốt là tìm hiểu xem có công việc nào đang chạy trên luồng chính khiến lệnh gọi lại không chạy ngay khi cần không.

Độ trễ đầu vào như mô tả trong bảng điều khiển hiệu suất của Chrome. Thời điểm bắt đầu tương tác diễn ra đáng kể trước lệnh gọi lại sự kiện do độ trễ đầu vào tăng lên do bộ hẹn giờ kích hoạt từ tập lệnh của bên thứ ba.
Độ trễ đầu vào do một tác vụ được kích hoạt bằng bộ hẹn giờ từ tập lệnh của bên thứ ba. Phần bên trái của ria trong lượt tương tác hiển thị trong kênh tương tác cho thấy độ trễ đầu vào.

Trong hình trước, một tác vụ từ tập lệnh của bên thứ ba đang chạy khi người dùng cố gắng tương tác với trang, do đó kéo dài độ trễ đầu vào. Độ trễ đầu vào kéo dài ảnh hưởng đến độ trễ của lượt tương tác, do đó có thể ảnh hưởng đến INP của trang.

Cách xác định thời gian xử lý lâu

Lệnh gọi lại sự kiện chạy ngay sau độ trễ đầu vào và thời gian cần thiết để hoàn tất được gọi là thời lượng xử lý. Nếu các lệnh gọi lại sự kiện chạy quá lâu, thì chúng sẽ làm chậm trình duyệt hiển thị khung hình tiếp theo và có thể làm tăng đáng kể tổng độ trễ của một lượt tương tác. Thời gian xử lý lâu có thể là do JavaScript của bên thứ nhất hoặc bên thứ ba có chi phí tính toán cao và trong một số trường hợp là cả hai. Trong trình phân tích hiệu suất, phần này được biểu thị bằng phần rắn của lượt tương tác trong kênh tương tác.

Hình ảnh mô tả các tác vụ gọi lại sự kiện trong bảng điều khiển hiệu suất của Chrome. Chú giải công cụ khi di chuột lên hoạt động tương tác trên dòng thời gian cho thấy thời gian xử lý dài.
Các lệnh gọi lại sự kiện chạy để phản hồi một lượt tương tác nhấp chuột, như hiển thị trong trình phân tích hiệu suất trong Công cụ của Chrome cho nhà phát triển. Bạn cần lưu ý đến thời gian xử lý cao.

Bạn có thể tìm thấy các lệnh gọi lại sự kiện tốn kém bằng cách quan sát những thông tin sau trong dấu vết của một lượt tương tác cụ thể:

  1. Xác định xem tác vụ liên kết với lệnh gọi lại sự kiện có phải là tác vụ dài hay không. Để hiển thị các tác vụ dài trong chế độ cài đặt phòng thí nghiệm một cách đáng tin cậy hơn, bạn có thể cần bật tính năng điều tiết CPU trong bảng điều khiển hiệu suất hoặc kết nối một thiết bị Android cấp thấp đến trung bình và sử dụng tính năng gỡ lỗi từ xa.
  2. Nếu tác vụ chạy lệnh gọi lại sự kiện là một tác vụ dài, hãy tìm các mục nhập của trình xử lý sự kiện (ví dụ: mục nhập có tên như Sự kiện: nhấp chuột) trong ngăn xếp lệnh gọi có một hình tam giác màu đỏ ở góc trên bên phải của mục nhập.

Bạn có thể thử một trong các chiến lược sau để giảm thời gian xử lý của một lượt tương tác:

  1. Chỉ làm ít việc nhất có thể. Mọi thứ xảy ra trong lệnh gọi lại sự kiện tốn kém có thực sự cần thiết không? Nếu không, hãy cân nhắc việc xoá hoàn toàn mã đó nếu có thể hoặc trì hoãn việc thực thi mã đó đến một thời điểm khác nếu bạn không thể. Bạn cũng có thể tận dụng các tính năng của khung để giúp ích. Ví dụ: tính năng ghi nhớ của React có thể bỏ qua công việc kết xuất không cần thiết cho một thành phần khi các thuộc tính của thành phần đó không thay đổi.
  2. Trì hoãn công việc không kết xuất trong lệnh gọi lại sự kiện đến một thời điểm sau đó. Bạn có thể chia nhỏ các tác vụ dài bằng cách chuyển sang luồng chính. Bất cứ khi nào bạn nhường cho luồng chính, bạn sẽ kết thúc quá trình thực thi tác vụ hiện tại và chia phần công việc còn lại thành một tác vụ riêng biệt. Điều này giúp trình kết xuất có cơ hội xử lý các bản cập nhật cho giao diện người dùng đã được thực hiện trước đó trong lệnh gọi lại sự kiện. Nếu bạn đang sử dụng React, thì tính năng chuyển đổi của React có thể giúp bạn thực hiện việc này.

Các chiến lược này có thể giúp bạn tối ưu hoá lệnh gọi lại sự kiện để các lệnh gọi này mất ít thời gian hơn để chạy.

Cách xác định độ trễ của bản trình bày

Độ trễ đầu vào và thời gian xử lý lâu không phải là nguyên nhân duy nhất gây ra INP kém. Đôi khi, các bản cập nhật kết xuất xảy ra để phản hồi ngay cả một lượng nhỏ mã gọi lại sự kiện cũng có thể tốn kém. Thời gian trình duyệt hiển thị nội dung cập nhật hình ảnh cho giao diện người dùng để phản ánh kết quả của một lượt tương tác được gọi là độ trễ hiển thị.

Hoạt động kết xuất như minh hoạ trong bảng điều khiển hiệu suất của Công cụ cho nhà phát triển của Chrome. Quá trình kết xuất xảy ra sau lệnh gọi lại sự kiện để vẽ khung tiếp theo.
Các tác vụ kết xuất như hiển thị trong trình phân tích hiệu suất của Chrome. Sợi tóc bên phải thể hiện thời lượng của độ trễ trong bản trình bày.

Công việc kết xuất thường bao gồm các công việc như tính toán lại kiểu, bố cục, vẽ và kết hợp, đồng thời được biểu thị bằng các khối màu tím và màu xanh lục trong biểu đồ hình ngọn lửa của trình phân tích tài nguyên. Tổng độ trễ hiển thị được biểu thị bằng ria bên phải của lượt tương tác trong kênh tương tác.

Trong số tất cả các nguyên nhân có thể gây ra độ trễ tương tác cao, độ trễ hiển thị có thể là nguyên nhân khó khắc phục nhất. Việc kết xuất quá mức có thể là do một trong những nguyên nhân sau:

  • Kích thước DOM lớn. Công việc kết xuất cần thiết để cập nhật bản trình bày của trang thường tăng lên cùng với kích thước DOM của trang. Để biết thêm thông tin, hãy đọc bài viết Mức độ ảnh hưởng của kích thước DOM đến khả năng tương tác và những việc bạn có thể làm về vấn đề này.
  • Buộc điều chỉnh lại luồng. Điều này xảy ra khi bạn áp dụng các thay đổi về kiểu cho các phần tử trong JavaScript, sau đó truy vấn ngay lập tức kết quả của thao tác đó. Kết quả là trình duyệt phải thực hiện công việc bố cục trước khi làm bất cứ việc gì khác để có thể trả về các kiểu đã cập nhật. Để biết thêm thông tin và mẹo về cách tránh buộc chỉnh lại luồng, hãy đọc bài viết Tránh tình trạng đơ bố cục và bố cục lớn, phức tạp.
  • Công việc quá mức hoặc không cần thiết trong lệnh gọi lại requestAnimationFrame. Lệnh gọi lại requestAnimationFrame() được chạy trong giai đoạn kết xuất của vòng lặp sự kiện và phải hoàn tất trước khi có thể hiển thị khung tiếp theo. Nếu đang sử dụng requestAnimationFrame() để thực hiện công việc không liên quan đến thay đổi đối với giao diện người dùng, hãy lưu ý rằng bạn có thể trì hoãn khung hình tiếp theo.
  • Lệnh gọi lại ResizeObserver. Các lệnh gọi lại như vậy chạy trước khi kết xuất và có thể trì hoãn việc hiển thị khung tiếp theo nếu công việc trong đó tốn kém. Cũng như với lệnh gọi lại sự kiện, hãy trì hoãn mọi logic không cần thiết cho khung hình tiếp theo.

Nếu bạn không thể tái hiện một lượt tương tác chậm thì sao?

Điều gì sẽ xảy ra nếu dữ liệu thực địa cho thấy một lượt tương tác cụ thể diễn ra chậm, nhưng bạn không thể tái hiện vấn đề đó trong phòng thí nghiệm theo cách thủ công? Có một số lý do có thể dẫn đến trường hợp này, nhưng một lý do quan trọng là hoàn cảnh của bạn khi kiểm thử các lượt tương tác phụ thuộc vào phần cứng và kết nối mạng của bạn. Bạn có thể đang sử dụng một thiết bị nhanh trên kết nối nhanh—nhưng điều đó không có nghĩa là người dùng của bạn cũng vậy. Bạn có thể thử một trong ba cách sau nếu trường hợp này xảy ra với bạn:

  1. Nếu bạn có thiết bị Android thực, hãy sử dụng tính năng gỡ lỗi từ xa để mở một thực thể Công cụ của Chrome cho nhà phát triển trên máy chủ và cố gắng tái hiện các hoạt động tương tác bị chậm ở đó. Thiết bị di động thường không nhanh bằng máy tính xách tay hoặc máy tính để bàn, vì vậy, bạn có thể dễ dàng quan sát thấy các lượt tương tác chậm trên các thiết bị này.
  2. Nếu bạn không có thiết bị thực, hãy bật tính năng điều tiết CPU trong Công cụ của Chrome cho nhà phát triển.
  3. Có thể bạn đang chờ một trang tải trước khi tương tác với trang đó, nhưng người dùng thì không. Nếu bạn đang sử dụng mạng nhanh, hãy mô phỏng tình trạng mạng chậm hơn bằng cách bật tính năng hạn chế băng thông mạng, sau đó tương tác với trang ngay khi trang đó vẽ. Bạn nên làm như vậy vì luồng chính thường bận rộn nhất trong quá trình khởi động và việc kiểm thử trong khoảng thời gian đó có thể cho thấy trải nghiệm của người dùng.

Khắc phục sự cố INP là một quá trình lặp lại

Việc tìm ra nguyên nhân gây ra độ trễ tương tác cao góp phần dẫn đến INP kém mất rất nhiều công sức. Tuy nhiên, nếu có thể xác định nguyên nhân thì bạn đã đi được nửa chặng đường. Bằng cách làm theo một phương pháp có hệ thống để khắc phục vấn đề về INP kém, bạn có thể xác định chính xác nguyên nhân gây ra vấn đề và nhanh chóng tìm ra giải pháp phù hợp. Cách xem lại:

  • Dựa vào dữ liệu trường để tìm các lượt tương tác chậm.
  • Kiểm thử theo cách thủ công các hoạt động tương tác có vấn đề trong trường trong phòng thí nghiệm để xem liệu có thể tái tạo các hoạt động đó hay không.
  • Xác định xem nguyên nhân là do độ trễ đầu vào lâu, lệnh gọi lại sự kiện tốn kém hay công việc kết xuất tốn kém.
  • Lặp lại.

Mục cuối cùng trong số này là quan trọng nhất. Giống như hầu hết các công việc khác bạn làm để cải thiện hiệu suất trang, việc khắc phục sự cố và cải thiện INP là một quá trình mang tính chu kỳ. Khi bạn khắc phục một tương tác bị chậm, hãy chuyển sang tương tác tiếp theo và lặp lại cho đến khi bạn bắt đầu thấy kết quả.