INP Là Gì? Cách Đo Và Tối Ưu Interaction to Next Paint

INP là gì?

INP, viết tắt của Interaction to Next Paint, là chỉ số Core Web Vitals đo thời gian từ lúc người dùng nhấp, chạm hoặc nhấn phím đến khi trình duyệt hiển thị phản hồi trực quan tiếp theo. INP quan sát các tương tác trong suốt lượt truy cập, không chỉ lần đầu. Mốc tốt là không quá 200 mili giây ở phân vị thứ 75.^[1]

Bạn bấm mở menu nhưng màn hình vẫn im lặng. Bạn nhấp nút gửi form thêm lần nữa vì không biết lần đầu đã được ghi nhận chưa. Hoặc chữ xuất hiện chậm hơn nhịp gõ. Trang có thể tải nội dung nhanh nhưng những khoảnh khắc đó vẫn khiến người dùng cảm thấy website bị đơ. Đó chính là trải nghiệm mà INP muốn phản ánh.

Trước khi đi vào chi tiết, nếu bạn chưa nắm phần nền, xem thêm technical SEO là gì.

INP bao nhiêu là tốt?

Google đánh giá INP ở phân vị thứ 75 của lượt tải trang, tách mobile và desktop. Có thể hiểu đơn giản rằng ít nhất 75% lượt xem cần đạt ngưỡng tương ứng. Không dùng điểm trung bình toàn site để kết luận vì nó có thể che khuất nhóm người dùng đang gặp phản hồi chậm.

Một URL có INP 180 ms không có nghĩa mọi tương tác đều đúng 180 ms. Giá trị trang đại diện cho tương tác dài nhất hoặc gần dài nhất trong từng lượt truy cập, sau đó được tổng hợp ở P75. Với trang có nhiều tương tác, phép tính sẽ loại bớt điểm ngoại lai. Cứ mỗi 50 tương tác, một tương tác dài nhất được bỏ qua.^[1]

INP đo điều gì trong một tương tác?

Một interaction có thể gồm nhiều event cùng thuộc một cử chỉ. Ví dụ, một lần chạm có thể tạo ra pointerdown, pointerup và click. INP không cộng mọi event một cách máy móc. Nó ghi nhận khoảng thời gian dài nhất của nhóm event điều khiển tương tác, từ lúc người dùng bắt đầu thao tác đến khi trình duyệt có thể vẽ khung hình tiếp theo.

Input delay: thao tác đã xảy ra nhưng callback chưa chạy

Input delay bắt đầu khi người dùng thao tác và kết thúc lúc event callback đầu tiên được thực thi. Main thread có thể đang bận parse JavaScript, chạy hydration, thực hiện analytics hoặc xử lý một long task khác. Đây là lý do menu đôi khi không mở khi người dùng nhấp trong những giây đầu, dù nội dung đã xuất hiện trên màn hình.

Processing duration: callback đang làm quá nhiều việc

Processing duration là thời gian chạy các callback của interaction. Một nút gửi form có thể vừa validate toàn bộ dữ liệu, vừa cập nhật state cấp cao, vừa gửi tracking, rồi render lại component cha. Người dùng chỉ cần thấy nút đổi trạng thái ngay, nhưng luồng chính lại phải hoàn thành cả một chuỗi công việc trước khi giao diện có cơ hội phản hồi.

Presentation delay: code đã chạy xong nhưng chưa vẽ được

Sau callback, trình duyệt còn phải tính style, layout, paint và composite. DOM lớn, layout thrashing, bảng hàng nghìn dòng hoặc thay đổi state làm nhiều nhánh render lại đều có thể kéo dài giai đoạn này. Vì vậy, giảm thời gian xử lý JavaScript chưa chắc đủ nếu phần render vẫn quá nặng.

Ví dụ minh họa: một cú nhấp có input delay 70 ms, processing 210 ms và presentation delay 90 ms. Tổng độ trễ là 370 ms, thuộc vùng cần cải thiện. Đây là phép tính minh họa cách đọc trace, không phải dữ liệu đo của manhdigital.com.

INP không đo những gì?

• Không đo cuộn, hover và zoom: INP tập trung vào nhấp chuột, chạm màn hình và bàn phím.
• Không chờ toàn bộ network request: nếu giao diện phản hồi trước rồi API chạy bất đồng bộ, request đó thường không kéo dài INP.
• Không đo thời gian tải nội dung chính: đó là vai trò gần hơn với LCP.
• Không phải điểm tốc độ tổng hợp: một trang có LCP tốt vẫn có thể có INP kém.
• Không phải thời gian xử lý trung bình: phép đo hướng đến tương tác chậm nhất hoặc gần chậm nhất trong lượt truy cập.

