Interaction to Next Paint (INP)

Interaction to Next Paint (INP) là gì?

Interaction to Next Paint (INP) là chỉ số đo lường độ trễ phản hồi tổng thể của mọi tương tác người dùng trên trang web — như nhấn nút, cuộn, gõ vào ô nhập liệu hoặc chạm trên thiết bị cảm ứng. Từ tháng 3/2024, Google chính thức thay thế First Input Delay (FID) bằng INP trong Core Web Vitals để đánh giá trải nghiệm người dùng một cách toàn diện hơn.

INP không chỉ xem xét tương tác đầu tiên (như FID), mà tính toán độ trễ lớn nhất trong tất cả các tương tác xảy ra trong suốt thời gian người dùng ở trên trang — bao gồm thời gian chờ xử lý (input delay), thời gian thực thi mã JavaScript (processing time) và thời gian hiển thị kết quả lên màn hình (presentation delay). Giá trị INP được báo cáo dưới dạng miligiây (ms), và mục tiêu tối ưu là ≤200ms.

Tại sao quan trọng trong SEO?

INP là một trong ba chỉ số Core Web Vitals được Google sử dụng trực tiếp trong thuật toán xếp hạng tìm kiếm (từ bản cập nhật năm 2021, được củng cố sau tháng 3/2024). Một trang có INP cao (>200ms) thường gây cảm giác chậm, giật, hoặc 'không phản hồi', dẫn đến tăng tỷ lệ thoát và giảm thời gian ở lại — hai tín hiệu gián tiếp ảnh hưởng tới thứ hạng.

Google xác nhận rằng INP được thu thập từ dữ liệu thực tế (field data) qua Chrome User Experience Report (CrUX), không phải từ kiểm tra mô phỏng. Điều này nghĩa là chỉ số phản ánh đúng trải nghiệm của người dùng thật — đặc biệt trên thiết bị di động, nơi tài nguyên hạn chế và mạng không ổn định.

Khác với các chỉ số kỹ thuật thuần túy, INP gắn liền với hành vi: nếu người dùng tương tác nhiều lần (ví dụ: mở nhiều tab sản phẩm, lọc danh sách, gửi form liên hệ), thì INP sẽ phản ánh 'điểm yếu tệ nhất' trong chuỗi đó — giúp nhà phát triển ưu tiên sửa lỗi nghiêm trọng nhất trước.

Cách hoạt động

INP được tính dựa trên ba thành phần chính của mỗi tương tác:

1. Input Delay: Thời gian từ khi người dùng tương tác (ví dụ: nhấn chuột) đến khi trình duyệt bắt đầu xử lý sự kiện — thường do main thread đang bận chạy JavaScript dài.
2. Processing Time: Thời gian trình duyệt thực thi event handler (ví dụ: hàm onClick), bao gồm cả việc cập nhật DOM.
3. Presentation Delay: Thời gian từ khi xử lý xong đến khi khung hình tiếp theo được vẽ (next paint), bao gồm layout, paint và composite.

INP lấy giá trị cao nhất trong số tất cả các tương tác hợp lệ trên trang (ít nhất 1 tương tác mới được tính; tương tác không dẫn đến thay đổi hiển thị — ví dụ: hover không trigger repaint — sẽ bị loại).

Hướng dẫn thực hiện

Để cải thiện INP, cần tập trung vào việc giảm tải cho main thread và tối ưu hóa chu kỳ render. Dưới đây là các bước cụ thể:

