INP là gì? 5 Cách tối ưu INP tốt nhất cho SEO và Cách đo lường chỉ số Interaction to Next Paint

Viết bởi: Nguyễn Thanh Trường

Cập nhật lần gần đây nhất: 14:29 - 31/10/2025

Cập nhật tin tức SEO hàng ngày:

Interaction to Next Paint hay INP là một chỉ số mới trong bộ 3 chỉ số Core Web Vitals, đã chính thức thay thế First Input Delay (FID) làm chỉ số Core Web Vital về khả năng phản hồi từ ngày 12 tháng 3 năm 2024.

INP “đo thời gian từ khi người dùng tương tác với trang (click, chạm, nhấn phím) cho đến khi họ nhìn thấy phản hồi trên màn hình.” Nó đánh giá khả năng phản hồi tổng thể của một trang đối với các tương tác của người dùng.

Vậy Google tính điểm số INP như thế nào? Tại sao website của bạn gặp các vấn đề về INP? Và làm thế nào để tối ưu INP tốt nhất cho Website? Tất cả sẽ được tôi, Nguyễn Thanh Trường – Founder & CEO của SEO Center chia sẻ chi tiết trong bài viết dưới đây.

Mục tiêu của bài viết này là giúp bạn hiểu rõ các kiến thức từ căn bản đến nâng cao về Interaction to Next Paint, từ đó giúp bạn có thể tự tối ưu điểm số INP cho website của mình được tốt nhất.

Nội dung chính của bài viết:

INP (Interaction to Next Paint) là chỉ số Core Web Vital mới nhất, đo lường toàn bộ khả năng phản hồi của website từ khi người dùng tương tác đến khi nhận được phản hồi trực quan trên màn hình, thay thế FID để mang lại cái nhìn chính xác hơn về trải nghiệm người dùng.

Điểm INP tốt cần dưới 200ms, trong khi điểm kém là trên 500ms, và chỉ số này chịu ảnh hưởng lớn từ các tác vụ JavaScript dài chặn luồng chính, thay đổi DOM phức tạp và các script bên thứ ba.

Để tối ưu hóa INP, cần ưu tiên cung cấp phản hồi trực quan tức thì cho người dùng và tối ưu JavaScript bằng cách minify, nén, trì hoãn (defer) script không quan trọng hoặc sử dụng Web Workers cho các tác vụ nặng.

Việc phân chia các tác vụ JavaScript dài thành các phần nhỏ hơn và tối ưu quá trình hiển thị (rendering) bằng cách tránh “layout thrashing” cùng giảm độ phức tạp của DOM sẽ giúp trình duyệt phản hồi nhanh hơn.

Cải thiện INP không chỉ nâng cao trải nghiệm người dùng, giảm tỷ lệ thoát và tăng tương tác, mà còn có lợi cho thứ hạng SEO, với các công cụ như Google Search Console, PageSpeed Insights và Chrome DevTools hỗ trợ đo lường và chẩn đoán hiệu quả.

Nội dung bài học

INP là gì?

INP hay Interaction to Next Paint lả chỉ số đo lường thời gian từ khi người dùng tương tác với trang (ví dụ: bấm chuột, chạm vào màn hình, hoặc nhấn phím) cho đến khi họ nhìn thấy một phản hồi trực quan trên màn hình. Phản hồi trực quan này thường là một nút đổi màu, một menu bật ra, hay văn bản bạn vừa gõ xuất hiện trong ô tìm kiếm.

Chỉ số INP được ghi nhận khi xem ở chế độ dev tool

Ví dụ: Bạn đang mua sắm online.

Bạn bấm vào nút “Thêm vào giỏ hàng”. Nếu nút đó ngay lập tức chuyển sang màu xanh lá và hiển thị “Đã thêm vào giỏ”, thì phản hồi rất nhanh. Đó là điều mà INP mong muốn.
Nhưng nếu bạn bấm xong, màn hình vẫn “đứng hình” một lúc, không có gì xảy ra, và bạn bắt đầu bấm lại lần nữa vì nghĩ rằng chưa được, thì đó là một trải nghiệm tệ, và INP sẽ ghi nhận điểm số cao (kém). Tình trạng này còn được gọi là “rage click” (nhấp điên cuồng), là một dấu hiệu của sự thất vọng ở người dùng.

Về bản chất, INP được coi là một chỉ số đo sự ổn định trong Core Web Vitals.

Sự ra đời và vai trò của INP trong Core Web Vitals

Interaction to Next Paint là một chỉ số mới, được Google chính thức đưa vào bộ Core Web Vitals từ tháng 3 năm 2024, và nó đã thay thế First Input Delay (FID). Google Search Console cũng đã cập nhật để hiển thị báo cáo INP thay cho FID.

