Core Web Vitals 2026: xử lý INP khi website đã đạt LCP tốt

Nhiều website Việt đạt LCP dưới 2,5s và CLS gần bằng 0 nhưng vẫn hiện “Cần cải thiện” trong báo cáo Core Web Vitals. Thủ phạm gần như luôn là INP (Interaction to Next Paint) — chỉ số đo độ trễ từ lúc người dùng chạm/nhấp cho tới khung hình phản hồi tiếp theo. Ngưỡng tốt là dưới 200ms, và khác với LCP, INP đo toàn bộ vòng đời phiên chứ không chỉ lần tải đầu.

Vì sao INP khó hơn LCP

LCP có thể vá bằng CDN, nén ảnh và preload. INP thì phụ thuộc vào JavaScript chạy trên luồng chính. Mỗi tác vụ dài trên 50ms đều chặn phản hồi. Trên site WordPress thương mại điện tử điển hình, ba nguồn gây long task lớn nhất là: script chat/popup của bên thứ ba, thư viện slider, và trình theo dõi quảng cáo nạp đồng bộ.

Đo đúng trước khi sửa

• ✓Dữ liệu thực (CrUX) trong Search Console — đây là con số Google dùng, trễ 28 ngày
• ✓PageSpeed Insights phần “Discover what your real users are experiencing” — chia theo desktop/mobile
• ✓Thư viện web-vitals đẩy sự kiện INP về GA4 kèm tên phần tử gây chậm (attribution build)
• ✓Chrome DevTools → Performance → ghi lại thao tác thật, lọc Long Tasks

Các bản vá theo thứ tự hiệu quả

• ✓Trì hoãn mọi script không cần cho lần vẽ đầu: chat, heatmap, remarketing — nạp sau sự kiện tương tác đầu tiên hoặc sau 3 giây
• ✓Chia nhỏ tác vụ dài bằng scheduler.yield() hoặc setTimeout 0 giữa các đoạn xử lý
• ✓Tránh cập nhật state đồng bộ cho danh sách dài — dùng ảo hóa danh sách khi hiển thị trên 100 phần tử
• ✓Loại bỏ layout thrashing: đọc kích thước DOM một lần rồi mới ghi, không xen kẽ
• ✓Thay slider nặng bằng CSS scroll-snap, tiết kiệm trung bình 90–140KB JS

Kinh nghiệm thực tế: trên một site WooCommerce 8.000 sản phẩm, chỉ riêng việc trì hoãn widget chat và thay slider bằng scroll-snap đã kéo INP từ 412ms xuống 186ms sau 4 tuần, kéo theo tỷ lệ thoát trên mobile giảm 9%.