Cải thiện INP cho blog bằng DevTools

Nếu blog phản hồi chậm khi người đọc mở menu, bấm tìm kiếm, gửi biểu mẫu hoặc mở mục lục, bạn nên ưu tiên cải thiện INP cho blog. INP không chỉ phản ánh thời gian JavaScript chạy, mà còn bao gồm độ trễ trước khi trình xử lý bắt đầu, thời gian cập nhật giao diện và lúc trình duyệt vẽ khung hình tiếp theo.

Bài hướng dẫn này giúp bạn trả lời nhanh câu hỏi INP là gì, đo dữ liệu thực tế bằng PageSpeed Insights, tái hiện lỗi bằng Chrome DevTools Performance và áp dụng các cách sửa phù hợp cho blog WordPress, Blogger hoặc website dùng JavaScript tùy biến.

INP là gì và mức nào được xem là tốt?

INP, viết tắt của Interaction to Next Paint, là chỉ số trong nhóm Core Web Vitals dùng để đánh giá khả năng phản hồi của trang trước các tương tác như nhấp chuột, chạm màn hình và nhập bằng bàn phím. Chỉ số quan sát các tương tác đủ điều kiện trong suốt phiên truy cập, sau đó đại diện bằng tương tác chậm nhất hoặc gần chậm nhất, thay vì chỉ đo lần tương tác đầu tiên như FID trước đây (theo web.dev).

INP	Đánh giá	Ý nghĩa thực tế
≤ 200 mili giây	Tốt	Giao diện thường phản hồi nhanh và rõ ràng.
Trên 200 đến 500 mili giây	Cần cải thiện	Người dùng có thể nhận thấy độ trễ ở một số thao tác.
> 500 mili giây	Kém	Trang dễ tạo cảm giác bị treo hoặc không nhận lệnh.

Các ngưỡng trên được đánh giá ở phân vị 75 và nên phân tách giữa thiết bị di động và máy tính. Một blog có INP tốt trên máy tính vẫn có thể chậm trên điện thoại cấu hình thấp, đặc biệt khi tải nhiều quảng cáo, tiện ích chia sẻ, trình theo dõi hoặc thư viện JavaScript.

Điểm quan trọng là INP không phải chỉ số tốc độ tải trang. PageSpeed Insights có thể hiển thị INP từ dữ liệu người dùng thật nếu URL hoặc miền đủ dữ liệu trong Chrome User Experience Report (CrUX). Còn bài kiểm tra phòng thí nghiệm của Lighthouse thường dùng Total Blocking Time, hay TBT, làm chỉ báo gần đúng vì quá trình tải tự động không tạo đủ tương tác để đo INP trực tiếp (theo web.dev).

Đo INP bằng PageSpeed Insights trước khi sửa

Bước 1: Kiểm tra dữ liệu người dùng thật

Mở PageSpeed Insights và nhập URL bài viết hoặc trang chủ blog.
Chọn báo cáo cho thiết bị di động trước, vì đây thường là nhóm có CPU và mạng hạn chế hơn.
Tìm phần dữ liệu thực tế, thường được ghi là dữ liệu người dùng thực địa hoặc trải nghiệm thực tế.
Ghi lại INP, trạng thái đánh giá và phạm vi dữ liệu: cấp URL hay cấp toàn miền.

Nếu PageSpeed Insights không có INP, điều đó không nhất thiết có nghĩa trang hoàn hảo. Có thể URL chưa có đủ lượt truy cập đủ điều kiện trong CrUX, người dùng không thực hiện thao tác phù hợp hoặc dữ liệu mới chưa được tổng hợp. Khi đó, bạn cần kiểm tra nhiều URL cùng mẫu giao diện và đo bổ sung bằng Chrome DevTools hoặc công cụ RUM (theo web.dev).

Bước 2: Dùng phần chẩn đoán để tìm dấu hiệu liên quan