Chỉ số FID trước đây chỉ đo lường độ trễ đầu vào của lần tương tác đầu tiên mà người dùng thực hiện trên trang. Tức là, nó chỉ quan tâm đến việc trang phản ứng nhanh hay chậm ở lần đầu tiên bạn chạm/nhấp vào nó.

Nhưng Google nhận thấy rằng, người dùng dành tới 90% thời gian trên một trang web sau khi trang đó đã tải xong. Điều này có nghĩa là, nếu chỉ đo lần tương tác đầu tiên thì không đủ để đánh giá toàn bộ trải nghiệm.

Và INP ra đời nhằm khắc phục hạn chế này bằng cách quan sát và đo lường khả năng phản hồi của tất cả các tương tác (nhấp chuột, chạm, nhấn phím) trong suốt toàn bộ vòng đời của trang, từ lúc bạn truy cập cho đến khi bạn rời đi.

Bên cạnh đó, chỉ số FID rất “dễ dãi” vì gần như 99.9% website trên máy tính và 95% trên di động có điểm FID tốt, khiến nó không thực sự phản ánh vấn đề trải nghiệm người dùng. INP ra đời để cung cấp một cái nhìn sắc thái và toàn diện hơn về khả năng phản hồi thực tế của trang.

INP là một chỉ số quan trọng mới và là chỉ số ổn định trong Core Web Vitals, tập trung vào khả năng phản hồi tổng thể của website. Nó giúp nhà phát triển có một bức tranh hoàn chỉnh hơn về hiệu suất trang và khuyến khích họ thực hiện những cải tiến thực sự nâng cao trải nghiệm người dùng.

Ví dụ về sự khác biệt giữa FID và INP: Hãy tưởng tượng bạn đang dùng một ứng dụng di động để đặt món ăn online:

FID: Bạn mở ứng dụng lên, và ngay lập tức chạm vào nút “Tìm kiếm” lần đầu tiên. FID chỉ đo thời gian từ lúc bạn chạm đến khi trình duyệt bắt đầu xử lý yêu cầu tìm kiếm đó. Nếu nó phản ứng ngay, FID tốt.
INP: Sau đó, bạn gõ món ăn vào ô tìm kiếm, bấm nút “Lọc” để chọn nhà hàng, lướt qua các món, nhấp vào hình ảnh để xem chi tiết, bấm nút “Thêm vào giỏ hàng”, rồi nhấn “Tiến hành thanh toán”. INP sẽ quan sát và đo lường thời gian phản hồi của TẤT CẢ các tương tác này, không chỉ riêng lần đầu tiên.
- Nếu bạn gõ xong mà chữ mãi không hiện, hay bấm “Thêm vào giỏ” mà nút không phản hồi ngay, INP sẽ ghi nhận điểm kém.
- Ngược lại, nếu mọi thao tác đều mượt mà, phản hồi tức thì, INP sẽ rất tốt.

Các loại tương tác được INP quan sát

INP không đo lường mọi loại tương tác. Nó chỉ tập trung vào những hành động yêu cầu website phải “làm gì đó” và hiển thị kết quả một cách rõ ràng. Cụ thể, INP quan sát các loại tương tác sau:

Bất kỳ cú nhấp chuột nào vào một phần tử tương tác (ví dụ: nút, liên kết). Ví dụ: Bạn nhấp vào nút “Gửi” trên một biểu mẫu liên hệ.
Bất kỳ lần chạm nào vào một phần tử tương tác trên thiết bị màn hình cảm ứng (ví dụ: điện thoại, máy tính bảng). Ví dụ: Bạn chạm vào biểu tượng menu “hamburger” trên điện thoại để mở thanh điều hướng.
Nhấn phím trên bàn phím vật lý hoặc bàn phím ảo (ví dụ: gõ chữ vào ô tìm kiếm, nhấn Enter để gửi biểu mẫu). Ví dụ: Bạn gõ tên sản phẩm vào ô tìm kiếm.

Những tương tác không được INP quan sát bao gồm:

Di chuột (hover).
Phóng to (zoom).
Cuộn trang (scroll). Tuy nhiên, nếu trong quá trình cuộn hoặc di chuột mà có hành động nhấp, chạm, hoặc nhấn phím nào đó diễn ra, thì INP vẫn sẽ đo lường phần tương tác đó.

Nguyên nhân gây ra INP cao

Các tác vụ dài chặn luồng hoạt động chính của trình duyệt

Luồng chính hay Main thread là nơi trình duyệt thực hiện hầu hết các công việc quan trọng như xử lý sự kiện người dùng, chạy JavaScript, tính toán bố cục và vẽ trang.

Nếu có một đoạn mã (thường là JavaScript) cần xử lý quá lâu (ví dụ, hơn 50 mili giây), nó sẽ “chiếm” luồng chính, ngăn cản trình duyệt phản hồi kịp thời các tương tác khác của người dùng.

