INP là gì? Hướng dẫn đo lường và tối ưu Interaction to Next Paint dưới 200ms

Ngày 12/03/2024, Google chính thức tạo ra một bước ngoặt lớn trong giới SEO khi khai tử FID và đưa INP lên làm tiêu chuẩn Core Web Vitals cốt lõi. Gần như ngay lập tức, hàng loạt website chứng kiến thứ hạng từ khóa lao dốc. Nếu bạn đang loay hoay đi tìm câu trả lời cho câu hỏi INP là gì chính là bản đồ định hướng dành cho bạn. Chúng tôi sẽ bóc tách bản chất của chỉ số này bằng ngôn ngữ đơn giản nhất, đồng thời cung cấp cho bạn một quy trình từng bước chuẩn xác để kiểm tra, khắc phục triệt để lỗi và giành lại thứ hạng xứng đáng trên kết quả tìm kiếm.

Khái niệm INP (Interaction to Next Paint) là gì?

INP (Interaction to Next Paint) là chỉ số đo lường tốc độ phản hồi của trang web đối với các thao tác của người dùng như nhấp chuột, chạm màn hình hoặc gõ phím.

Những hành vi này bao gồm:

• Click chuột vào một nút CTA hoặc các liên kết.

• Chạm (Tap) vào màn hình trên các thiết bị di động.

• Gõ phím (nhập liệu) trên bàn phím vật lý hoặc màn hình ảo.

Đồng hồ bấm giờ của INP sẽ bắt đầu chạy ngay từ khoảnh khắc bạn thao tác. Nó chỉ dừng lại khi trình duyệt hoàn tất việc hiển thị sự thay đổi tiếp theo lên màn hình khái niệm này được gọi là Next Paint.

Khác với người tiền nhiệm FID vốn chỉ tập trung đo lường sự chậm trễ ở bước đầu tiên, INP ghi nhận lại toàn bộ quãng thời gian trình duyệt “nghĩ” và “vẽ” ra kết quả. Điều này giúp các quản trị viên đánh giá được chính xác 100% trải nghiệm thực tế của người dùng khi họ chờ đợi website phản hồi.

Các ngưỡng đánh giá điểm số INP của Google

Dựa trên tài liệu chính thức từ web.dev và dữ liệu báo cáo trải nghiệm người dùng Chrome (CrUX), điểm số INP được phân định rạch ròi thành ba mốc giới hạn. Bạn cần nắm vững các con số này để biết chính xác “sức khỏe” website của mình đang ở đâu:

• 🟢 Tốt – Dưới 200 mili giây: Trang web phản hồi gần như tức thì ngay khi có thao tác. Đây là “vùng an toàn” tuyệt đối bạn phải hướng tới để giữ chân khách hàng và tối ưu hóa tỷ lệ chuyển đổi.

• 🟠 Cần cải thiện – Từ 200 đến 500 mili giây: Độ trễ đã bắt đầu có thể cảm nhận được. Bạn sẽ nhận được các email cảnh báo màu vàng từ Google Search Console. Ở giai đoạn này, website chưa bị phạt mất top ngay lập tức, nhưng nó đã rơi vào danh sách “cần rà soát” của thuật toán.

• 🔴 Kém – Trên 500 mili giây: Trải nghiệm người dùng đang bị gián đoạn nghiêm trọng. Màn hình giật lag, nút bấm phản hồi chậm chạp. Nếu URL của bạn bị đánh dấu đỏ ở mức này, thứ hạng từ khóa sụt giảm là viễn cảnh chắc chắn sẽ xảy ra.

Tại sao Google lại chọn mốc 200 mili giây làm ranh giới chuẩn mực?

Dựa trên các nghiên cứu cốt lõi về tâm lý học hành vi tương tác giữa người và máy tính, 200ms chính là giới hạn thời gian tối đa để não bộ con người cảm nhận một hệ thống đang phản hồi “ngay lập tức”. Nếu vượt qua con số này, luồng suy nghĩ của người dùng bị đứt đoạn, họ sẽ có xu hướng bấm liên tục vào màn hình vì tưởng thao tác trước đó chưa được ghi nhận, gây ra sự ức chế tột độ.

So sánh sự khác biệt giữa INP và FID

