Tìm hiểu cách đưa dữ liệu thực địa vào phòng thí nghiệm để tái tạo 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.
Ngày xuất bản: 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ể 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ử, thì 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 thực địa hay không, bước tiếp theo là kiểm thử và tái tạo các lượt tương tác bị chậm theo cách thủ công. Bởi vì chỉ khi có thể tái tạo một lượt tương tác bị chậm, bạn mới có thể khắc phục vấn đề này.
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, khi mở bảng điều khiển Hiệu suất lần đầu tiên, 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:
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ụ được đề xuất để 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:
- Mở trang mà bạn muốn kiểm thử.
- 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.
- Nhấp vào nút Record (Ghi) ở phía trên bên trái của bảng điều khiển để bắt đầu theo dõi.
- Thực hiện(các) lượt tương tác mà bạn muốn khắc phục sự cố.
- 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. Bảng tóm tắt hoạt động cho thấy các thanh màu đỏ ở đầu nơi các tác vụ dài xảy ra 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ạ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 tiến trình và bỏ qua hoạt động không liên quan.
Sau khi bạn tập trung vào vị trí xảy ra lượt tương tác, kênh Tương tác sẽ giúp bạn sắp xếp lượt tương tác và hoạt động đã xảy ra trong kênh luồng chính bên dưới:
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:
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ê là:
- Độ trễ đầu vào – được minh hoạ bằng ria mép bên trái.
- Thời gian xử lý – được thể hiện bằng khối rắn giữa các râu trái và phải.
- Độ trễ trình bày – được minh hoạ bằng ria bên phải.
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 bao gồm 3 phần: độ trễ đầu vào, thời lượng xử lý và độ trễ hiển thị. 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 vị trí 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.
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 lệnh gọi lại sự kiện chạy quá lâu, thì trình duyệt sẽ bị chậm trễ trong việc 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.
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ể:
- 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 phải 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.
- 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 trình xử lý sự kiện (ví dụ: các mục nhập có tên như Sự kiện: nhấp) trong ngăn xếp lệnh gọi có 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:
- Chỉ thực hiện ít công 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 để trợ giúp. 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.
- 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ị.
Công việc kết xuất thường bao gồm các tác vụ 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à 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 kết quả của công việ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 tránh buộc luồng lại, hãy đọc bài viết Tránh bố cục lớn, phức tạp và tình trạng bố cục bị rối loạn.
- 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ạirequestAnimationFrame()
đượ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ụngrequestAnimationFrame()
để 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 hình 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 tạo vấn đề đó trong phòng thí nghiệm theo cách thủ công? Có một số lý do khiến điều này có thể xảy ra, 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 với 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:
- 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 phiên bản Chrome DevTools 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.
- 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.
- 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
Bạn sẽ phải mất nhiều công sức để tìm hiểu nguyên nhân gây ra độ trễ tương tác cao dẫn đến INP kém. Tuy nhiên, nếu có thể xác định được nguyên nhân, bạn đã đi được một 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.
Yếu tố cuối cùng này là quan trọng nhất. Giống như hầu hết các công việc khác mà 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 quy trình tuần hoàn. Khi bạn khắc phục một lượt tương tác bị chậm, hãy chuyển sang lượt 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ả.