Nếu một trang không có giá trị INP, chưa thể kết luận trang đạt chuẩn. Người dùng có thể chưa thực hiện thao tác được đo, URL có quá ít dữ liệu hoặc lượt truy cập đến từ bot. Đó là lý do PageSpeed Insights đôi khi chỉ hiển thị dữ liệu cấp origin, hoặc không có Field Data cho URL cụ thể.

INP khác FID và TBT như thế nào?

INP chính thức thay FID trong Core Web Vitals từ ngày 12/03/2024. Khác biệt quan trọng nhất là phạm vi. FID chỉ xem input delay ở lần tương tác đầu. INP nhìn cả input delay, processing, presentation delay và quan sát gần như toàn bộ hành trình.^[2]

TBT có ích khi chạy Lighthouse vì nó chỉ ra main thread đang bị chiếm dụng trong lúc tải. Tuy nhiên, Lighthouse tải trang một lần mà không thực hiện đầy đủ hành trình người dùng thì không thể tự sinh ra một INP đại diện. Hãy dùng TBT để phát hiện nguy cơ rồi tái hiện đúng interaction trong Chrome DevTools.

Đọc được số INP ở field data là một chuyện, truy ngược ra đoạn script nào chặn main thread lại cần dựng profile trên trình duyệt thật. Phần truy vết đó thuộc dịch vụ SEO audit.

Cách đo INP đúng theo 4 lớp dữ liệu

1. Search Console: xác định nhóm URL có vấn đề

Báo cáo Core Web Vitals trong Google Search Console dùng dữ liệu CrUX để nhóm các URL có trải nghiệm tương tự. Nó phù hợp để trả lời “template nào đang bị ảnh hưởng?” nhưng không chỉ ra nút bấm hoặc event handler nào gây chậm. Khi nhiều URL blog cùng có INP kém, hãy kiểm tra component dùng chung như header, mục lục tự động, form, popup và script bên thứ ba trước.

2. PageSpeed Insights: phân biệt URL và origin

Nhập URL canonical cụ thể rồi đọc phần dữ liệu người dùng thật. Hãy xem báo cáo đang hiển thị dữ liệu của chính URL hay dữ liệu cấp origin. Nếu URL chưa đủ mẫu, kết quả origin chỉ cho biết bức tranh chung của tên miền. Nó không chứng minh riêng trang đang kiểm tra đạt hay không đạt.

Bài hướng dẫn đọc PageSpeed Insights giải thích kỹ cách tách Field Data, Lab Data và các cảnh báo chẩn đoán. Với INP, luôn ghi lại thiết bị, phạm vi dữ liệu và ngày kiểm tra để tránh so hai phép đo không cùng điều kiện.

3. RUM: tìm đúng phần tử và hành trình chậm

CrUX cho biết mức độ. Real User Monitoring cho biết ngữ cảnh. Một record thực tế có thể gồm giá trị INP, rating, path đã làm sạch, loại template, loại interaction và selector ổn định của phần tử. Không gửi nội dung người dùng nhập, email, số điện thoại, token hoặc query nhạy cảm vào hệ thống analytics.

Thư viện web-vitals của Google cung cấp cách triển khai tham chiếu để thu thập INP. Dữ liệu nên được phân tích theo P75, template, thiết bị và interaction target. Một con số trung bình toàn site hiếm khi đủ để developer tái hiện lỗi.^[3]

4. Chrome DevTools: tái hiện và tách ba pha

Mở Performance panel, quan sát Live metrics rồi thực hiện hành trình giống người dùng thật. Nếu một interaction chậm xuất hiện, hãy lặp lại thao tác và ghi trace. Trong bản ghi, xem interaction track, long task, call tree, forced layout và thời gian render. DevTools giúp trả lời “vì sao chậm”, còn Field Data giúp trả lời “vấn đề có xảy ra với người dùng thật hay không”.^[4]

Quy trình audit INP từ dữ liệu đến ticket kỹ thuật

1. Chọn luồng kinh doanh: menu mobile, tìm kiếm, bộ lọc, thêm giỏ hàng, gửi form hoặc CTA nhận tư vấn.
2. Khoanh vùng URL: dùng nhóm URL trong Search Console, template trong RUM và dữ liệu thiết bị.
3. Tái hiện đúng thời điểm: thử cả khi trang đang tải và sau khi trang ổn định.
4. Ghi trace: lưu interaction, input delay, processing, presentation delay và long task liên quan.
5. Đặt giả thuyết: bundle lớn, handler nặng, re-render lan rộng, DOM lớn hoặc script bên thứ ba.
6. Sửa một nhóm nguyên nhân: tránh thay nhiều biến cùng lúc khiến kết quả khó quy về một thay đổi.
7. Kiểm thử hồi quy: xác nhận bàn phím, trình đọc màn hình, validation, analytics và conversion vẫn hoạt động.
8. Đo lại: so trace trước sau và tiếp tục theo dõi P75 trong Field Data.

