INP thay thế FID 2024 — metric mới đo interaction performance

INP (Interaction to Next Paint) là chỉ số Core Web Vitals thay thế FID từ tháng 3/2024. INP đo thời gian phản hồi tương tác của 75% lượt tương tác trong phiên, không chỉ lần đầu.

INP là gì và đo thế nào

INP đo độ trễ giữa lúc người dùng tương tác (click, chạm, nhấn phím) đến khi trình duyệt vẽ frame phản hồi tiếp theo. Khác với FID chỉ đo lần đầu, INP ghi lại tất cả lượt tương tác trong phiên và lấy p98 làm giá trị cuối.

Điều này có nghĩa là chỉ cần một lượt tương tác lag trên 200ms cũng đủ để INP fail cho toàn phiên đó.

Cách INP tính chính xác

• Trình duyệt ghi nhận mọi lượt tương tác: click, chạm, nhấn phím, kéo thả.
• Đo từ thời điểm tương tác đến khi trình duyệt vẽ frame hiển thị thay đổi tiếp theo.
• Kết quả: lấy p98 của tất cả lượt tương tác trong vòng đời trang.
• CrUX tổng hợp p75 của p98 này từ người dùng thực trong 28 ngày.

3 thành phần INP timeline

Hiểu 3 thành phần này giúp xác định đúng vị trí tắc nghẽn khi debug INP fail.

1. Input delay: thời gian từ lúc người dùng tương tác đến khi event handler bắt đầu chạy. Bị chặn khi main thread bận.
2. Processing time: thời gian event handler và callback chạy. Code chậm là nguyên nhân chính của thành phần này.
3. Presentation delay: thời gian từ khi handler xong đến khi trình duyệt vẽ frame. Layout và style nặng gây ra trì hoãn ở đây.

Vì sao Google thay FID bằng INP

FID có 3 hạn chế lớn khiến nó không phản ánh đúng trải nghiệm người dùng thực tế. INP giải quyết cả 3 vấn đề đó.

Hiểu lý do thay đổi này giúp lập luận đúng khi giải thích với khách hàng. FID cũ pass không có nghĩa INP sẽ pass.

Hạn chế cụ thể của FID

• Chỉ đo lần đầu: trang có thể lag ở lượt tương tác thứ 5 mà FID không bắt được. INP đo tất cả.
• Bỏ qua processing và paint: FID chỉ đo từ input đến lúc handler bắt đầu chạy — handler chạy 2s vẫn pass FID. INP đo toàn bộ pipeline.
• Thiếu loại sự kiện: FID chỉ đo click và chạm. INP bổ sung thêm nhấn phím, kéo thả, dừng cuộn.

Mốc thời gian migration

• Tháng 5/2022: INP ra mắt ở trạng thái thử nghiệm.
• Tháng 5/2023: Google thông báo INP sẽ thay thế FID.
• 12/3/2024: INP chính thức trở thành Core Web Vital. FID ngừng hoạt động.
• Search Console và PSI tự động chuyển từ FID sang INP.

5 nguyên nhân INP fail phổ biến

INP fail (trên 200ms) thường do một trong 5 nguyên nhân về mặt code. Xác định đúng nguyên nhân quan trọng hơn sửa ngẫu nhiên.

Dùng tab Performance của Chrome DevTools để ghi lại lượt tương tác và xem phân tích chi tiết.

Sửa sai nguyên nhân có thể mất nhiều tuần mà INP không cải thiện.

1. Long task chặn main thread

Task trên 50ms trên main thread sẽ chặn xử lý input. Thường gặp: phân tích JSON lớn, cập nhật DOM hàng loạt, XHR đồng bộ.

Chrome DevTools tô viền đỏ task trên 50ms trong timeline hiệu năng.

Cách sửa: chia task thành micro-task qua setTimeout(fn, 0) hoặc scheduler.yield().

2. Script bên thứ ba nặng

Chat widget, Google Tag Manager tải đồng bộ, quảng cáo và công cụ A/B test thường ship 100–500KB JS trên main thread. Cần defer hoặc lazy load tất cả script bên thứ ba.

Cách xác định culprit: tắt từng plugin/script, đo INP bằng DevTools để so sánh delta.

3. Event handler chạy code chậm

• Handler onClick truy vấn hơn 100 phần tử DOM rồi thao tác.
• Handler onScroll không debounce, kích hoạt 60 lần/giây.
• Kiểm tra form onChange chạy regex phức tạp.
• Component React render lại cây quá lớn (trên 5.000 node).

4. Layout thrashing trong handler

Handler đọc thuộc tính DOM (offsetWidth, getBoundingClientRect) sau khi đã sửa DOM = buộc trình duyệt tính toán lại layout đồng bộ. Pattern này phổ biến trong code legacy.