1. Phân tích INP thực tế: Dùng PageSpeed Insights hoặc Web Vitals extension để kiểm tra field data và lab data. Lưu ý: CrUX chỉ báo cáo INP nếu trang có đủ lượng truy cập (≥100 lượt/tháng).
2. Xác định tương tác gây chậm: Trong DevTools → Tab Performance, ghi lại phiên tương tác (record), rồi tìm các event dài >200ms trong phần Main. Nhấn vào từng event để xem call stack và hàm nào chiếm nhiều thời gian.
3. Tối ưu JavaScript: Chia nhỏ task dài (>50ms) bằng setTimeout hoặc queueMicrotask; chuyển logic nặng sang Web Worker; loại bỏ hoặc hoãn tải script không cần thiết (lazy-load third-party widget).
4. Tối ưu DOM và layout: Tránh layout thrashing (đọc-ghi DOM liên tục); dùng transform và opacity thay vì thay đổi width, top để tránh repaint/layout.
5. Giảm kích thước và độ trễ của thư viện: Đánh giá lại các thư viện như React, Vue, hoặc jQuery — nếu dùng phiên bản cũ hoặc không cần tính năng nào, hãy nâng cấp hoặc thay thế bằng giải pháp nhẹ hơn (ví dụ: Preact).

Lỗi thường gặp

• Chạy JavaScript đồng bộ dài trong event handler: Ví dụ: xử lý dữ liệu CSV lớn ngay trong onClick. Cách khắc phục: Chuyển sang xử lý bất đồng bộ hoặc phân mảnh dữ liệu.
• Thiếu debounce hoặc throttle cho sự kiện cuộn (scroll) hoặc thay đổi kích thước (resize): Gây hàng chục callback mỗi giây. Cách khắc phục: Áp dụng requestIdleCallback hoặc thư viện như Lodash.
• Render-blocking third-party script: Widget chat, analytics hoặc quảng cáo chặn main thread. Cách khắc phục: Tải bằng async hoặc defer; giới hạn số lần gọi API; dùng iframe sandbox nếu khả thi.
• Thiếu will-change hoặc contain cho phần tử động: Dẫn đến layout recalculations không cần thiết. Cách khắc phục: Áp dụng contain: layout paint cho container có animation.

Ví dụ thực tế

Một trang thương mại điện tử có nút "Thêm vào giỏ" với INP đo được là 480ms. Khi phân tích trong DevTools, phát hiện hàm addToCart() thực hiện 3 việc cùng lúc: (1) validate form, (2) gọi API đồng bộ, (3) cập nhật DOM toàn bộ giỏ hàng (gồm 10 sản phẩm). Sau khi tách riêng phần validate (chạy ngay), gọi API bất đồng bộ, và chỉ cập nhật DOM cho sản phẩm vừa thêm (thay vì render lại toàn bộ), INP giảm còn 165ms — đạt mức tốt.

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

INP khác gì so với FID?

FID chỉ đo độ trễ của tương tác đầu tiên và không tính thời gian xử lý hay vẽ lại. INP đo tất cả tương tác, chọn giá trị tệ nhất, và bao gồm cả processing + presentation delay — nên phản ánh chính xác hơn trải nghiệm thực tế.

INP có áp dụng cho trang tĩnh không có tương tác?

Nếu trang không có bất kỳ sự kiện nào (click, input, touch), INP sẽ không được tính — nhưng điều này rất hiếm. Ngay cả trang tin tức cũng thường có nút chia sẻ, menu bật ra, hoặc form đăng ký. Nếu không có tương tác hợp lệ, CrUX sẽ không báo cáo INP cho trang đó (giá trị hiển thị là Not Available).

Có thể kiểm tra INP trên localhost không?

Có thể đo trong môi trường lab (DevTools, Lighthouse), nhưng giá trị chỉ mang tính tham khảo. INP chính thức dùng trong SEO là field data từ CrUX — yêu cầu trang đã được index và có đủ lưu lượng thực. Kết quả lab có thể khác field data tùy thiết bị, mạng và cấu hình người dùng — tùy trường hợp.

Chỉ số	Đo lường	Mục tiêu tốt	Thời điểm áp dụng chính thức	Ghi chú
FID	Độ trễ tương tác đầu tiên	≤100ms	Trước tháng 3/2024	Không còn trong Core Web Vitals
INP	Độ trễ tệ nhất trong tất cả tương tác	≤200ms	Từ tháng 3/2024	Thay thế FID hoàn toàn