INP là gì: đo độ phản hồi website và sửa tương tác chậm

Website bán hàng hay đặt lịch có thể chậm ở khâu ít được đo: khách bấm nút nhưng màn hình chưa đổi gì. Chỉ số INP (Interaction to Next Paint) đo đúng khoảnh khắc đó và là chỉ số độ phản hồi trong bộ Core Web Vitals của Google.

Bài này giải thích INP đo gì, ngưỡng nào là tốt, đo bằng công cụ nào và sửa theo từng phần của tương tác. Nguồn chính là web.dev, Chrome for Developers, Google Search Central và Web Almanac 2025, đối chiếu đến ngày 23/10/2026.

Click Star đã có bài riêng về Core Web Vitals, tối ưu ảnh và Google Tag Manager; bài này đi sâu vào INP. Click Star có dịch vụ thiết kế website chuẩn SEO tải nhanh, nên có lợi ích liên quan đến chủ đề.

Điểm chính

• INP đo thời gian từ lúc người dùng bấm, chạm hoặc gõ phím đến khi trình duyệt vẽ khung hình kế tiếp. Tốt khi không quá 200 mili giây, kém khi trên 500 mili giây, tính ở phân vị 75 của các lượt xem trang.
• INP thay FID thành chỉ số Core Web Vitals chính thức ngày 12/3/2024. FID chỉ đo độ trễ của tương tác đầu tiên, còn INP quan sát mọi tương tác trong suốt lượt xem trang.
• Mỗi tương tác có 3 phần: độ trễ nhập, thời gian xử lý và độ trễ hiển thị. Phải biết phần nào chậm thì mới sửa đúng chỗ.
• Hãy bắt đầu bằng dữ liệu thực địa (PageSpeed Insights, Search Console), rồi gỡ lỗi bằng DevTools. Lighthouse chạy tải trang thông thường không đo INP vì không có người dùng thao tác.
• Theo Web Almanac 2025, 77% website trên di động và 97% trên máy tính có INP tốt (dữ liệu tháng 7/2025, chỉ gồm website nằm trong CrUX). Click Star chưa tìm thấy số riêng cho Việt Nam.
• Sửa INP thường là chia nhỏ việc JavaScript chiếm luồng chính: chia tác vụ dài, hoãn script bên thứ ba, giữ DOM gọn. Google nói Core Web Vitals tốt không bảo đảm xếp hạng cao.

INP là gì và khác FID ở đâu

Theo web.dev (cập nhật 2/9/2025, đọc 23/10/2026), INP quan sát độ trễ của mọi lần bấm chuột, chạm màn hình và nhấn phím trong suốt lượt xem trang. Giá trị cuối cùng là tương tác chậm nhất, có bỏ qua ngoại lệ: với mỗi 50 tương tác thì bỏ 1 tương tác chậm nhất.

Giá trị của trang được báo ở phân vị 75 của các lượt xem, nghĩa là 3 trong 4 lượt xem đạt mức đó hoặc tốt hơn. Rê chuột, thu phóng và cuộn trang không được tính; trang không có tương tác nào, hoặc chỉ bị bot truy cập, sẽ không có giá trị INP.

Ngưỡng do web.dev nêu: không quá 200 mili giây là tốt, trên 200 đến 500 mili giây là cần cải thiện, trên 500 mili giây là kém. Trợ giúp của Search Console (đọc 23/10/2026) dùng cùng các ngưỡng này.

FID, chỉ số tiền nhiệm, chỉ đo thời gian chờ trước tương tác đầu tiên. Bài thông báo trên web.dev (cập nhật 31/1/2024) cho biết INP thay FID ngày 12/3/2024. Nhật ký thay đổi INP của Chromium (đọc 23/10/2026) không có dòng nào nói về đổi ngưỡng.

Một tương tác gồm 3 phần

Web.dev chia độ trễ của một tương tác thành 3 phần, tổng của chúng là độ trễ của tương tác đó. Phần 1 là độ trễ nhập (input delay): từ lúc người dùng thao tác đến lúc hàm xử lý bắt đầu chạy. Phần 2 là thời gian xử lý (processing duration): các hàm xử lý chạy xong.