Cách sửa: gộp tất cả thao tác đọc trước, gộp tất cả thao tác ghi sau (ReadAfterWrite pattern), dùng requestAnimationFrame.

5. Reflow cưỡng bức từ ảnh hoặc font

Ảnh hoặc font tải đúng lúc người dùng đang tương tác buộc trình duyệt tính toán lại bố cục. Cách sửa: đặt trước không gian cho ảnh (width/height), preload font với font-display: swap.

Không tải font bất đồng bộ khi người dùng đang tương tác.

Đo INP — 3 cách thực tế

Đo INP cần mô phỏng lượt tương tác thực, không chỉ chờ trang tải xong như với LCP. Cần xây dựng kịch bản test chuẩn cho từng loại trang.

Tham khảo thêm bài đo LCP để so sánh quy trình đo giữa hai chỉ số.

PageSpeed Insights — dữ liệu thực tế

Tab “Origin Summary” trong PSI hiển thị INP từ CrUX 28 ngày. Mục “Largest Interaction” tô sáng lượt tương tác tệ nhất và selector phần tử.

Ưu điểm: dữ liệu người dùng thực. Nhược điểm: lag 28 ngày, không debug được trực tiếp.

Chrome DevTools — ghi lại phiên làm việc

1. Mở DevTools (F12) → tab Performance.
2. Bật “Web Vitals” trong phần cài đặt.
3. Click record → click/chạm vào phần tử tương tác → dừng sau 2–5s.
4. Timeline có marker “INP” — click để xem phần tử và phân tích chi tiết.
5. Xem track “Long Tasks” — task trên 50ms là thủ phạm cần điều tra.

web-vitals.js + theo dõi RUM

import {onINP} from 'web-vitals';

onINP((metric) => {
  gtag('event', 'web_vitals', {
    metric_name: 'INP',
    metric_value: Math.round(metric.value),
    metric_id: metric.id,
    interaction_target: metric.attribution?.interactionTarget,
  });
});

Dữ liệu attribution hiển thị phần tử tương tác cụ thể và selector. Đây là thông tin quan trọng để debug trên môi trường production — biết chính xác nút hoặc form nào đang lag trong thực tế.

Thứ tự ưu tiên khi sửa INP

Không nên sửa tất cả cùng lúc. Ưu tiên theo tác động giảm dần.

Sửa đúng 1–2 nguyên nhân đầu thường đã giảm INP đáng kể mà không cần refactor toàn bộ codebase.

Bước 1 — Xác định long task culprit

Dùng DevTools Performance tab, ghi lại lượt tương tác có INP cao nhất. Click vào long task, xem stack trace để biết file/function gây ra.

Đây là bước không thể bỏ qua.

Bước 2 — Defer script bên thứ ba không critical

Thêm thuộc tính defer hoặc async cho mọi script tracker và chat widget. Plugin “Async JavaScript” tự động xử lý cho mọi script được enqueue trong WordPress.

Giảm input delay đáng kể mà rủi ro thấp.

Bước 3 — Chia long task thành micro-task

Dùng scheduler.yield() hoặc setTimeout(fn, 0) để chia task lớn thành nhiều chunk nhỏ. Main thread sẽ có cơ hội xử lý input giữa các chunk.

Bước 4 — Tối ưu re-render React hoặc Vue

Dùng useMemo và useCallback để tránh re-render không cần thiết. Áp dụng virtualization (react-window) cho danh sách dài.

React 18 concurrent rendering giúp giảm INP đáng kể mà không cần refactor nhiều.

Checklist INP cho shop WordPress

1. Đo INP baseline qua PSI và DevTools trước khi thay đổi bất cứ điều gì.
2. Ghi lại lượt tương tác INP cao nhất bằng DevTools Performance tab.
3. Xác định long task culprit qua stack trace.
4. Defer tất cả script bên thứ ba không critical.
5. Tắt từng plugin lần lượt để xác định plugin gây INP cao nhất.
6. Thêm debounce cho handler onScroll và onChange.
7. Áp dụng ReadAfterWrite pattern cho code thao tác DOM.
8. Preload font và đặt trước không gian cho ảnh.
9. Đo lại INP sau mỗi thay đổi.
10. Thiết lập web-vitals.js để theo dõi INP liên tục trên production.

Bài liên quan

• Core Web Vitals 2026 — tổng quan 3 chỉ số
• Tối ưu LCP — đo và sửa
• Sửa CLS — nguyên nhân dịch chuyển bố cục
• TBT — tổng thời gian block và quan hệ với INP
• Defer vs async — khi nào dùng cái nào

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

Cần audit INP và tối ưu hiệu năng tương tác cho shop online — defer JS, chia long task, và thiết lập theo dõi RUM? Xem dịch vụ tối ưu Core Web Vitals của Web22.