Nếu coi việc đo lường tốc độ website là một cuộc đua, thì First Input Delay (FID) giống như một vị trọng tài bị “bịt mắt một nửa”. Chỉ số cũ này tồn tại hai lỗ hổng cực kỳ lớn khiến nó không còn đủ sức bảo vệ trải nghiệm người dùng:

• Chỉ đo tương tác đầu tiên: FID hoàn toàn bỏ qua mọi hành động của người truy cập sau cú click chuột khởi đầu.

• Bỏ sót thời gian xử lý và hiển thị: Góc nhìn của FID quá thiển cận khi chỉ đếm thời gian từ lúc bạn bấm nút cho đến khi trình duyệt bắt đầu nhận lệnh. Nó phớt lờ hoàn toàn quãng thời gian hệ thống phải gồng mình xử lý dữ liệu và kết xuất hình ảnh ra màn hình.

Ví dụ thực tiễn: Hãy tưởng tượng một khách hàng truy cập vào trang đích bán hàng của bạn và bấm nút “Thêm vào giỏ hàng”. Nút bấm lập tức nhận lệnh chỉ sau 15ms. Lúc này, FID đánh giá website của bạn đạt điểm “Tốt”. Nhưng ngay sau cú click đó, trang web bị treo cứng mất 2 giây do các đoạn script JavaScript chạy ngầm quá nặng trước khi thực sự hiện lên thông báo popup “Thêm thành công”. Trải nghiệm mua sắm vô cùng tệ hại và khách hàng bỏ đi, nhưng báo cáo FID vẫn trả về kết quả màu xanh hoàn hảo. Đó chính là lý do Google phải can thiệp!

Ngược lại, Interaction to Next Paint (INP) ra đời để lấp đầy những khoảng trống tai hại đó. INP hoạt động như một hệ thống giám sát liên tục, ghi nhận tất cả các tương tác trong suốt toàn bộ phiên truy cập của người dùng. Hơn thế nữa, nó tính toán thời gian của cả một vòng đời trọn vẹn: từ khoảnh khắc ngón tay chạm vào thiết bị cho đến khi khung hình thay đổi thực sự xuất hiện trước mắt họ. Hệ thống sẽ lấy tương tác có độ trễ tồi tệ nhất để làm điểm số INP cuối cùng đại diện cho URL đó.

Dưới đây là bảng phân tích trực quan giúp bạn dễ dàng nhìn nhận bản chất của sự chuyển giao này:

Sự khắt khe của INP chính là bộ lọc hoàn hảo để thuật toán loại bỏ những trang web giật lag ra khỏi Top đầu kết quả tìm kiếm. Khi đã thấu hiểu tại sao website của mình lại trượt bài kiểm tra này dù trước đó vẫn xanh mượt với FID, đây là lúc chúng ta xắn tay áo lên để tìm ra gốc rễ vấn đề.

Nguyên nhân kỹ thuật làm tăng thời gian phản hồi INP

Dưới góc nhìn của Technical SEO, độ trễ phản hồi xảy ra khi bộ xử lý của trình duyệt bị quá tải. Căn cứ vào 3 giai đoạn của vòng đời INP mà chúng ta đã phân tích, dưới đây là 3 “thủ phạm” chính đang ngấm ngầm phá hoại trải nghiệm người dùng trên trang của bạn:

• Luồng chính bị nghẽn do JavaScript: Trình duyệt xử lý hầu hết các tác vụ trên một “luồng chính” duy nhất – giống như một con đường hẹp chỉ có một làn xe chạy. Khi bạn nhồi nhét quá nhiều tệp JavaScript nặng nề hoặc lạm dụng các đoạn script từ bên thứ ba (như mã theo dõi Google Analytics, Facebook Pixel, hay các banner quảng cáo tự động), luồng chính sẽ rơi vào trạng thái kẹt xe trầm trọng. Kết quả là khi người dùng click chuột, trình duyệt không thể tiếp nhận ngay yêu cầu vì còn đang bận thực thi các đoạn mã chằng chịt kia, đẩy Input Delay (Độ trễ đầu vào) lên mức báo động.

