Google Search Console

INP (Interaction to Next Paint)

Chỉ số thay thế FID, đo độ trễ phản hồi trong suốt vòng đời tương tác, bao quát hơn và đáng tin cậy hơn.

5 lượt xem Cập nhật: 30/05/2026

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

INP (Interaction to Next Paint) là chỉ số đo độ trễ phản hồi của trang web khi người dùng tương tác — ví dụ như nhấn nút, cuộn, nhập liệu hoặc chạm trên thiết bị cảm ứng. Khác với FID (First Input Delay), INP không chỉ xét lần tương tác đầu tiên mà đánh giá tất cả các tương tác quan trọng trong suốt thời gian người dùng ở trên trang, sau đó chọn giá trị xấu nhất (tức là độ trễ cao nhất) làm kết quả cuối cùng.

INP được Google công bố chính thức vào tháng 3/2023 và trở thành một trong ba chỉ số Core Web Vitals bắt buộc từ tháng 3/2024, thay thế FID trong báo cáo Google Search Console và PageSpeed Insights. Đơn vị đo là mili giây (ms), và ngưỡng đạt chuẩn là ≤ 200 ms. Giá trị từ 201–500 ms được coi là cần cải thiện; trên 500 ms là kém.

Tại sao quan trọng trong SEO?

INP ảnh hưởng trực tiếp đến trải nghiệm người dùng — yếu tố Google xác nhận là tín hiệu xếp hạng rõ ràng. Kể từ bản cập nhật Core Web Vitals năm 2024, trang có INP vượt ngưỡng xấu sẽ gặp khó khăn hơn trong việc duy trì hoặc cải thiện vị trí trên trang kết quả tìm kiếm (SERP), đặc biệt với các truy vấn nhạy cảm về tốc độ như 'mua online', 'đăng ký ngay', hay 'đặt lịch nhanh'.

Bên cạnh đó, INP xuất hiện trong Google Search Console > Báo cáo Trải nghiệm người dùng > Core Web Vitals, giúp chủ website xác định chính xác URL nào đang gây cản trở tương tác — điều mà FID không thể làm được do giới hạn ở tương tác đầu tiên. Đây là cơ sở để ưu tiên tối ưu hóa nội dung và kỹ thuật theo dữ liệu thực tế, không phải phỏng đoán.

Cách hoạt động

INP theo dõi toàn bộ chu kỳ của mỗi tương tác hợp lệ: từ thời điểm người dùng bắt đầu thao tác (ví dụ: nhấn giữ nút 'Thêm vào giỏ') cho đến khi trình duyệt hoàn tất vẽ lại (paint) khung hình tiếp theo phản ánh thay đổi đó (ví dụ: hiển thị thông báo 'Đã thêm'). Quá trình này bao gồm ba giai đoạn:

  • Input Delay: Thời gian chờ CPU xử lý sự kiện (do JavaScript đang chạy dài, render chặn…)
  • Processing Time: Thời gian thực thi mã xử lý sự kiện (ví dụ: chạy hàm validate form)
  • Presentational Delay: Thời gian từ khi xử lý xong đến khi màn hình cập nhật (bao gồm layout, paint, composite)

INP lấy tổng thời gian của cả ba giai đoạn trong tương tác tồi tệ nhất — không phải trung bình, cũng không phải lần đầu. Điều này phản ánh đúng nhất điểm nghẽn thực sự ảnh hưởng đến người dùng.

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