Ví dụ: Bạn vừa gõ chữ vào ô tìm kiếm thì một script nặng về phân tích dữ liệu bất ngờ chạy (có thể do API gọi định kỳ), khiến trình duyệt không kịp vẽ chữ bạn vừa gõ lên màn hình. Lúc này, bạn sẽ thấy ô tìm kiếm bị “đơ”.

Trình xử lý sự kiện đồng bộ trên các sự kiện nhấp

Đây là khi code xử lý sự kiện (ví dụ: khi bấm nút) chạy một cách đồng bộ và thực hiện các tác vụ nặng ngay lập tức, thay vì để trình duyệt có cơ hội cập nhật giao diện người dùng trước.

Ví dụ: Bạn bấm nút “Đăng ký”. Ngay lập tức, một đoạn code rất nặng chạy để kiểm tra tất cả các trường dữ liệu trên form và gửi lên server cùng lúc, khiến nút không kịp đổi trạng thái hay hiển thị “Đang xử lý…” ngay lập tức.

Thay đổi DOM gây ra nhiều lần bố cục lại và vẽ lại

DOM hay Document Object Model là cấu trúc của 1 trang. Khi các phần tử trong DOM bị thay đổi như thêm, xóa, sửa kích thước, vị trí,… thì trình duyệt phải tính toán lại bố cục và sắp xếp lại các phần đó của trang.

Nếu có quá nhiều sự thay đổi DOM hoặc cấu trúc DOM quá lớn (ví dụ: hơn 1.500 phần tử HTML), trình duyệt sẽ phải làm việc rất nhiều để cập nhật lại giao diện, gây ra độ trễ hiển thị.

Ví dụ: Bạn đang xem danh sách sản phẩm. Khi bạn bấm nút “Xem thêm”, trang tải thêm 100 sản phẩm mới và tự động chèn chúng vào DOM. Nếu quá trình này không được tối ưu, trang sẽ bị giật cục hoặc đơ một lúc vì trình duyệt phải tính toán lại vị trí của toàn bộ các phần tử hiển thị.

Kích thước và độ phức tạp của web, cũng như số lượng file JavaScript và CSS được tải

Trang càng lớn, càng phức tạp, và càng có nhiều file JavaScript, CSS thì trình duyệt càng phải tải xuống, phân tích, biên dịch và thực thi nhiều code hơn. Điều này có thể ảnh hưởng đến khả năng phản hồi, đặc biệt trong giai đoạn tải ban đầu hoặc khi có nhiều tương tác.

Cách tính toán giá trị INP cuối cùng

Để đưa ra một giá trị INP đại diện cho toàn bộ trải nghiệm người dùng trên trang, Google sử dụng phương pháp tính toán cụ thể:

INP sẽ quan sát độ trễ của tất cả các tương tác mà người dùng thực hiện trong suốt thời gian họ truy cập trang.
Giá trị INP cuối cùng được chọn là tương tác có độ trễ tệ nhất trong số các tương tác quan sát được.
Tuy nhiên, để tránh những trường hợp “ngoại lai” như những tương tác đột ngột bị chậm không thường xuyên, đặc biệt là trên các trang có rất nhiều tương tác (hơn 50 lần) thì Google sẽ bỏ qua một tương tác có độ trễ cao nhất trong mỗi 50 tương tác.
Cuối cùng, INP sẽ báo cáo phân vị thứ 75 của tất cả lượt xem trang. Điều này có nghĩa là 75% người dùng thực tế sẽ có trải nghiệm tương tác bằng hoặc tốt hơn giá trị INP được báo cáo.

Cách tính toán giá trị INP cuối cùng

Giá trị INP cuối cùng này chỉ được tính toán và báo cáo khi người dùng rời khỏi trang. Điều này cho phép INP có cái nhìn toàn diện về hiệu suất phản hồi của trang trong suốt hành trình của người dùng.

Các mức điểm INP theo Google

Google đưa ra các ngưỡng điểm cụ thể để đánh giá chỉ số INP của một trang web, dựa trên dữ liệu thực tế thu thập từ người dùng (Field Data) và thường lấy ở phân vị thứ 75 (tức là 75% số lượt truy cập trang có INP bằng hoặc tốt hơn giá trị này) để đảm bảo tính đại diện cho đa số người dùng.

Hãy tưởng tượng bạn đang chấm điểm một bài kiểm tra tốc độ phản ứng. Đây là cách Google phân loại kết quả:

Tốt (Good responsiveness): INP dưới hoặc bằng 200 mili giây (ms). Trang của bạn phản hồi cực kỳ nhanh nhạy. Khi người dùng bấm, chạm hoặc gõ phím, trang web gần như lập tức hiển thị phản hồi trực quan, mang lại trải nghiệm mượt mà và liền mạch.
Cần cải thiện (Needs improvement): INP trên 200 ms và dưới hoặc bằng 500 ms. Trang của bạn có phản hồi, nhưng đôi khi có độ trễ nhỏ khiến người dùng có thể cảm nhận được. Điều này cho thấy trang web vẫn cần được tối ưu hóa thêm.
Kém (Poor responsiveness): INP trên 500 ms. Trang phản hồi rất chậm. Người dùng có thể cảm thấy trang bị “đứng hình” hoặc không hoạt động. Điều này gây ra sự thất vọng và dễ khiến họ rời bỏ trang.