Phần 3 là độ trễ hiển thị (presentation delay): từ lúc hàm xử lý xong đến lúc trình duyệt vẽ khung hình có kết quả.

Cần chia vì cách sửa khác nhau: độ trễ nhập cao thường do luồng chính đang bận, xử lý chậm do mã trong hàm, độ trễ hiển thị cao do dựng giao diện nặng.

Đo INP bằng dữ liệu thực địa trước, phòng thí nghiệm sau

Dữ liệu thực địa

Web.dev khuyên bắt đầu từ dữ liệu người dùng thật, vì phòng thí nghiệm chỉ phản ánh thao tác của người kiểm thử.

PageSpeed Insights lấy dữ liệu thực địa từ Chrome User Experience Report (CrUX) trong 28 ngày gần nhất, theo tài liệu Google for Developers (cập nhật 21/10/2024). Nếu trang chưa đủ mẫu, công cụ lùi về cả tên miền; trang đạt khi phân vị 75 của cả 3 chỉ số đều tốt (thiếu dữ liệu INP thì xét LCP và CLS).

Theo tài liệu phương pháp CrUX (cập nhật 20/6/2024), trang phải công khai và đủ phổ biến, và dữ liệu chỉ đến từ Chrome trên máy tính và Android. Chrome trên iOS, Android WebView và Edge không gửi dữ liệu, nên khách dùng iPhone không có trong số liệu này.

Báo cáo Core Web Vitals của Search Console dùng cùng nguồn CrUX, nhóm các URL tương tự, chỉ gồm URL đã lập chỉ mục và chỉ là mẫu. Trợ giúp của báo cáo nói có thể tách theo quốc gia bằng BigQuery.

CrUX cho biết có vấn đề nhưng không cho biết nguyên nhân. Web.dev (cập nhật 7/6/2024) khuyên dùng thư viện web-vitals, bản attribution, để ghi phần tử được bấm và thời lượng của 3 phần, cộng dữ liệu từ API Long Animation Frames.

API đó chỉ ra script và hàm gây khung hình chậm, nhưng bảng tương thích trên trang Chrome (cập nhật 14/10/2024) ghi chỉ Chrome và Edge từ phiên bản 123, Firefox và Safari chưa hỗ trợ.

Phòng thí nghiệm

Bảng Performance của Chrome DevTools mở ra ở màn hình số liệu trực tiếp: khi tương tác, bảng ghi INP cục bộ cùng 3 phần của từng tương tác, đặt được cạnh số CrUX (tài liệu cập nhật 17/9/2024).

Để tìm nguyên nhân, web.dev (cập nhật 17/10/2024) hướng dẫn ghi bản ghi hiệu năng, thực hiện tương tác rồi xem dòng Interactions, với giới hạn CPU hoặc điện thoại Android tầm trung vì máy phát triển thường nhanh hơn máy khách.

Tiện ích Web Vitals của Chrome đã hết được hỗ trợ từ Chrome 132 (bản ổn định ngày 7/1/2025); kho mã của nó khuyên chuyển sang bảng Performance.

Lighthouse ở chế độ tải trang không đo INP. Web.dev (cập nhật 31/10/2024) giải thích công cụ chạy trong môi trường mô phỏng không có người dùng thì không đo được INP, và nêu Total Blocking Time (TBT) là đại diện gần đúng đo được trong phòng thí nghiệm.

Tài liệu Chrome năm 2022 nói chế độ timespan của Lighthouse đo được INP khi có thao tác; Click Star chưa xác nhận với phiên bản hiện hành.

Bằng chứng: bao nhiêu website đạt INP

Web Almanac 2025 của HTTP Archive (chương Performance, đăng 15/1/2026) dùng dữ liệu CrUX chủ yếu từ tháng 7/2025. Theo chương này, 97% website đạt INP tốt trên máy tính và 77% trên di động (tỷ lệ website, không phải lượt truy cập); di động tăng từ 74% của năm 2024.