Trong kết quả phòng thí nghiệm, hãy chú ý TBT, thời gian thực thi JavaScript, tác vụ dài trên luồng chính, JavaScript không dùng và mã của bên thứ ba. Đây không phải nguyên nhân chắc chắn của INP, nhưng là dấu hiệu tốt để khoanh vùng. Ví dụ, TBT cao thường cho thấy luồng chính bị JavaScript chiếm dụng trong thời gian dài, khiến thao tác của người dùng phải chờ.

Đừng cố đạt điểm 100 bằng cách sửa mọi cảnh báo. Hãy ưu tiên lỗi gắn với thao tác quan trọng: mở menu trên di động, bật tìm kiếm, mở bộ lọc, chuyển tab, gửi bình luận hoặc nhấn nút đăng ký nhận tin.

Nếu blog của bạn phụ thuộc vào nhiều công cụ đo lường, hãy xem xét cách thu thập dữ liệu có trách nhiệm qua dữ liệu bên thứ nhất tôn trọng quyền riêng tư. Việc giảm mã theo dõi không cần thiết thường vừa có lợi cho quyền riêng tư vừa giảm công việc JavaScript trên trang.

Phân tích và sửa INP bằng Chrome DevTools Performance

Bước 1: Chuẩn bị phép đo có thể lặp lại

Mở bài viết cần kiểm tra bằng Chrome.
Nhấn F12 hoặc chọn More tools → Developer tools.
Mở tab Performance. Chrome hiện khuyến nghị dùng Performance panel và Insights thay cho Performance Insights panel cũ, vốn đã bị loại bỏ từ Chrome 132 (theo Chrome for Developers).
Trong Capture settings, bật CPU throttling ở mức phù hợp, chẳng hạn giảm tốc độ 4 lần để mô phỏng thiết bị yếu hơn.
Tắt cache khi cần kiểm tra quá trình tải, nhưng khi kiểm tra tương tác sau tải hãy giữ một kịch bản nhất quán.

Bước 2: Ghi lại thao tác gây chậm

Bấm Record.
Thực hiện đúng thao tác cần kiểm tra, chẳng hạn mở menu, đóng menu rồi mở tìm kiếm.
Chờ giao diện phản hồi và dừng ghi.
Trong màn hình Live Metrics, xem INP cục bộ sau khi tương tác. Sau đó dùng bản ghi để tìm thao tác tương ứng trong phần Interactions.

Performance panel có thể hiển thị các chỉ số Core Web Vitals trong lúc bạn tương tác và cho phép xem bảng các tương tác, thời lượng cùng phần xử lý liên quan (theo Chrome for Developers). Khi chọn tương tác chậm, hãy lần theo Main track và các vùng có dấu tam giác đỏ. Đây thường là tác vụ dài, tức đoạn công việc chiếm luồng chính quá lâu và trì hoãn phản hồi.

Bước 3: Xác định phần gây chậm

INP thường gồm ba phần: thời gian chờ trước khi event handler chạy, thời gian xử lý callback và thời gian trình duyệt hoàn tất kết xuất. Cách sửa phụ thuộc phần nào chiếm nhiều thời gian:

Độ trễ đầu vào cao: giảm JavaScript khởi chạy khi tải trang, hoãn mã quảng cáo hoặc tiện ích chưa cần thiết, đồng thời loại bỏ plugin và thư viện không sử dụng.
Thời gian xử lý dài: rút gọn callback, tránh vòng lặp trên quá nhiều phần tử và chia tác vụ lớn thành các phần nhỏ. Có thể nhường luồng chính giữa các phần việc bằng setTimeout hoặc scheduler.yield() khi môi trường hỗ trợ.
Độ trễ kết xuất cao: giảm số lượng DOM cần cập nhật, tránh thay đổi hàng trăm phần tử sau một cú nhấp và không tạo lượng lớn HTML bằng JavaScript trong cùng một frame.