• Kích thước DOM quá lớn và cấu trúc HTML phức tạp: Hãy hình dung DOM (Document Object Model) như một bộ khung xương cấu tạo nên toàn bộ giao diện trang web. Khi một URL chứa hàng ngàn phần tử HTML lồng ghép đa tầng vào nhau, bất kỳ một tương tác nhỏ nào cũng buộc trình duyệt phải quét lại và tính toán toán bộ cục. Việc phải rà soát một “bộ khung khổng lồ” chỉ để thay đổi một chi tiết nhỏ sẽ thiêu rụi một lượng lớn Processing Time (Thời gian xử lý).

• Khối lượng công việc kết xuất CSS quá sức: Ngay sau khi xử lý xong logic của thao tác, trình duyệt phải lập tức bước vào giai đoạn “vẽ” lại màn hình. Nếu giao diện của bạn sử dụng các hiệu ứng CSS chuyển động quá phức tạp, hoặc yêu cầu trình duyệt phải vẽ lại một vùng diện tích hiển thị quá rộng lớn cùng một lúc, bộ máy kết xuất sẽ bị đuối sức. Khối lượng công việc đồ họa khổng lồ này trực tiếp kéo dài Presentation Delay (Độ trễ hiển thị), khiến người dùng cảm thấy các nút bấm phản hồi vô cùng chậm chạp và giật lag.

Một sai lầm phổ biến mà 80% các Webmaster gặp phải là cố gắng tải tất cả mọi thứ ngay khi trang vừa mở. Bằng cách trì hoãn (defer) các đoạn script không quan trọng và giảm thiểu độ sâu của cây DOM (khuyến nghị giữ dưới 1.500 nodes), bạn hoàn toàn có thể cắt giảm tới 50% thời gian Main thread bị chiếm dụng vô ích.

Công cụ đo lường và kiểm tra chỉ số INP trên website

Rất may, Google không chỉ đưa ra hình phạt, họ còn cung cấp sẵn cho chúng ta một bộ công cụ nội soi chuyên sâu để bắt đúng “thủ phạm”. Dưới đây là hai bước kiểm tra bắt buộc mà mọi chuyên gia Technical SEO đều sử dụng.

Xem báo cáo tổng quan trong Google Search Console

Bước đầu tiên trong quy trình chẩn đoán luôn phải bắt đầu từ góc nhìn toàn cảnh. Google Search Console (GSC) đóng vai trò như một trạm radar cảnh báo sớm. Thay vì vội vã đưa từng đường link rời rạc vào công cụ kiểm tra, GSC giúp bạn khoanh vùng hàng loạt URL đang dính án phạt để xử lý đồng bộ.

1. Truy cập vào tài khoản GSC của bạn, nhìn sang thanh menu bên trái và nhấp vào mục Chỉ số thiết yếu về trang web (Core Web Vitals).

2. Mở báo cáo ở phần Thiết bị di động hoặc Máy tính. (Chúng tôi luôn khuyên bạn nên ưu tiên xử lý dữ liệu Mobile trước, bởi Google hiện đang áp dụng thuật toán Mobile-first Indexing).

3. Trong bảng chi tiết lỗi, hãy lọc ra danh sách các nhóm URL có trạng thái “Vấn đề về INP: dài hơn 200 mili giây (hoặc 500 mili giây)”.

Bí quyết tối ưu ở bước này là hãy học cách nhóm các trang bị lỗi tương tự nhau. Lỗi INP thường mang tính hệ thống. Ví dụ, nếu một đoạn mã theo dõi làm nghẽn luồng chính trên một trang chi tiết sản phẩm, khả năng cao là 1.000 trang sản phẩm khác dùng chung bộ giao diện đó cũng đang mắc bệnh. Khi bạn phát hiện được sự trùng lặp về cấu trúc URL trong GSC, bạn chỉ cần sửa một lỗi gốc là có thể cứu được cả ngàn trang.

Phân tích nguyên nhân chi tiết bằng PageSpeed Insights

Sau khi đã khoanh vùng được “hiện trường” nhờ Search Console, đây là lúc chúng ta đưa một URL đại diện vào phòng thí nghiệm PageSpeed Insights (PSI) để mổ xẻ chi tiết từng dòng code.