Tối ưu hóa INP như thế nào tốt nhất cho SEO?

Cách 1. Cung cấp phản hồi tức thì

Ngay cả khi có một độ trễ nhỏ trong quá trình xử lý, việc cung cấp một tín hiệu trực quan ngay lập tức cho người dùng rằng tương tác của họ đã được ghi nhận sẽ tạo cảm giác rằng web phản hồi nhanh.

Các loại phản hồi tức thì:

Chỉ báo tải (Loading indicators): Hiển thị biểu tượng xoay vòng (spinner), thanh tiến trình khi một quá trình đang diễn ra.
Pop-up xác nhận: Một thông báo nhỏ xuất hiện ngay lập tức để xác nhận hành động đã thành công (ví dụ: “Đã thêm vào giỏ hàng!”).
Xác thực trường biểu mẫu tức thì: Kiểm tra và hiển thị lỗi ngay khi người dùng nhập dữ liệu vào một trường biểu mẫu (ví dụ: định dạng email sai), thay vì đợi họ gửi toàn bộ biểu mẫu.

Cách 2. Tối ưu hóa thực thi JavaScript

Tối ưu hóa thực thi JavaScript và các CSS

Thu nhỏ file JavaScript và CSS (Minify): Quá trình này loại bỏ tất cả các ký tự không cần thiết (khoảng trắng, dòng mới, bình luận) khỏi mã mà không làm thay đổi chức năng của nó. Kết quả là các file sẽ nhỏ hơn, tải nhanh hơn và ít tốn thời gian phân tích cú pháp hơn.

Nén GZip: Một phương pháp nén dữ liệu giúp giảm kích thước file JavaScript và CSS trước khi chúng được gửi từ máy chủ đến trình duyệt của người dùng. File nhỏ hơn thì tải nhanh hơn.

Sử dụng CDN (Content Delivery Network): CDN là một mạng lưới máy chủ phân phối nội dung được đặt ở nhiều vị trí địa lý khác nhau. Khi bạn sử dụng CDN để lưu trữ và phân phối file JavaScript, CSS, người dùng sẽ tải chúng từ máy chủ gần họ nhất, giúp giảm đáng kể thời gian tải.

Trì hoãn JavaScript không quan trọng (Defer non-critical JavaScript): Các script không cần thiết cho trải nghiệm ban đầu của người dùng (ví dụ: script phân tích, quảng cáo, pop-up) nên được tải và thực thi sau khi nội dung chính của trang đã sẵn sàng. Sử dụng thuộc tính defer trong thẻ <script> hoặc tải động script có thể giúp ích.

Sử dụng script async: Tương tự như defer, thuộc tính async cho phép script được tải song song với việc phân tích cú pháp HTML, nhưng sẽ thực thi ngay khi có sẵn, không chờ HTML được phân tích xong. Điều này cũng ngăn chặn việc JavaScript chặn hiển thị ban đầu của trang.

Xóa mã không sử dụng (Remove unused code): Đôi khi, các thư viện hoặc đoạn mã đã từng được sử dụng nhưng nay không còn cần thiết vẫn nằm trong dự án. Các công cụ kiểm tra hiệu suất có thể giúp bạn xác định và loại bỏ chúng.

Tối ưu hóa Event Callbacks: Các hàm xử lý sự kiện (event callback) nên được viết hiệu quả và gọn gàng. Giảm độ phức tạp của mã trong các hàm này để chúng thực thi nhanh chóng, không gây trễ khi người dùng tương tác.

Tránh chặn luồng chính (Avoid blocking the main thread): Luồng chính là nơi trình duyệt thực hiện hầu hết các công việc quan trọng. Tránh chạy các tác vụ tính toán nặng, vòng lặp lớn, hoặc các đoạn mã phức tạp trên luồng chính.

Sử dụng Web Workers: Đối với các tác vụ tính toán rất phức tạp hoặc xử lý dữ liệu lớn, hãy sử dụng Web Workers. Chúng cho phép JavaScript chạy ở một luồng riêng biệt, không làm gián đoạn luồng chính và do đó, không ảnh hưởng đến khả năng phản hồi của giao diện người dùng.

Cách 3. Phân chia các tác vụ dài

Các tác vụ JavaScript dài hơn 50ms có thể gây ra hiện tượng “giật” hoặc đóng băng trang. Thay vì để một tác vụ lớn chạy liên tục, hãy chia nó thành các “khúc” nhỏ hơn, cho phép trình duyệt có thời gian xử lý các sự kiện và cập nhật giao diện giữa các khúc đó.