Ở cấp trang (cũng từ CrUX), trang chủ trên di động đạt 80% còn trang con chỉ 69%. Có chi tiết trái chiều: TBT trung vị trên di động tăng từ 1.209 lên 1.916 mili giây (đo mô phỏng) trong khi INP thực địa cải thiện. Almanac nêu vài lý do có thể và coi đó là giả thuyết.

Vì sao tương tác chậm: các nguyên nhân hay gặp

Nguyên nhân chung là luồng chính của trình duyệt chỉ làm 1 việc cùng lúc. Theo web.dev (cập nhật 19/12/2024), tác vụ chạy quá 50 mili giây là tác vụ dài, và trong lúc đó trình duyệt không xử lý được thao tác của người dùng.

Script tải khi trang đang mở. Web.dev (cập nhật 9/5/2023) giải thích mỗi script phải được phân tích và biên dịch trước khi chạy, tạo tác vụ dài khi người dùng đã thấy trang. Gói script lớn tạo ra 1 tác vụ lớn; bài gợi ý chia nhỏ, khoảng 100 kilobyte mỗi script.

Bộ đếm thời gian và script bên thứ ba. Web.dev nêu các bộ đếm lặp như setInterval có thể chen ngang tương tác. Script bên thứ ba (nút mạng xã hội, quảng cáo, đo lường, thử nghiệm A/B) thường tự đăng ký hàm xử lý và bộ đếm mà chủ website khó kiểm soát.

Hydration của framework. Chrome (nhóm Aurora, cập nhật 12/12/2023) mô tả hydration là bước gắn hàm xử lý vào HTML do máy chủ dựng; bước này có thể nặng và trang trông đã dùng được khi chưa dùng được. Nhóm này nêu startTransition và Suspense của React cho phép chia hydration thành các lát có thể bị ngắt.

DOM lớn và công việc dựng giao diện. Khi tương tác thay đổi DOM lớn, việc tính bố cục và vẽ lại tốn thời gian. Bài web.dev năm 2023 nêu ngưỡng cũ của Lighthouse: cảnh báo trên 800 nút, quá lớn trên 1.400 nút. Từ Lighthouse 13 (10/2025) mục Optimize DOM size thay ngưỡng đó, chỉ báo lỗi khi tính lại kiểu hoặc bố cục lớn kéo dài trên 40 mili giây.

Cách sửa theo từng phần của tương tác

Nguyên tắc của web.dev: làm ít việc nhất trong hàm xử lý, chia phần còn lại thành tác vụ nhỏ, và chỉ sửa sau khi tái hiện được tương tác chậm.

Giảm độ trễ nhập

Rà các bộ đếm lặp, kể cả của script bên thứ ba, và chia tác vụ dài. Với ô tìm kiếm tự gợi ý gọi mạng theo từng phím, web.dev gợi ý debounce và dùng AbortController để hủy yêu cầu cũ.

Giảm thời gian xử lý

Trong hàm xử lý chỉ làm phần cần để vẽ cập nhật kế tiếp, phần còn lại hoãn lại. Web.dev (cập nhật 2/9/2025) lấy ví dụ trình soạn thảo: cập nhật ô nhập ngay, còn đếm từ, kiểm chính tả và lưu bản nháp để sau khung hình kế tiếp.

Có 2 cách chia tác vụ. setTimeout chạy phần còn lại ở tác vụ mới nhưng xếp cuối hàng đợi; sau 5 lần lồng nhau, trình duyệt áp mức chờ tối thiểu 5 mili giây cho mỗi lần.

scheduler.yield() chạy phần còn lại với ưu tiên cao hơn. Bảng tương thích trên web.dev (đọc 23/10/2026) ghi Safari chưa hỗ trợ, nên cần dự phòng bằng setTimeout.

Giảm độ trễ hiển thị