Nhập URL của bạn vào PSI và đợi hệ thống phân tích. Đừng vội nhìn vào điểm số 1-100 màu mè bên dưới. Nơi đầu tiên bạn cần tập trung sự chú ý là khu vực Khám phá những trải nghiệm của người dùng thực tế . Dữ liệu tại đây chính là con số INP trung bình được ghi nhận từ chính khách hàng của bạn trong suốt 28 ngày qua. Đây là bản án thực sự quyết định thứ hạng SEO, chứ không phải các bài test trong môi trường giả lập.

Để truy tìm chính xác đoạn mã gây lỗi, bạn hãy cuộn xuống phần Chẩn đoán và thực hiện các bước sau:

• Tìm đến tab Tránh các tác vụ dài trong luồng chính. Hệ thống sẽ liệt kê đích danh tệp JavaScript (tên file .js, mã nguồn bên thứ 3) đang chiếm dụng bộ nhớ lâu nhất.

• Kiểm tra mục Tránh kích thước DOM quá lớn. Nếu xuất hiện cờ cảnh báo đỏ ở đây, điều đó có nghĩa là cấu trúc HTML của bạn đang quá cồng kềnh, khiến trình duyệt mất quá nhiều thời gian tính toán lại bố cục mỗi khi người dùng chạm vào màn hình.

Đã bắt được bệnh và chỉ mặt đặt tên được nguyên nhân gốc rễ, thao tác cuối cùng của chúng ta chính là “lên bàn mổ”. Ở phần tiếp theo, chúng ta sẽ bước thẳng vào quy trình can thiệp mã nguồn để ép chỉ số INP về lại mốc an toàn dưới 200ms.

4 bước tối ưu hóa INP để đạt điểm xanh dưới 200ms

Việc xác định đúng đoạn mã gây nghẽn luồng chính mới chỉ là một nửa chặng đường. Dưới đây là phác đồ “phẫu thuật” 4 bước chính xác, an toàn và hiệu quả nhất mà chúng tôi đang áp dụng để giúp các dự án của khách hàng đưa chỉ số INP về lại mốc xanh lý tưởng.

Trì hoãn và chia nhỏ quá trình thực thi JavaScript

Không phải mọi đoạn mã JavaScript đều cần thiết để hiển thị ngay trong vài giây đầu tiên người dùng truy cập. Việc bắt trình duyệt tải toàn bộ tài nguyên cùng một lúc chính là nguyên nhân lớn nhất gây tê liệt luồng chính (Main thread). Để giải quyết bài toán này, bạn cần thiết lập lại thứ tự ưu tiên:

• Sử dụng thuộc tính Defer và Async: Hãy gắn thẻ defer hoặc async cho các tệp script không tham gia trực tiếp vào việc định hình giao diện màn hình đầu tiên. Thao tác này ra lệnh cho trình duyệt cứ tiếp tục tải trang web và chỉ thực thi các script phụ khi hệ thống đã rảnh tay.

• Áp dụng kỹ thuật Code Splitting (Chia nhỏ mã): Thay vì bắt người dùng tải một tệp bundle.js khổng lồ dung lượng vài Megabytes, kỹ thuật này cắt hệ thống mã thành nhiều mảnh nhỏ. Trình duyệt sẽ chỉ tải đoạn mã cần thiết cho giao diện mà khách hàng đang xem ở thời điểm hiện tại, giúp phản hồi các thao tác click hoặc cuộn trang gần như ngay lập tức.

Tối ưu hóa các script bên thứ 3

Website của bạn đang gánh bao nhiêu mã theo dõi từ các bên thứ ba? Nút chat trực tuyến, Facebook Pixel, Google Analytics, hay các mã nhúng quảng cáo tự động đều là những “bóng ma” âm thầm ngốn sạch tài nguyên xử lý.

• Thanh lọc hệ thống: Mở bảng điều khiển plugin hoặc mã nguồn và gỡ bỏ triệt để các công cụ đo lường, tiện ích mở rộng không còn tạo ra giá trị kinh doanh.

• Quản lý thông minh bằng Google Tag Manager (GTM): Đối với các mã theo dõi bắt buộc phải giữ lại, đừng ném trực tiếp chúng vào thẻ <head>. Hãy cấu hình chúng qua GTM và thiết lập kịch bản trì hoãn. Nghĩa là, Facebook Pixel hay hệ thống Chatbox sẽ chỉ được kích hoạt hoạt động sau khi người dùng thực hiện thao tác cuộn chuột hoặc chạm vào màn hình đầu tiên.