Đừng giao ticket “tối ưu INP toàn website”. Một ticket có thể nghiệm thu cần URL hoặc template, thiết bị, phần tử tương tác, trace, pha gây chậm, bản sửa dự kiến và tiêu chí hoàn thành. Đây cũng là cách biến một báo cáo Core Web Vitals thành backlog kỹ thuật thay vì danh sách cảnh báo chung chung.

Hạ INP xuống dưới 200ms giúp trải nghiệm mượt hơn, nhưng nó chỉ là một chỉ số trong nhóm Core Web Vitals. Đặt nó cạnh content và liên kết trong một kế hoạch SEO tổng thể sẽ hợp lý hơn.

Cách tối ưu INP theo đúng nguyên nhân

Giảm JavaScript chạy trên main thread

Minify chỉ làm file nhỏ hơn, không bảo đảm thời gian thực thi ngắn. Hãy đo code nào chạy ở đúng thời điểm người dùng thao tác. Xóa code không dùng, code-split theo route hoặc tính năng, trì hoãn chat và heatmap chưa cần, đồng thời xem lại những thư viện chỉ được dùng cho một hiệu ứng nhỏ.

Khi công việc đồng bộ dài, hãy chia nó thành các phần để main thread có cơ hội nhận input. Tuy nhiên, chia task không có nghĩa dùng hàng loạt timeout vô nghĩa. Giao diện cần được cập nhật trước, phần không khẩn cấp mới được nhường sang task tiếp theo. Tính toán CPU nặng và không cần DOM có thể chuyển sang Web Worker.^[5]

Làm event handler gọn và có phản hồi sớm

Nút gửi form nên đổi sang trạng thái “Đang gửi” và ngăn double submit trong khung hình sớm. Việc ghi analytics, đồng bộ cache hoặc hiển thị nội dung phụ có thể chạy sau. Với ô tìm kiếm, đừng render lại toàn bộ cây component sau từng phím nếu chỉ danh sách kết quả cần đổi.

Cũng cần kiểm tra nhiều event cùng thuộc một interaction. Tách một phần logic khỏi click không giúp ích nếu pointerup hoặc handler từ thư viện khác vẫn chặn main thread. Trace cần bao quát cả nhóm event, không chỉ hàm do đội phát triển tự viết.

Giảm chi phí render và kích thước DOM

DOM lớn khiến style calculation và layout tốn thời gian hơn. Hãy bỏ wrapper không cần thiết, phân trang hoặc virtualize danh sách dài và tránh đo kích thước ngay sau khi vừa thay đổi style. Với component hiện đại, kiểm tra re-render từ state đặt quá cao trước khi thêm memoization tràn lan.

content-visibility có thể giảm công việc render ngoài viewport trong một số trường hợp. Nhưng cần kiểm tra anchor navigation, kích thước dự phòng và accessibility. Một thủ thuật CSS chỉ được coi là thành công khi interaction nhanh hơn mà hành vi trang vẫn đúng.

Kiểm soát script bên thứ ba

Tag manager, chat, A/B testing, heatmap và quảng cáo đều có thể tạo long task. Đừng xóa chúng theo cảm tính. Trước hết, liệt kê owner và mục tiêu kinh doanh của từng script. Sau đó kiểm tra script nào thực sự cần trên mọi trang, script nào có thể tải sau tương tác đầu hoặc sau khi người dùng đồng ý.

Nếu cùng một widget làm chậm hàng trăm URL, sửa ở component chung có giá trị hơn tối ưu từng bài. Với website đang chậm nói chung, hãy kết hợp quy trình này cùng bài website chậm: nguyên nhân và cách sửa.

Mỗi site nghẽn tương tác ở một chỗ khác nhau: chỗ do theme, chỗ do tag manager chất chồng. Mô tả nền tảng đang dùng trong brief SEO miễn phí, chúng tôi khoanh vùng nguyên nhân trước.

Nên ưu tiên lỗi INP theo P0, P1, P2 thế nào?