Các kỹ thuật phân chia tác vụ:

setTimeout(0): Sử dụng setTimeout với thời gian chờ 0ms. Điều này không có nghĩa là tác vụ sẽ chạy ngay lập tức, mà nó sẽ được đẩy vào cuối hàng đợi tác vụ của trình duyệt, cho phép trình duyệt xử lý các tác vụ ưu tiên cao hơn (như tương tác của người dùng) trước.
requestIdleCallback: API này cho phép bạn lên lịch các tác vụ chạy khi trình duyệt đang “nhàn rỗi”, tức là không có công việc quan trọng nào khác cần xử lý.
scheduler.yield(): Một API hiện đại hơn (hoặc polyfill) cho phép bạn chủ động “nhường quyền” điều khiển luồng chính cho trình duyệt trong các hàm async. Điều này cho phép trình duyệt xử lý các tương tác người dùng hoặc cập nhật hiển thị trước khi tiếp tục thực thi mã của bạn.
Debouncing: Kỹ thuật này trì hoãn việc thực thi một hàm cho đến khi một khoảng thời gian nhất định trôi qua kể từ lần cuối cùng sự kiện được kích hoạt. Nó hữu ích cho các sự kiện xảy ra liên tục như gõ phím vào ô tìm kiếm hoặc thay đổi kích thước cửa sổ.
Throttling: Kỹ thuật này giới hạn số lần một hàm được gọi trong một khoảng thời gian nhất định, đảm bảo hàm không chạy quá thường xuyên. Nó khác với debouncing ở chỗ nó đảm bảo hàm được chạy định kỳ, không chỉ sau khi sự kiện dừng hẳn.
AbortController(): Cho phép bạn hủy bỏ một tác vụ hoặc một chuỗi tác vụ đang chạy nếu có một tương tác mới khiến tác vụ cũ trở nên lỗi thời hoặc không cần thiết.

Cách 4. Tối ưu hóa hiển thị (Rendering)

Tránh bố cục lớn, phức tạp và “layout thrashing”: “Layout thrashing” xảy ra khi bạn liên tục thay đổi kiểu dáng (style) của các phần tử và ngay lập tức yêu cầu trình duyệt đọc lại các giá trị bố cục của chúng (ví dụ: kích thước, vị trí). Điều này buộc trình duyệt phải tính toán lại bố cục nhiều lần liên tiếp, rất tốn kém tài nguyên. Hãy cố gắng nhóm các thay đổi bố cục lại với nhau và tránh đọc các giá trị bố cục ngay sau khi thay đổi chúng.
Giảm phạm vi và độ phức tạp của việc tính toán kiểu: Tránh các bộ chọn CSS quá phức tạp hoặc các quy tắc CSS ảnh hưởng đến một lượng lớn phần tử trên trang. Các quy tắc CSS đơn giản hơn và được áp dụng cho một phạm vi nhỏ hơn sẽ giúp trình duyệt tính toán kiểu dáng nhanh hơn.
Giảm kích thước DOM: DOM (Document Object Model) là cấu trúc cây của các phần tử HTML trên trang. Một DOM quá lớn (ví dụ, > 1.500 phần tử HTML) có thể làm tăng đáng kể thời gian cần thiết để trình duyệt tính toán kiểu dáng và bố cục. Hãy cố gắng giữ cho DOM của bạn gọn gàng, chỉ chứa các phần tử cần thiết.
Sử dụng content-visibility: Thuộc tính CSS này cho phép trình duyệt bỏ qua việc render nội dung của một phần tử cho đến khi nó thực sự cần thiết (ví dụ: khi người dùng cuộn đến gần phần tử đó). Điều này giúp cải thiện hiệu suất tải ban đầu và INP vì trình duyệt không phải làm việc với các phần tử ngoài màn hình.
Trình xử lý sự kiện thụ động (Passive event listeners): Với các sự kiện như scroll hoặc touchstart, trình duyệt thường phải đợi xem trình xử lý sự kiện có gọi preventDefault() hay không. Khai báo trình xử lý sự kiện là “thụ động” (passive) cho trình duyệt biết rằng nó sẽ không gọi preventDefault(), cho phép trình duyệt xử lý các sự kiện cuộn/chạm ngay lập tức mà không phải chờ phản hồi từ script của bạn.

Cách 5. Giải quyết vấn đề với các script bên thứ ba

Script bên thứ ba là mã từ các nhà cung cấp khác (ví dụ: quảng cáo, công cụ phân tích, widget chat) mà bạn nhúng vào trang web của mình. Chúng thường là nguyên nhân phổ biến gây ra INP cao.

