INP là gì?

INP là gì?

INP (Interaction to Next Paint) là chỉ số thuộc Core Web Vitals, đo độ trễ phản hồi của trang web đối với các thao tác của người dùng (click, gõ phím, chạm màn hình) trong suốt vòng đời truy cập trang, không chỉ riêng lần tương tác đầu tiên.

INP thay thế FID như thế nào?

INP chính thức thay thế FID (First Input Delay) trong bộ Core Web Vitals từ tháng 3/2024. Khác biệt cốt lõi: FID chỉ đo độ trễ của lần tương tác đầu tiên của người dùng, trong khi INP đo và lấy giá trị đại diện (thường gần với giá trị cao nhất) trong toàn bộ các lần tương tác trong suốt phiên truy cập – phản ánh toàn diện hơn trải nghiệm phản hồi thực tế, đặc biệt với các trang có nhiều tương tác liên tục.

Ngưỡng đánh giá INP

Nguyên nhân phổ biến khiến INP kém

• JavaScript nặng chạy trên luồng chính (main thread), chặn trình duyệt phản hồi thao tác người dùng
• Quá nhiều thư viện/script bên thứ ba (quảng cáo, chat widget, tracking) chạy đồng thời
• Xử lý sự kiện (event handler) không tối ưu, thực hiện quá nhiều tính toán trong một lần tương tác

Cách cải thiện INP

• Chia nhỏ các tác vụ JavaScript nặng thành nhiều phần nhỏ hơn (break up long tasks) để trình duyệt có thể phản hồi tương tác giữa các phần
• Trì hoãn tải các script không cần thiết ngay lập tức (lazy load, defer)
• Giảm số lượng thư viện bên thứ ba, đánh giá lại script nào thực sự cần thiết
• Tối ưu code xử lý sự kiện để phản hồi nhanh, tách các phần tính toán nặng ra khỏi luồng chính khi có thể

INP so với LCP và CLS

Xem tổng quan tại bài Core Web Vitals là gì?. LCP đo tốc độ hiển thị nội dung ban đầu, còn INP đo khả năng phản hồi trong suốt quá trình sử dụng, và CLS đo độ ổn định hình ảnh – ba khía cạnh trải nghiệm khác nhau và độc lập với nhau.

Ví dụ debug INP thực tế

Một trang có bộ lọc sản phẩm dùng JavaScript: khi người dùng click chọn một tùy chọn lọc, trang mất gần 600ms mới phản hồi (mức Kém) vì toàn bộ danh sách sản phẩm được tính toán lại và render đồng thời trên luồng chính. Giải pháp: chia nhỏ việc render thành từng phần nhỏ (chunking), hiển thị trạng thái loading tức thời cho phần tương tác trong khi xử lý dữ liệu chạy nền, giúp INP giảm xuống dưới 200ms – người dùng cảm nhận trang phản hồi ngay lập tức dù dữ liệu vẫn đang xử lý phía sau.

Những sai lầm thường gặp

• Chỉ tối ưu cho lần tương tác đầu tiên (thói quen cũ từ thời FID) mà bỏ qua các tương tác sau đó trong phiên truy cập
• Thêm quá nhiều script bên thứ ba mà không đánh giá tác động đến hiệu năng tổng thể

INP có khó cải thiện hơn LCP không?

Thường khó hơn, vì INP phụ thuộc vào toàn bộ hành vi JavaScript trong suốt phiên truy cập chứ không chỉ một lần tải trang, đòi hỏi rà soát sâu về kiến trúc code (đặc biệt với website dùng nhiều framework JS phức tạp hoặc nhiều script bên thứ ba như quảng cáo, chat, tracking).

Câu hỏi thường gặp

Trang tĩnh ít tương tác có cần quan tâm INP không?

Nếu trang gần như không có tương tác nào (thuần đọc nội dung), Google có thể không thu thập đủ dữ liệu INP để đánh giá – nhưng vẫn nên đảm bảo các tương tác cơ bản (menu, nút bấm) phản hồi nhanh.

Có công cụ nào đo INP không?

PageSpeed Insights, Chrome User Experience Report (CrUX), và báo cáo Core Web Vitals trong Google Search Console đều cung cấp dữ liệu INP thực tế.

Nguồn tham khảo

• web.dev (Google) – Interaction to Next Paint (INP)

Nguồn tham khảo

• web.dev (Google) - INP