Đừng chỉ ưu tiên theo con số mili giây. Một CTA tạo lead có INP 280 ms có thể đáng sửa trước accordion bài blog ở 420 ms. Hãy kết hợp độ trễ, số người bị ảnh hưởng, tần suất tương tác và giá trị kinh doanh. Nếu cần audit nhiều template, dịch vụ SEO Audit nên trả về backlog có owner và mức ưu tiên như trên.

Ví dụ: audit một nút gửi form phản hồi chậm

Giả sử RUM cho thấy nút gửi form trên mobile thường là interaction target chậm. Đây chưa phải bằng chứng rằng API chậm. Bạn tái hiện bằng DevTools và thấy event callback đang validate toàn bộ form, cập nhật state của component cha và khởi tạo một lệnh tracking đồng bộ trước khi nút đổi trạng thái.

1. Cho nút đổi ngay sang trạng thái đang xử lý và ngăn nhấp lặp.
2. Chỉ validate những trường cần thiết ở bước gửi.
3. Thu hẹp state update để không render lại cả vùng nội dung lớn.
4. Đưa tracking không khẩn cấp sang sau khung hình phản hồi.
5. So lại interaction trace, lỗi JavaScript và conversion trước sau.

Nếu trace ngắn hơn nhưng tỷ lệ gửi form giảm, bản sửa chưa đạt. INP là chỉ số trải nghiệm, không phải lý do để hy sinh chức năng. Tiêu chí tốt luôn gồm hiệu suất, tính đúng đắn, accessibility và kết quả kinh doanh.

INP ảnh hưởng SEO như thế nào?

Google khuyến nghị website đạt Core Web Vitals tốt để thành công trên Search và mang lại trải nghiệm tốt. Tuy nhiên, không có một tín hiệu “page experience” duy nhất. Nội dung phù hợp vẫn có thể xếp hạng khi một số khía cạnh trải nghiệm chưa hoàn hảo. Do đó, INP không phải nút bấm giúp một trang tự động tăng hạng, cũng không bù được nội dung sai intent.^[6]

Cách dùng INP hợp lý là bảo vệ luồng người dùng sau khi họ đã đến trang. Phản hồi nhanh giúp hạn chế nhấp lặp, bỏ form và cảm giác website hỏng. Với SEO Technical, hãy theo dõi Core Web Vitals theo template, sau đó đối chiếu conversion thay vì đặt mục tiêu “mọi URL phải 100 điểm”. Bài tốc độ website ảnh hưởng SEO giúp đặt INP vào bối cảnh ranking, crawl và conversion. Xem thêm bài SEO Technical là gì để đặt chỉ số này đúng vị trí trong toàn bộ hệ thống.

Đọc thêm: redirect 301 vs 302 · kiểm tra mobile friendly

INP có phải tín hiệu GEO hoặc AI Overviews không?

Không có ngưỡng INP riêng để được AI Overviews hoặc AI Mode trích dẫn. Google cho biết các tính năng AI vẫn dựa trên hệ thống Search cốt lõi. URL phải được index và đủ điều kiện hiển thị snippet. Không có yêu cầu kỹ thuật hay schema đặc biệt chỉ dành cho AI Search.^[7]

INP vẫn có giá trị gián tiếp vì trải nghiệm trang tốt là một nền SEO vững. Nội dung quan trọng nên có dạng văn bản trong initial HTML, crawling được, có internal link và structured data khớp với nội dung hiển thị. JavaScript dùng cho tương tác cần được tối ưu, nhưng SSR hoặc prerender không tự động chữa INP nếu bundle sau đó vẫn chạy tác vụ dài.

Muốn tăng khả năng được trích dẫn, phần nội dung cần rõ, có nguồn gốc, trả lời trực tiếp và bổ sung góc nhìn không phải bản tóm tắt đại trà. Visual ba pha, bảng chẩn đoán và quy trình tạo ticket trong bài này phục vụ chính mục tiêu đó. Bạn có thể đọc thêm GEO là gì để phân biệt khả năng index, khả năng được truy xuất và khả năng được chọn làm nguồn.

7 sai lầm khi tối ưu INP

1. Chỉ nhìn điểm Lighthouse: một lần tải lab không đại diện cho toàn bộ interaction của người dùng thật.
2. Coi dữ liệu origin là dữ liệu URL: origin có thể trộn nhiều template với hành vi rất khác nhau.
3. Chỉ sửa input delay: processing và presentation delay cũng nằm trong INP.
4. Xóa JavaScript theo cảm tính: dễ làm hỏng form, analytics hoặc chức năng có giá trị.
5. Dùng desktop để đại diện mobile: CPU, input và điều kiện mạng khác nhau.
6. Đo trung bình: Core Web Vitals cần đọc P75 và phân đoạn hợp lý.
7. Không kiểm thử hồi quy: trace đẹp hơn nhưng double submit, focus hoặc conversion xấu đi vẫn là thất bại.