Các script phổ biến gây chậm trễ: Các script phân tích (như Google Analytics 4), pixel theo dõi, reCAPTCHA, và các script quảng cáo (như AdSense) thường yêu cầu nhiều thời gian thực thi JavaScript và có thể chặn luồng chính, góp phần gây ra INP cao.
Trì hoãn tải các script không thiết yếu: Nếu một script bên thứ ba không cần thiết cho trải nghiệm người dùng ban đầu, hãy trì hoãn việc tải nó cho đến sau khi nội dung chính của trang đã tải xong.
Ưu tiên các script quan trọng: Xác định các script bên thứ ba nào là cực kỳ quan trọng cho chức năng cốt lõi của trang web và ưu tiên tải chúng sớm hơn. Các script khác có thể đợi.
Kiểm tra các trình xử lý sự kiện dài của bên thứ ba: Đôi khi, mã của bên thứ ba có thể thêm các trình xử lý sự kiện chạy rất lâu, ảnh hưởng đến INP của bạn. Sử dụng các công cụ gỡ lỗi để xác định xem script nào đang gây ra vấn đề.
Sử dụng kỹ thuật “yielding” cho script bên thứ ba: Nếu bạn có thể kiểm soát cách script bên thứ ba được tải hoặc thực thi, hãy khuyến khích các nhà cung cấp đó sử dụng các kỹ thuật như “yielding” để chia nhỏ các tác vụ dài của họ.

Case Study của các website lớn trong việc tối ưu INP

1. The Economic Times

Thách thức: Website của họ có thời gian phản hồi chậm, ảnh hưởng đến trải nghiệm người dùng.

Hành động: Ban đầu, họ tập trung vào việc giảm Total Blocking Time (TBT) (Tổng thời gian chặn) – một chỉ số liên quan chặt chẽ đến INP, đo lường thời gian mà luồng chính của trình duyệt bị “tắc nghẽn”. Họ đã làm theo các khuyến nghị từ Google Lighthouse.

Tải chậm các script không quan trọng: Thay vì tải tất cả JavaScript cùng lúc, họ hoãn tải những đoạn mã không thiết yếu để giải phóng luồng chính của trình duyệt, giúp trang phản hồi nhanh hơn.
Loại bỏ mã JavaScript và CSS không sử dụng: Tức là xóa bỏ những đoạn code thừa, không cần thiết mà vẫn tiêu tốn tài nguyên xử lý.
Giảm kích thước DOM: Cấu trúc trang web gọn gàng hơn giúp trình duyệt hiển thị nhanh hơn sau tương tác.
Nâng cấp React hooks trong Next.js: Để tránh việc trang phải hiển thị lại toàn bộ (rerendering) một cách không cần thiết, giúp tối ưu hóa hiệu suất.
Sử dụng requestIdleCallback và Party Town: Các kỹ thuật này giúp chuyển các tác vụ nền hoặc mã của bên thứ ba (như quảng cáo, công cụ phân tích) ra khỏi luồng chính, để chúng không làm gián đoạn tương tác của người dùng.

Kết quả:

Giảm 75% chỉ số INP trên các trang chủ đề.
Giảm 50% tỷ lệ thoát (bounce rate) – tức là số người rời trang ngay lập tức giảm đi một nửa.
Tăng 43% lượt xem trang (page views) – người dùng khám phá nhiều nội dung hơn.

2. Redbus

Thách thức: Người dùng di động, đặc biệt là những người có điện thoại không quá mạnh thường gặp phải thời gian tương tác rất cao.

Hành động: Redbus đã triển khai Real User Monitoring (RUM) sử dụng thư viện webvitals.js để xác định chính xác những phần tử nào trên trang có thời gian tương tác chậm nhất. Điều này rất quan trọng vì nó cho phép họ biết vấn đề đang ở đâu thay vì đoán mò. Sau đó, họ đã:

Giảm lượng CSS và JavaScript gây chặn hiển thị.
Giảm lượng dữ liệu được gửi trong các cuộc gọi API: Điều này giúp tiết kiệm thời gian xử lý và lọc dữ liệu.
Loại bỏ JavaScript và CSS không cần thiết.

Kết quả: Redbus đã giảm một nửa chỉ số INP và chứng kiến tỷ lệ chuyển đổi tăng 7.2%.

Ví dụ minh họa: Tưởng tượng bạn đang đặt vé xe khách online ở Việt Nam. Khi bạn tìm kiếm tuyến đường và bấm vào nút “Chọn ghế”, nếu nút đó phản hồi ngay lập tức, bạn sẽ cảm thấy tin tưởng và hoàn tất giao dịch hơn. Việc giảm độ trễ tương tác trực tiếp dẫn đến tăng doanh số, vì người dùng ít bị nản lòng và bỏ dở giữa chừng.

Bạn có thể xem qua chi tiết 2 Case Study này trong video “How to optimize web responsiveness with Interaction to Next Paint” được tôi gắn dưới đây:

9 Công cụ đo lường INP phổ biến nhất

1. Google Search Console (GSC)

GSC là một công cụ miễn phí từ Google giúp chủ sở hữu trang web theo dõi hiệu suất trang web của họ trong kết quả tìm kiếm.