Giảm kích thước DOM và tối ưu hóa giao diện

Một cấu trúc web cồng kềnh với hàng ngàn phần tử HTML lồng ghép vào nhau sẽ khiến trình duyệt phải thực hiện khối lượng tính toán khổng lồ mỗi khi có một thay đổi nhỏ về giao diện.

• Làm phẳng cấu trúc thiết kế: Vấn đề này thường gặp nhất ở các trang web dùng Page Builders như Elementor hay Divi, nơi mỗi đoạn văn bản lại bị nhốt trong 4-5 thẻ <div> lồng nhau. Hãy rà soát lại bố cục, xóa bỏ các phần tử bọc ngoài không cần thiết để duy trì tổng số DOM Nodes dưới mức 1.500.

• Tận dụng CSS Content-visibility: Đây là một thủ thuật cực kỳ mạnh mẽ. Bằng cách thêm thuộc tính content-visibility: auto; vào các vùng nội dung nằm tít bên dưới chân trang (như phần footer hoặc mục bài viết liên quan), trình duyệt sẽ tạm thời bỏ qua việc kết xuất khu vực đó. Chúng chỉ thực sự được “vẽ” ra khi khách hàng cuộn chuột đến gần, qua đó tiết kiệm tối đa sức mạnh xử lý ở thời điểm đầu.

Giải phóng luồng chính bằng Web Workers

Nếu luồng chính của trình duyệt là một sân khấu, thì JavaScript chính là diễn viên đang chiếm sóng quá lâu khiến các tiết mục khác (phản hồi tương tác của người dùng) không thể diễn ra. Web Workers ra đời để giải quyết triệt để sự độc quyền này.

Công nghệ này cho phép bạn thuê một “trợ lý hậu trường”. Thay vì để luồng chính xử lý các phép toán phức tạp, phân tích dữ liệu data nặng nề hay lọc thông tin tìm kiếm, bạn đẩy toàn bộ khối lượng công việc đó ra phía sau để chạy nền. Nhờ vậy, Main thread luôn ở trạng thái hoàn toàn rảnh rỗi, sẵn sàng tiếp nhận và phản hồi ngay lập tức mọi cú click chuột của khách hàng, đảm bảo điểm số INP luôn nằm gọn dưới ngưỡng 200ms.

Kết luận

INP (Interaction to Next Paint) hoàn toàn không phải là một thuật toán đánh đố từ Google. Sự nâng cấp này là lời khẳng định mạnh mẽ cho việc trải nghiệm thực tế của con người phải được đặt lên hàng đầu. Một trang web tải nhanh trên máy đo nhưng lại đơ cứng khi khách hàng chạm vào sẽ không còn chỗ đứng trên bảng xếp hạng. Bằng việc tuân thủ quy trình xử lý JavaScript, kiểm soát DOM và giải phóng luồng chính, bạn không chỉ khóa chặt vị trí TOP 1 Google mà còn triệt tiêu hoàn toàn sự ức chế của người mua, từ đó đẩy vọt tỷ lệ chuyển đổi.

Ngay sau khi bộ phận kỹ thuật hoàn tất các tinh chỉnh trên mã nguồn, hãy truy cập lại vào bảng điều khiển Google Search Console. Mở báo cáo Core Web Vitals, chọn chi tiết lỗi INP và nhấn nút “Xác thực bản sửa lỗi”. Google sẽ cần một chu kỳ 28 ngày để thu thập lại dữ liệu trải nghiệm từ người dùng thực tế trước khi chính thức gỡ bỏ hoàn toàn trạng thái cảnh báo đỏ cho website của bạn. Đừng quên theo dõi sát sao biểu đồ trong suốt khoảng thời gian này!

Founder Lê Hưng

Tôi là Lê Hưng, là Founder và CEO của SEOVIET, với hơn 14 năm kinh nghiệm trong lĩnh vực SEO. Dưới sự lãnh đạo của tôi, SEOVIET đã xây dựng uy tín vững chắc và trở thành đối tác tin cậy của nhiều doanh nghiệp. Tôi còn tích cực chia sẻ kiến thức và tổ chức các sự kiện quan trọng, đóng góp vào sự phát triển của cộng đồng SEO tại Việt Nam.