Để xem chính xác hàm nào tiêu tốn thời gian, mở Call tree hoặc Bottom-up trong bản ghi. Chrome DevTools cho phép lọc các hoạt động theo thời lượng, loại công việc và mở liên kết tới dòng mã tương ứng khi có source map (theo Chrome for Developers).

Bước 4: Áp dụng các sửa đổi thực tế cho blog

Giảm script bên thứ ba: gỡ widget không còn dùng, trì hoãn mã chia sẻ mạng xã hội và chỉ tải hệ thống bình luận khi người đọc cuộn tới khu vực đó.
Tách JavaScript theo chức năng: mã cho trang liên hệ không nên tải trên mọi bài viết. Với WordPress, kiểm tra plugin nào chèn script toàn site và giới hạn phạm vi enqueue.
Giảm cập nhật DOM: thay vì tạo lại toàn bộ danh sách bài viết khi người dùng bấm lọc, chỉ cập nhật vùng kết quả và trạng thái nút.
Tránh đọc rồi ghi layout liên tục: gom các lần đọc kích thước phần tử, sau đó mới thực hiện thay đổi CSS hoặc DOM để hạn chế layout thrashing.
Ưu tiên phản hồi trực quan: đổi trạng thái nút ngay khi nhận thao tác, hiển thị trạng thái đang tải và thực hiện phần việc nặng sau đó. Phản hồi sớm không thay thế tối ưu thật, nhưng giúp người dùng hiểu lệnh đã được nhận.
Giảm DOM ngoài màn hình: với phần bình luận, mục bài liên quan hoặc khối dài ở cuối bài, cân nhắc tải theo nhu cầu và thử content-visibility sau khi kiểm tra tương thích giao diện. Đây là một hướng được khuyến nghị để giảm công việc kết xuất không cần thiết (theo web.dev).

Nếu blog có nhiều phiên bản ngôn ngữ, hãy kiểm tra cả script của bộ chuyển ngôn ngữ và thành phần điều hướng. Quy trình quản lý bản dịch hreflang không trùng lặp giúp giảm nội dung và logic thừa, dù không thay thế việc tối ưu JavaScript.

Sau mỗi thay đổi, hãy ghi lại cùng một kịch bản trên thiết bị giả lập tương tự. So sánh thời lượng tương tác, tác vụ dài và vùng Main track. Tiếp đó, chạy lại PageSpeed Insights sau khi dữ liệu người dùng thực tế có thời gian cập nhật; điểm phòng thí nghiệm có thể thay đổi theo mạng, máy chủ và thời điểm chạy.

Đừng chỉ kiểm tra nút menu. Hãy lập danh sách 5–10 thao tác quan trọng nhất của blog, gồm tìm kiếm, mục lục, biểu mẫu, bình luận và liên kết tải thêm. Một sửa đổi làm menu nhanh hơn nhưng khiến tìm kiếm hoặc biểu mẫu chậm hơn chưa phải là cải thiện tổng thể.

Nếu mục tiêu của bạn là tăng khả năng phân phối nội dung, tốc độ tương tác nên đi cùng cấu trúc nội dung và trải nghiệm khám phá. Bạn có thể tham khảo thêm cách đưa blog vào Google Discover nhưng không nên xem Discover là lý do để thêm nhiều script theo dõi hoặc widget nặng.

Tóm lại, quy trình cải thiện INP cho blog hiệu quả gồm bốn bước: xem dữ liệu người dùng thật trong PageSpeed Insights, tái hiện thao tác chậm bằng Chrome DevTools Performance, xác định phần thời gian bị lãng phí và kiểm tra lại bằng cùng một kịch bản. Hãy ưu tiên giảm JavaScript không cần thiết, chia tác vụ dài, cập nhật DOM có kiểm soát và đo trên thiết bị di động. INP tốt là kết quả của nhiều cải tiến nhỏ được xác minh liên tục, không phải một thủ thuật duy nhất.

Cải thiện INP cho blog: Đo và sửa bằng PageSpeed Insights, Chrome DevTools