Giữ DOM nhỏ và đơn giản. Dùng content-visibility trong CSS để trình duyệt hoãn dựng phần nằm ngoài màn hình. Tránh đọc kích thước ngay sau khi ghi kiểu trong cùng tác vụ.

Script bên thứ ba

Web.dev (cập nhật 19/2/2024) hướng dẫn tìm script tốn kém bằng DevTools (nhóm theo sản phẩm trong tab Bottom-up) và chặn yêu cầu mạng để thử bỏ từng script. Sau đó quyết định có thật sự cần script đó không.

Với website dùng Next.js, tài liệu next/script (đọc 23/10/2026) có 4 chiến lược nạp, trong đó lazyOnload được nêu là hợp với widget chat và mạng xã hội.

Điều này nghĩa là gì với doanh nghiệp Việt Nam

Google cho biết (trang page experience, cập nhật 22/9/2026) hệ thống xếp hạng cốt lõi dùng Core Web Vitals nhưng không có tín hiệu trải nghiệm trang đơn lẻ nào. Điểm tốt không bảo đảm xếp hạng cao.

Đánh giá của Click Star. INP khó vì không có 1 nút sửa chung. Mỗi website chậm ở 1 phần khác nhau, nên việc đầu tiên là xác định phần nào chứ không phải áp một danh sách tối ưu.

Suy luận của Click Star, không phải số đo trên website Việt Nam: các điểm nghi ngờ trước tiên là widget chat, thẻ nạp qua Tag Manager, popup, ô tìm kiếm tự gợi ý và bộ lọc. Mỗi script bên thứ ba cần chủ sở hữu rõ ràng: ai thêm, vì mục đích gì, ai gỡ.

Lộ trình 4 tuần (khung tham khảo của Click Star)

Khung này do Click Star đề xuất, không lấy từ nguồn ngoài; chỉ ngưỡng 200 mili giây và chu kỳ 28 ngày là từ nguồn đã nêu.

• Tuần 1, đo hiện trạng: chạy PageSpeed Insights cho 5 trang quan trọng, tách di động và máy tính, ghi INP ở phân vị 75. Liệt kê 5 tương tác then chốt (mở menu, mở chat, gửi biểu mẫu, lọc, đặt lịch).
• Tuần 2, tái hiện: trong bảng Performance, bật giới hạn CPU, thực hiện từng tương tác và ghi 3 phần của nó, rồi đánh dấu phần chậm nhất.
• Tuần 3, sửa từng thay đổi một: hoãn hoặc gỡ script bên thứ ba không cần, chia tác vụ dài, giảm DOM; đo lại sau mỗi thay đổi.
• Tuần 4, phát hành và theo dõi: xem PageSpeed Insights và Search Console. Chỉ kết luận sau khi đủ 28 ngày, so với hiện trạng tuần 1 và ngưỡng 200 mili giây.

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

1. Dùng điểm Lighthouse hoặc TBT làm mục tiêu thay cho INP thực địa ở phân vị 75.
2. Chỉ thử trên máy tính nhanh của đội làm web, không giới hạn CPU.
3. Chỉ thử tương tác sau khi trang tải xong, bỏ qua lúc đang tải khi luồng chính bận nhất.
4. Thêm widget chat, thẻ đo lường, popup mà không đo ảnh hưởng.
5. Dùng setTimeout hay scheduler.yield() nhưng để nguyên việc nặng trong hàm xử lý, hoặc nhường luồng ở mọi chỗ.
6. Kết luận ngay sau khi phát hành, trong khi dữ liệu CrUX cần 28 ngày để phản ánh đủ.

Điều chưa biết

Click Star chưa tìm thấy tỷ lệ đạt INP riêng cho Việt Nam, cũng chưa thấy nguồn nào đo mức tăng chuyển đổi hay doanh thu khi cải thiện INP. Google không nêu bằng số ảnh hưởng của INP lên thứ hạng.

Lý do TBT tăng trong khi INP cải thiện ở Web Almanac mới là giả thuyết. Chế độ timespan của Lighthouse chỉ được đọc qua tài liệu năm 2022.