Google Algorithm

INP

Interaction to Next Paint – chỉ số thay thế FID từ tháng 3/2024, đo độ trễ tương tác tổng thể trong suốt vòng đời trang.

4 lượt xem Cập nhật: 29/05/2026

INP là gì?

INP — viết tắt của Interaction to Next Paint — là chỉ số đo lường độ trễ tổng thể khi người dùng tương tác với trang web (như nhấn nút, cuộn, nhập liệu), từ thời điểm bấm cho đến khi giao diện phản hồi rõ ràng (hiển thị pixel mới trên màn hình). Từ tháng 3/2024, Google chính thức thay thế FID (First Input Delay) bằng INP trong Core Web Vitals, vì INP phản ánh trải nghiệm người dùng thực tế tốt hơn: 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 vòng đời trang.

Tại sao quan trọng trong SEO?

INP là một trong ba chỉ số Core Web Vitals được Google sử dụng làm tín hiệu xếp hạng trên cả tìm kiếm di động và máy tính. Trang có INP thấp (≤ 200ms) thường được ưu tiên hiển thị cao hơn trong kết quả tìm kiếm, đặc biệt khi cạnh tranh ở các từ khóa có mức độ cạnh tranh cao. Ngoài ra, INP ảnh hưởng trực tiếp đến tỷ lệ thoát và thời gian ở lại: nếu người dùng nhấn nút nhưng trang “đơ” 1–2 giây, họ dễ rời đi ngay lập tức — điều này làm giảm khả năng chuyển đổi và làm suy yếu hiệu quả SEO tổng thể.

Cách hoạt động

INP theo dõi từng tương tác người dùng hợp lệ (click, tap, keypress, cuộn) trong suốt thời gian trang được mở. Với mỗi tương tác, hệ thống ghi lại:

  • Thời điểm bắt đầu xử lý (tức lúc trình duyệt sẵn sàng chạy JavaScript hoặc cập nhật giao diện);
  • Thời điểm hoàn tất cập nhật giao diện (next paint — lần vẽ lại màn hình đầu tiên sau tương tác);
  • Độ trễ giữa hai mốc đó (tính bằng mili giây).

INP cuối cùng là giá trị cao nhất trong số các độ trễ đã đo — nhưng chỉ tính trên tối đa 50 tương tác đầu tiên, hoặc toàn bộ nếu ít hơn. Đây là điểm khác biệt lớn so với FID: FID chỉ lấy lần tương tác đầu tiên, còn INP đại diện cho “điểm yếu tồi tệ nhất” trong hành vi người dùng thực tế.

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

Để cải thiện INP, cần tập trung vào ba nhóm nguyên nhân chính: xử lý JavaScript quá tải, render chậm và blocking resources. Dưới đây là các bước cụ thể, dựa trên hướng dẫn chính thức từ web.dev và công cụ PageSpeed Insights:

  1. Phân tích dữ liệu thực tế: Dùng Chrome User Experience Report (CrUX) hoặc công cụ PageSpeed Insights để kiểm tra INP của trang ở chế độ “Real URL”. Lưu ý: chỉ số này chỉ xuất hiện nếu trang có đủ dữ liệu sử dụng thực tế (≥ 100 mẫu/tháng).
  2. Tối ưu hóa JavaScript:
    • Chia nhỏ (code splitting) và hoãn tải (defer) các script không cần thiết ở lần render đầu;
    • Giảm khối lượng JavaScript thực thi đồng thời — đặc biệt tránh long tasks (> 50ms);
    • Sử dụng requestIdleCallback cho các tác vụ nền không khẩn cấp.
  3. Tối ưu hóa render:
    • Tránh thay đổi layout liên tục (layout thrashing) khi xử lý sự kiện cuộn hoặc resize;
    • Dùng will-change: transform hoặc transform thay vì top/left để kích hoạt GPU;
    • Giới hạn số lượng phần tử DOM trên trang (dưới 1.500 node là khuyến nghị).
  4. Quản lý tài nguyên chặn:
    • Loại bỏ hoặc hoãn tải CSS không dùng đến (unused CSS);
    • Không nhúng CSS/JS lớn trong thẻ <head> nếu không cần thiết cho render ban đầu;
    • Ưu tiên tải font bằng font-display: optional để tránh chặn render.

Lỗi thường gặp

Dưới đây là những sai lầm phổ biến khiến INP tăng cao và cách khắc phục:

Lỗi Dấu hiệu nhận biết Cách khắc phục
JavaScript chạy dài (> 200ms) sau click Click nút → chờ 0,5–1s mới thấy phản hồi Phân tích bằng Performance tab trong DevTools; tách logic thành các task ngắn hơn; dùng Web Workers cho xử lý nặng.
Cập nhật DOM quá mức trong event listener Hiệu ứng cuộn mượt bị giật, đặc biệt trên thiết bị低端 Dùng debounce hoặc throttle; cập nhật DOM chỉ khi cần thiết; áp dụng virtual scrolling cho danh sách dài.
Font hoặc hình ảnh chặn render Giao diện “trắng” vài trăm mili giây sau load Loại bỏ font display block; preload font quan trọng; dùng loading='lazy' cho ảnh ngoài viewport.

Ví dụ thực tế

Một trang thương mại điện tử tại Việt Nam (giao diện React) từng có INP 480ms do xử lý lọc sản phẩm chạy đồng bộ trên toàn bộ danh sách 2.000 mục. Sau khi áp dụng:

  • Chuyển logic lọc sang Web Worker;
  • Giới hạn hiển thị 50 sản phẩm đầu, tải thêm khi cuộn;
  • Thay thế animation CSS bằng transform và opacity;

→ INP giảm còn 165ms trong vòng 2 tuần. Kết quả: tỷ lệ thoát giảm 22%, thời gian ở lại tăng 37%, và vị trí trung bình trên Google Search cải thiện từ #7 lên #3 cho 12 từ khóa chính.

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

INP có thay thế hoàn toàn FID không?

Có. Từ ngày 12/3/2024, Google đã loại bỏ FID khỏi Core Web Vitals trên mọi nền tảng. Các báo cáo CrUX, PageSpeed Insights và Search Console đều chỉ hiển thị INP thay vì FID. Tuy nhiên, FID vẫn có thể xuất hiện trong dữ liệu lịch sử trước tháng 3/2024.

INP bao nhiêu là đạt chuẩn?

Theo tiêu chuẩn của Google: INP ≤ 200ms là tốt, 201–500ms là cần cải thiện, và > 500ms là kém. Lưu ý: đây là ngưỡng áp dụng chung cho mọi trang, không phân biệt thiết bị hay khu vực. Tuy nhiên, ngưỡng chấp nhận được trên thiết bị低端 có thể linh hoạt hơn tùy trường hợp.

INP có đo trên mobile và desktop như nhau không?

Có, nhưng dữ liệu được thu thập riêng biệt. CrUX báo cáo INP theo thiết bị (mobile/desktop/tablet), và Google xếp hạng dựa trên phiên bản người dùng đang truy cập. Một trang có INP tốt trên desktop nhưng kém trên mobile sẽ bị đánh giá thấp khi người dùng tìm kiếm từ điện thoại — điều này rất phổ biến ở Việt Nam.