Vào tháng 3 năm 2024, INP đã chính thức thay thế First Input Delay (FID) làm chỉ số Core Web Vital, và GSC đã cập nhật để hiển thị báo cáo INP, đồng thời ngừng báo cáo FID.

Đo lường INP bằng Google Search Console (GSC)

Báo cáo INP trong GSC sẽ cho bạn biết liệu các trang của bạn có vấn đề về INP hay không (ví dụ: “Sự cố INP: lớn hơn 200 ms (di động)”) và phân loại theo thiết bị (di động và máy tính để bàn).

Hạn chế: GSC rất hữu ích để biết liệu có vấn đề hay không, nhưng nó không cho bạn biết nguyên nhân cụ thể nào gây ra vấn đề đó.

Ví dụ: Bạn nhận được cảnh báo từ GSC rằng “Core Web Vitals INP issues detected on your sites” (Các vấn đề về INP của Core Web Vitals đã được phát hiện trên web của bạn) chỉ riêng cho phiên bản di động, với giá trị INP trên 200ms. Điều này cho họ biết website của bạn đang gặp vấn đề về khả năng phản hồi trên thiết bị di động, nhưng bạn sẽ không biết được vì sao web của bạn lại bị.

Đôi khi, GSC có thể báo cáo rằng không có dữ liệu INP cho trang của bạn. Điều này xảy ra khi không có đủ dữ liệu từ người dùng Chrome thực tế để tạo ra một mẫu đại diện.

2. PageSpeed Insights

PageSpeed Insights là một công cụ khác của Google cho phép bạn phân tích hiệu suất của một URL cụ thể.

PSI hiển thị dữ liệu thực tế (Field Data) được lấy từ Báo cáo trải nghiệm người dùng Chrome (CrUX). Nó cung cấp một cái nhìn tổng quan về hiệu suất của trang bạn trong 28 ngày qua.

Nó cũng hiển thị dữ liệu phòng thí nghiệm (Lab Data) được tạo ra trong một môi trường kiểm soát bằng Google Lighthouse. Dữ liệu này hữu ích để kiểm tra các tính năng mới trước khi đưa chúng lên trực tuyến.

Ví dụ: Bạn muốn kiểm tra trang chủ của mình. Bạn nhập URL vào PSI, và nó sẽ cho bạn biết điểm INP của trang đó. Nếu điểm là 50 ms, nó sẽ được xếp loại “Good” (Tốt). PSI cũng sẽ đưa ra các khuyến nghị để cải thiện điểm INP của bạn.

Nếu dữ liệu INP không khả dụng, PSI có thể hiển thị chỉ số Total Blocking Time (TBT). TBT không phải là một chỉ số Core Web Vital, nhưng nó thường tương quan với INP cao và có thể là một chỉ số thay thế hữu ích để chẩn đoán các vấn đề về khả năng phản hồi trong môi trường phòng thí nghiệm.

3. Chrome User Experience Report (CrUX)

CrUX là một tập hợp dữ liệu hiệu suất thực tế từ người dùng Chrome trên toàn thế giới. Đây là nguồn dữ liệu chính cho GSC và PSI về hiệu suất thực tế.

Hạn chế: CrUX cho bạn biết liệu có vấn đề hay không, nhưng không đi sâu vào nguyên nhân gốc rễ của vấn đề đó. Để tìm hiểu nguyên nhân, bạn cần tự thu thập thêm dữ liệu chi tiết.

Đo lường INP bằng Chrome User Experience Report

4. Thư viện web-vitals.js

Đây là cách dễ nhất để bạn tự thu thập dữ liệu INP từ người dùng thực tế của mình.

Thư viện này cung cấp dữ liệu thuộc tính (attribution data), giúp bạn xác định nguyên nhân cụ thể gây ra tương tác chậm. Dữ liệu này có thể bao gồm:

Interaction target: Phần tử mà người dùng tương tác.
Type of interaction: Loại tương tác (nhấp chuột, chạm, nhấn phím).
Script responsible: Đoạn mã JavaScript nào đã gây ra sự chậm trễ.

Thư viện web-vitals.js cũng tích hợp với Long Animation Frames API (LoAF) (từ Chrome 123) để cung cấp thông tin chi tiết hơn về các phần của tương tác bị chậm. Một tương tác bao gồm ba phần chính:

Độ trễ đầu vào (Input Delay): Thời gian từ khi người dùng bắt đầu tương tác cho đến khi trình xử lý sự kiện bắt đầu chạy.
Thời gian xử lý (Processing Duration): Thời gian thực thi các hàm xử lý sự kiện của bạn.
Độ trễ hiển thị (Presentation Delay): Thời gian từ khi các hàm xử lý sự kiện kết thúc cho đến khi trình duyệt hoàn thành việc cập nhật giao diện người dùng.

5. Các công cụ RUM bên thứ ba