Để đo và cải thiện INP, bạn cần kết hợp công cụ kiểm tra và hành động kỹ thuật cụ thể:

  1. Đo lường thực tế: Dùng Google Search Console > Báo cáo Core Web Vitals (dữ liệu trường hợp sử dụng thật). Kiểm tra tab 'URL có vấn đề' để lọc theo INP.
  2. Phân tích chi tiết: Mở Chrome DevTools > Tab 'Performance', nhấn Ctrl+Shift+P > gõ 'Show Interactions' để bật nhãn tương tác. Ghi lại thao tác người dùng và xem timeline từng sự kiện.
  3. Xác định nguyên nhân: Tập trung vào các tác vụ JavaScript dài (> 50 ms), đặc biệt là trong event listener (click, input, scroll). Dùng 'Long Tasks' trong Performance panel để phát hiện.
  4. Tối ưu hóa:
    • Chia nhỏ tác vụ nặng bằng setTimeout hoặc queueMicrotask
    • Tránh chạy mã đồng bộ trong event handler — chuyển sang bất đồng bộ hoặc lazy-load logic không cấp thiết
    • Giảm kích thước và trì hoãn tải script không cần thiết (thông qua defer hoặc loading='lazy' cho component)
    • Thay thế animation CSS bằng transform và opacity thay vì top, height để tránh layout thrashing
  5. Kiểm tra lại: Sau tối ưu, đợi 28 ngày để dữ liệu Search Console cập nhật đầy đủ, hoặc dùng CrUX Dashboard để so sánh trước/sau.

Lỗi thường gặp

Lỗi Dấu hiệu Cách khắc phục
JavaScript chạy dài trong event listener Timeline hiển thị 'Long Task' trùng với thời điểm nhấn nút Tách logic thành các phần nhỏ, dùng requestIdleCallback hoặc phân tán qua nhiều frame
Render-blocking script ở đầu <head> INP cao ngay cả trên trang tĩnh, không có tương tác phức tạp Di chuyển script ra cuối <body>, thêm defer, hoặc loại bỏ nếu không cần thiết cho render ban đầu
Thiếu tối ưu cho thiết bị di động INP tốt trên desktop nhưng xấu trên mobile (theo báo cáo CrUX) Kiểm tra touch event handler, đảm bảo không gắn ontouchstart thừa; dùng passive: true cho scroll listeners

Ví dụ thực tế

Một trang thương mại điện tử ghi nhận INP = 640 ms trong Search Console, tập trung ở các URL danh mục sản phẩm. Phân tích DevTools cho thấy khi người dùng nhấn nút 'Lọc theo giá', trình duyệt mất 420 ms để xử lý hàm JavaScript lọc — do chạy vòng lặp qua 12.000 sản phẩm trong main thread. Đội ngũ đã áp dụng hai thay đổi: (1) chuyển lọc sang phía máy chủ (API riêng trả kết quả đã lọc), (2) thêm loading skeleton để che độ trễ còn lại. Sau 3 tuần, INP giảm xuống còn 132 ms và tỷ lệ thoát trên trang danh mục giảm 18% — đồng thời CTR từ SERP tăng 9% theo dữ liệu Search Console.

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

INP khác FID ở điểm nào?

FID chỉ đo độ trễ của tương tác đầu tiên và không tính các tương tác sau đó — nên dễ bỏ sót vấn đề xảy ra muộn hơn trong phiên. INP đo tất cả tương tác quan trọng, chọn giá trị cao nhất, do đó phản ánh đúng hơn trải nghiệm tổng thể. FID cũng không khả dụng trên các tương tác không gây thay đổi UI (ví dụ: hover), trong khi INP có thể ghi nhận nếu chúng kích hoạt paint.

INP có phụ thuộc vào thiết bị không?

Có. INP được thu thập từ dữ liệu thực tế (CrUX), nên phụ thuộc vào cấu hình thiết bị, mạng và hệ điều hành của người dùng. Một trang có thể đạt INP tốt trên máy tính nhưng kém trên điện thoại Android đời cũ. Google báo cáo riêng theo nhóm thiết bị trong Search Console — bạn nên kiểm tra cả hai tab 'Desktop' và 'Mobile'.

Có thể kiểm tra INP bằng Lighthouse không?

Lighthouse (phiên bản 11.0+) hỗ trợ đo INP trong chế độ thử nghiệm (lab), nhưng kết quả chỉ mang tính tham khảo. Vì INP là chỉ số dựa trên dữ liệu thực tế, nên chỉ Google Search Console và CrUX Dashboard mới cung cấp giá trị đáng tin cậy. Lighthouse có thể giúp phát hiện nguyên nhân, nhưng không thay thế được dữ liệu trường hợp sử dụng thật.