Checklist nghiệm thu tối ưu INP

• Đã xác định URL, template, thiết bị và interaction target.
• Đã phân biệt dữ liệu URL với origin và Field Data với Lab Data.
• Đã lưu trace trước khi sửa và chỉ ra pha gây chậm.
• Phản hồi trực quan xuất hiện sớm, không chờ network hoàn tất.
• Long task, callback hoặc render mục tiêu đã giảm.
• Không phát sinh layout shift, double submit hoặc state race.
• Luồng bàn phím, focus và trình đọc màn hình vẫn hoạt động.
• Analytics, error rate và conversion không xấu đi.
• Đã triển khai RUM hoặc kế hoạch theo dõi Field Data P75.
• Đã kiểm tra lại sau khi có đủ dữ liệu người dùng mới.

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

INP bao nhiêu là tốt?

INP không quá 200 mili giây được xem là tố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. Hãy đánh giá ở phân vị thứ 75 của lượt tải trang và tách riêng mobile với desktop.

Tại sao PageSpeed Insights không có INP của URL?

URL có thể chưa đủ dữ liệu người dùng trong Chrome UX Report, chưa có tương tác đo được hoặc lượng truy cập còn thấp. PageSpeed Insights có thể chuyển sang dữ liệu cấp origin. Khi đó, không nên tự suy ra riêng URL đã đạt mà cần bổ sung RUM và lab test.

Lighthouse có đo INP không?

Một lần chạy Lighthouse mặc định chủ yếu quan sát quá trình tải và không tái tạo toàn bộ hành trình tương tác. TBT có thể đóng vai trò proxy để tìm nguy cơ main thread bị chặn. Muốn đo interaction trong lab, bạn cần thực hiện thao tác và phân tích bằng DevTools hoặc user flow phù hợp.

INP có tính thời gian gọi API không?

INP không chờ toàn bộ tác vụ bất đồng bộ như API hoàn tất nếu trình duyệt có thể vẽ phản hồi trước. Vì vậy, nút nên đổi trạng thái ngay sau khi nhấp. Nếu code đồng bộ hoặc render chặn khung hình trước request, phần đó vẫn làm INP tăng.

SSR có tự động làm INP tốt hơn không?

Không. SSR hoặc prerender giúp nội dung ban đầu sẵn trong HTML, nhưng JavaScript hydration, event handler và render phía client vẫn có thể làm interaction chậm. Cần đo main thread và hành vi sau khi trang tải. Đọc thêm quy trình audit mobile và desktop để kiểm tra parity cùng initial HTML.

Thay theme hoặc plugin có chắc sửa được INP không?

Không chắc. Theme hoặc plugin chỉ là nghi phạm cho đến khi trace cho thấy code của nó chiếm input delay, processing hoặc presentation delay. Hãy đo trước, tắt thử trong staging, so trace và kiểm tra lại chức năng trước khi thay đổi trên website thật.

Kết luận

Muốn tối ưu INP, đừng bắt đầu bằng việc xóa ngẫu nhiên script hoặc chạy lại Lighthouse cho đến khi được điểm xanh. Hãy bắt đầu từ dữ liệu người dùng, tìm interaction cụ thể, tách ba pha độ trễ rồi sửa đúng nguyên nhân. Một bản sửa tốt phải giúp thao tác thật phản hồi nhanh hơn, không làm hỏng chức năng và được xác nhận lại bằng Field Data.

Nếu website có nhiều template và chưa biết lỗi nằm ở đâu, bước tiếp theo hợp lý là lập danh sách các luồng tạo giá trị, đo từng interaction target và chuyển kết quả thành backlog P0, P1, P2. Tốc độ chỉ đáng tối ưu khi nó làm trải nghiệm và kết quả kinh doanh tốt lên.

Nguồn tham khảo

1. web.dev: Lượt tương tác đến nội dung hiển thị tiếp theo (INP), cập nhật ngày 02/09/2025.
2. web.dev: INP chính thức trở thành Core Web Vital, ngày 12/03/2024.
3. GoogleChrome: thư viện web-vitals.
4. Chrome for Developers: phân tích hiệu suất bằng Performance panel.
5. web.dev: Cách tối ưu hóa INP, cập nhật ngày 02/09/2025.
6. Google Search Central: Core Web Vitals và kết quả tìm kiếm.
7. Google Search Central: tối ưu website cho các tính năng AI tạo sinh.