Ngoài các công cụ của Google, có nhiều dịch vụ Real User Monitoring (RUM) thương mại như DebugBear hoặc Akamai mPulse.

Các công cụ này thường được xây dựng trên nền tảng web-vitals.js hoặc có cơ chế thu thập dữ liệu riêng để đo lường Core Web Vitals, cung cấp các báo cáo và phân tích sâu hơn.

6. Tiện ích Chrome Web Vitals (Chrome Web Vitals Extension)

Đây là một tiện ích trình duyệt tiện lợi cung cấp cái nhìn tổng quan nhanh về các chỉ số Core Web Vitals của trang bạn đang truy cập, bao gồm cả INP. Nó hiển thị cả dữ liệu CrUX (tổng quan UX) và các giá trị CWV theo thời gian thực của lượt truy cập hiện tại.

7. Chrome DevTools

Đây là một công cụ mạnh mẽ được tích hợp sẵn trong trình duyệt Chrome, cho phép bạn ghi lại và phân tích chi tiết các tương tác chậm.

Bước thực hiện:

Mở DevTools: Nhấn F12 trên PC hoặc Ctrl+Shift+I.
Chuyển sang tab Performance.
Mô phỏng thiết bị: Để có kết quả gần với thực tế, hãy bật mô phỏng thiết bị di động và giảm tốc độ CPU (ví dụ: “4x CPU slowdown” – mô phỏng thiết bị di động tầm trung).
Ghi lại tương tác: Nhấp vào nút “Record” (Ghi lại), sau đó tương tác với trang web của bạn (ví dụ: nhấp vào menu, nhập vào ô tìm kiếm) và dừng ghi lại.

Phân tích: Trong bảng điều khiển Performance, bạn sẽ thấy các track như “Interactions” (tương tác) và “Main Thread” (luồng chính).

Track “Interactions”: Hiển thị tổng thời lượng của mỗi tương tác.
Track “Main Thread”: Cho bạn thấy những gì đang diễn ra trên luồng chính của trình duyệt, nơi các tác vụ JavaScript, tính toán kiểu dáng, bố cục và vẽ xảy ra. Bạn có thể dễ dàng xác định các “long tasks” (tác vụ dài – kéo dài hơn 50ms) gây chặn luồng chính.
Phân tích chi tiết từng tương tác: Bằng cách di chuột hoặc nhấp vào một tương tác, bạn sẽ thấy thời gian chi tiết cho từng giai đoạn: input delay, processing duration, và presentation delay. Điều này giúp bạn biết chính xác phần nào của tương tác đang bị chậm.

8. Google Lighthouse

Đo lường INP bằng Google Lighthouse

Lighthouse là một công cụ mã nguồn mở tự động kiểm tra chất lượng trang web, bao gồm hiệu suất, khả năng tiếp cận, SEO, v.v..

Chế độ “Time span” (Thời gian kéo dài) trong bảng điều khiển Lighthouse trong DevTools cho phép bạn tương tác với trang và sau đó nhận một báo cáo về các sự kiện trong khoảng thời gian đó, bao gồm cả INP và các chẩn đoán liên quan. Điều này hữu ích để kiểm tra các luồng người dùng cụ thể.

9. Total Blocking Time (TBT)

Như đã đề cập trước đó, TBT không phải là một chỉ số Core Web Vital, nhưng nó là một chỉ số phòng thí nghiệm quan trọng thường tương quan chặt chẽ với INP cao.

TBT đo tổng thời gian mà luồng chính bị chặn bởi các tác vụ dài (trên 50ms) trong quá trình tải trang. Nếu TBT cao, có khả năng INP của bạn cũng sẽ cao, vì các tác vụ dài này có thể ngăn trình duyệt phản hồi kịp thời các tương tác của người dùng.

Kết luận

Tóm lại, INP là một chỉ số quan trọng, toàn diện hơn để đo lường khả năng phản hồi của trang web, phản ánh chính xác trải nghiệm người dùng thực tế. Việc tối ưu hóa INP không chỉ giúp cải thiện thứ hạng SEO mà còn tạo ra một trải nghiệm web mượt mà và hài lòng hơn cho người dùng.

Bài viết trên được mình nghiên cứu, tổng hợp và phân tích từ nhiều nguồn uy tín như WebDev, Google Search Central, Google Support, Search Engine Land,…. Cùng với kinh nghiệm hơn 7 năm làm SEO. Nếu bạn còn điều gì thắc mắc về INP thì bạn hãy để lại ý kiến ở phần bình luận để cùng nhau trao đổi nhé!

Nguồn bài viết tham khảo:

Hãy đánh giá nội dung

Nguyễn Thanh Trường

Founder @ SEO Center – nơi mình và team triển khai SEO & CRO giúp website tăng trưởng thật và ra đơn thật. Mình là người chịu trách nhiệm đảm bảo mọi nội dung ở đây đều... có ích thật sự.