INP là gì? Cách đo và tối ưu Interaction to Next Paint

Bạn mở Search Console, vào báo cáo Core Web Vitals và thấy một dòng cảnh báo lạ: “INP lớn hơn 200 mili giây”. Trang vẫn tải nhanh, điểm PageSpeed vẫn xanh, ảnh vẫn nhẹ — nhưng Google vẫn báo lỗi. Đây là tình huống rất nhiều chủ website gặp phải kể từ tháng 3/2024, thời điểm Google chính thức đưa INP vào bộ chỉ số Core Web Vitals và loại bỏ FID.

Vấn đề nằm ở chỗ: INP không đo tốc độ tải trang. Nó đo độ nhạy của trang — khoảng thời gian từ lúc người dùng bấm vào một nút cho đến lúc màn hình thực sự thay đổi để phản hồi cú bấm đó. Một trang có thể tải trong 1,2 giây nhưng vẫn có INP 600ms, vì mỗi lần người dùng bấm menu thì giao diện đứng hình gần nửa giây. Đó chính là loại trải nghiệm khiến người ta bấm hai ba lần rồi thoát ra — và Google đo được điều đó.

Bài viết này giải thích INP là gì, cách Google chấm điểm, vì sao chỉ số này thay thế FID, những nguyên nhân kỹ thuật thực sự khiến INP kém, và một lộ trình tối ưu theo thứ tự tác động giảm dần để bạn không phí thời gian vào những việc không thay đổi được con số.

INP là gì?

INP là viết tắt của Interaction to Next Paint — tạm dịch là “từ tương tác đến khung hình kế tiếp”. Đây là chỉ số đo độ trễ phản hồi của trang web: khi người dùng thực hiện một tương tác (bấm chuột, chạm màn hình, gõ phím), trình duyệt mất bao lâu để vẽ ra khung hình mới phản ánh kết quả của tương tác đó.

INP là một trong ba chỉ số thuộc bộ Core Web Vitals của Google, bên cạnh LCP (đo tốc độ hiển thị nội dung chính) và CLS (đo độ ổn định bố cục). Nếu LCP trả lời câu hỏi “trang hiện ra nhanh không?” thì INP trả lời câu hỏi “trang có phản hồi mượt khi tôi dùng nó không?”.

INP đo chính xác cái gì

Một tương tác trong mắt trình duyệt được chia thành ba giai đoạn, và INP cộng cả ba lại:

• Input delay (độ trễ đầu vào): khoảng thời gian từ khi người dùng bấm cho đến khi trình duyệt bắt đầu chạy đoạn mã xử lý sự kiện. Nếu luồng chính đang bận chạy một đoạn JavaScript khác, cú bấm phải xếp hàng chờ.
• Processing time (thời gian xử lý): thời gian chạy toàn bộ các hàm xử lý sự kiện gắn với tương tác đó. Một hàm onClick nặng, tính toán nhiều, gọi API đồng bộ sẽ kéo dài giai đoạn này.
• Presentation delay (độ trễ hiển thị): thời gian trình duyệt tính lại bố cục, vẽ lại và đưa khung hình mới lên màn hình sau khi mã đã chạy xong.

Điểm quan trọng: INP chỉ dừng đồng hồ khi khung hình mới đã được vẽ xong. Đây là khác biệt cốt lõi so với chỉ số cũ, và cũng là lý do nhiều website từng có điểm Core Web Vitals đẹp bỗng nhiên bị đánh trượt.

Những tương tác nào được tính

Không phải mọi hành vi của người dùng đều được INP ghi nhận. Chỉ ba nhóm sau được tính:

• Bấm chuột (click)
• Chạm màn hình cảm ứng (tap)
• Gõ phím (keypress), bao gồm cả bàn phím ảo trên di động

Cuộn trang (scroll) và di chuột (hover) không được tính vào INP, vì trình duyệt xử lý chúng trên luồng riêng. Đây là chi tiết hay bị hiểu nhầm: nhiều người cố tối ưu hiệu ứng cuộn để cải thiện INP nhưng con số không nhúc nhích, đơn giản vì scroll không nằm trong phạm vi đo.

Google lấy con số nào làm đại diện cho cả trang

Một phiên truy cập có thể phát sinh hàng chục tương tác. Google không lấy trung bình — cách đó sẽ che mất những lần giật nặng nhất. Thay vào đó:

• Nếu phiên có dưới 50 tương tác, INP của phiên là tương tác chậm nhất.
• Nếu phiên có nhiều hơn 50 tương tác, cứ mỗi 50 tương tác thì bỏ qua một giá trị tệ nhất, nhằm loại bỏ các trường hợp cá biệt do máy người dùng bị treo.

Sau đó, ở cấp độ website, Google lấy phân vị thứ 75 (p75) của toàn bộ dữ liệu người dùng thật trong 28 ngày gần nhất. Nghĩa là 75% lượt truy cập phải đạt ngưỡng thì trang mới được chấm “Tốt”. Cách tính này bảo vệ nhóm người dùng có máy yếu và mạng chậm — vốn chính là nhóm dễ bị bỏ qua nếu ta chỉ test trên máy tính cá nhân.

Ba mức ngưỡng INP theo Google

Google chia INP thành ba mức rõ ràng:

Mức đánh giá	Giá trị INP (p75)	Cảm nhận của người dùng	Mức ưu tiên xử lý
Tốt	≤ 200 ms	Phản hồi gần như tức thì, không nhận ra độ trễ	Giữ nguyên, chỉ theo dõi định kỳ
Cần cải thiện	200 – 500 ms	Cảm nhận được một khoảng khựng nhẹ sau khi bấm	Đưa vào kế hoạch tối ưu trong quý
Kém	> 500 ms	Giao diện như treo, người dùng bấm lại nhiều lần	Xử lý gấp, ảnh hưởng trực tiếp chuyển đổi

Mốc 200ms không phải con số tùy tiện. Nghiên cứu về tâm lý tương tác người–máy cho thấy dưới khoảng 100–200ms, não bộ vẫn coi phản hồi là “ngay lập tức” và liên kết nó với hành động vừa thực hiện. Vượt quá 500ms, người dùng bắt đầu nghi ngờ rằng cú bấm không ăn, và hành vi điển hình là bấm lại lần nữa — điều này lại tạo thêm tương tác, thêm tác vụ cho luồng chính, và đẩy INP lên cao hơn nữa. Đó là một vòng xoáy tự khuếch đại.

Vì sao Google thay FID bằng INP?

FID (First Input Delay) từng là chỉ số đo độ nhạy trong Core Web Vitals, nhưng nó có một điểm yếu lớn đến mức gần như vô dụng trên thực tế.

FID chỉ đo độ trễ đầu vào của tương tác đầu tiên trong phiên. Nó dừng đồng hồ ngay khi trình duyệt bắt đầu chạy mã xử lý — hoàn toàn bỏ qua việc đoạn mã đó chạy mất bao lâu và giao diện có cập nhật hay không. Hệ quả là một trang có thể đạt FID 20ms “rất tốt” trong khi người dùng bấm nút và chờ 2 giây mới thấy gì thay đổi.

Thống kê của Google trước khi chuyển đổi cho thấy khoảng 95% website đạt ngưỡng FID tốt — một tỷ lệ cao bất thường, chứng tỏ chỉ số này không còn phân biệt được website tốt và website kém. Khi chuyển sang INP, tỷ lệ đạt ngưỡng tụt xuống rõ rệt, phản ánh đúng thực trạng hơn.

Bảng dưới tóm tắt khác biệt:

Tiêu chí	FID (đã ngừng)	INP (hiện hành)
Phạm vi đo	Chỉ độ trễ đầu vào	Trọn vòng đời: đầu vào + xử lý + hiển thị
Số tương tác xét	Chỉ tương tác đầu tiên	Toàn bộ tương tác trong phiên
Điểm dừng đồng hồ	Khi bắt đầu chạy mã	Khi khung hình mới được vẽ
Ngưỡng tốt	≤ 100 ms	≤ 200 ms
Độ tin cậy thực tế	Thấp — dễ đạt một cách hình thức	Cao — bám sát cảm nhận thật

Nói ngắn gọn: FID đo xem trình duyệt có nghe thấy cú bấm không. INP đo xem trang có trả lời cú bấm không. Đó là hai câu hỏi hoàn toàn khác nhau, và câu hỏi thứ hai mới là thứ người dùng quan tâm.

INP ảnh hưởng đến thứ hạng và doanh thu như thế nào?

Cần nói thẳng để tránh kỳ vọng sai: INP là tín hiệu xếp hạng phụ, không phải yếu tố quyết định. Nó nằm trong nhóm tín hiệu Page Experience, và Google đã nhiều lần khẳng định nội dung phù hợp với nhu cầu tìm kiếm vẫn quan trọng hơn. Một trang INP 500ms nhưng trả lời đúng câu hỏi vẫn có thể xếp trên một trang INP 100ms nội dung sơ sài.

Tuy nhiên, INP tác động theo ba đường gián tiếp và những đường này thường mạnh hơn tác động xếp hạng trực tiếp:

• Tiêu chí phân định khi nội dung ngang nhau. Trong những truy vấn cạnh tranh, khi nhiều trang có chất lượng nội dung tương đương, trải nghiệm trang trở thành yếu tố phân định. Đây là lúc INP có tiếng nói.
• Tín hiệu hành vi người dùng. Trang phản hồi chậm đẩy tỷ lệ thoát lên và tạo ra hiện tượng pogo sticking — người dùng bấm vào rồi quay lại trang kết quả tìm kiếm ngay. Chuỗi hành vi này Google quan sát được ở quy mô lớn.
• Tỷ lệ chuyển đổi. Đây mới là chỗ đau nhất về tiền. Các nút chịu ảnh hưởng nặng nhất của INP thường là nút “Thêm vào giỏ”, nút gửi form, nút lọc sản phẩm — tức đúng những điểm nằm trên đường dẫn ra đơn hàng.

Một ví dụ dễ hình dung: website bán hàng có 30.000 phiên/tháng, tỷ lệ chuyển đổi 1,8%, tức khoảng 540 đơn. Nếu nút lọc danh mục có INP 700ms khiến 8% người dùng bỏ giữa chừng, con số mất đi không phải là một chỉ số kỹ thuật mà là khoảng 43 đơn hàng mỗi tháng. Tối ưu INP trong trường hợp này không phải việc “làm cho đẹp báo cáo” mà là thu hồi doanh thu đang rò rỉ.

Những nguyên nhân thật sự khiến INP kém

Gần như toàn bộ vấn đề INP đều quy về một nguyên nhân gốc: luồng chính (main thread) của trình duyệt bị chiếm dụng. Trình duyệt chỉ có một luồng để vừa chạy JavaScript, vừa tính bố cục, vừa vẽ giao diện. Khi một tác vụ dài đang chạy, mọi thứ khác phải xếp hàng.

1. JavaScript bên thứ ba

Đây là thủ phạm số một trên phần lớn website Việt Nam. Mỗi mã chat, mã đo lường, mã quảng cáo, mã đánh giá, mã popup đều chèn thêm script chạy trên cùng luồng chính. Một website thương mại điện tử điển hình có thể đang tải cùng lúc: Google Tag Manager, Facebook Pixel, TikTok Pixel, chat widget, công cụ heatmap, và hai ba mã remarketing. Từng mã một thì nhẹ, cộng lại thì luồng chính không còn chỗ thở.

Vấn đề trầm trọng hơn vì các script này thường gắn thêm trình lắng nghe sự kiện toàn cục. Mỗi cú bấm của người dùng không chỉ chạy mã của bạn mà còn kích hoạt mã theo dõi của năm sáu bên khác nhau — tất cả đều cộng vào processing time.

2. Long task — tác vụ chạy quá dài

Bất kỳ đoạn mã nào chiếm luồng chính quá 50ms đều bị coi là long task. Trong khoảng thời gian đó, trình duyệt không thể phản hồi bất cứ tương tác nào. Nếu người dùng bấm đúng lúc một long task 400ms đang chạy, riêng input delay đã là 400ms trước khi mã xử lý của bạn kịp bắt đầu.

Long task hay xuất hiện ở: vòng lặp xử lý danh sách sản phẩm dài, thư viện chart vẽ biểu đồ, thao tác đọc/ghi localStorage hàng loạt, và các hàm khởi tạo chạy đồng loạt khi trang vừa tải xong.

3. DOM quá lớn và bố cục phức tạp

Khi cây DOM có hàng nghìn phần tử, mỗi lần trình duyệt phải tính lại bố cục là một lần tốn kém. Giai đoạn presentation delay phình to dù mã xử lý của bạn chạy rất nhanh. Trang danh mục hiển thị 200 sản phẩm cùng lúc, mỗi sản phẩm là một khối HTML nhiều lớp lồng nhau, là trường hợp kinh điển. Đây là lý do việc tối ưu trang danh mục sản phẩm thường mang lại cải thiện INP rõ rệt hơn cả việc chỉnh sửa mã.

4. Hiệu ứng CSS nặng và animation không tối ưu

Animation thay đổi các thuộc tính gây tính lại bố cục — như width, height, top, left — buộc trình duyệt tính lại toàn bộ cây bố cục ở mỗi khung hình. Animation dùng transform và opacity thì ngược lại, chạy trên luồng hợp thành và gần như không ảnh hưởng INP.

5. Popup và lớp phủ hiện ngay sau tương tác

Popup thường là tổ hợp tệ nhất: nó gắn vào sự kiện bấm, chèn thêm một khối DOM lớn, chạy animation, đồng thời gọi mã đo lường. Bốn việc nặng dồn vào đúng khoảnh khắc INP đang được đo. Nếu website bạn có popup, đây là nơi nên kiểm tra đầu tiên.

Cách đo INP chính xác

Sai lầm phổ biến nhất khi xử lý INP là đo sai nguồn dữ liệu rồi tối ưu nhầm chỗ. Cần phân biệt rõ hai loại dữ liệu.

Dữ liệu field — thứ Google thực sự dùng để chấm điểm

Dữ liệu field (hay dữ liệu CrUX) là dữ liệu thu từ người dùng Chrome thật, trên máy thật, mạng thật, trong 28 ngày gần nhất. Đây là dữ liệu duy nhất ảnh hưởng đến đánh giá Core Web Vitals của Google. Cách lấy:

• PageSpeed Insights: phần “Khám phá trải nghiệm của người dùng thực tế” ở đầu báo cáo chính là dữ liệu field. Đọc phần này trước, đừng vội cuộn xuống phần điểm số.
• Google Search Console: báo cáo Core Web Vitals nhóm các URL có cùng vấn đề lại với nhau, giúp bạn thấy được nhóm trang nào đang hỏng thay vì phải kiểm tra từng URL. Đây là điểm khởi đầu tốt nhất cho website nhiều trang.

Dữ liệu lab — để chẩn đoán, không để chấm điểm

Dữ liệu lab là kết quả chạy thử trong môi trường mô phỏng. Lighthouse không báo cáo INP vì INP cần tương tác thật của người dùng, còn Lighthouse chỉ tải trang rồi dừng. Thay vào đó, hãy dùng:

• Chrome DevTools, tab Performance: bật ghi, thao tác thật trên trang, rồi xem phần Interactions. Công cụ chỉ ra chính xác hàm nào chiếm bao nhiêu mili giây.
• Chế độ giả lập máy yếu: bật CPU throttling 4x hoặc 6x trong DevTools. Máy tính của bạn nhanh hơn thiết bị của phần lớn người dùng, nên nếu không giả lập, bạn sẽ không bao giờ tái hiện được vấn đề mà p75 đang phản ánh.
• Thư viện web-vitals: nhúng thư viện chính chủ của Google để ghi INP của người dùng thật vào GA4. Cách này cho phép bạn biết chính xác phần tử nào trên trang gây ra INP kém, thứ mà PageSpeed Insights không nói.

Nguyên tắc vàng: dữ liệu field cho biết có vấn đề hay không, dữ liệu lab cho biết vấn đề nằm ở đâu. Dùng field để quyết định có cần sửa, dùng lab để tìm chỗ sửa.

Lộ trình 5 bước kéo INP về dưới 200ms

Thứ tự dưới đây sắp theo mức độ tác động giảm dần. Làm đúng thứ tự giúp bạn thấy kết quả sớm và tránh tốn công vào những việc chỉ cải thiện vài mili giây.

Bước 1 — Đo bằng dữ liệu thật

Mở Search Console, vào báo cáo Core Web Vitals, tách riêng di động và máy tính. Ghi lại con số p75 hiện tại và danh sách nhóm URL đang ở mức “Kém”. Đây là điểm mốc — không có nó, bạn sẽ không chứng minh được việc tối ưu có tác dụng hay không. Đừng bắt đầu bằng việc sửa mã.

Bước 2 — Khoanh vùng đúng trang và đúng phần tử

INP kém hầu như không trải đều toàn site. Thông thường chỉ một vài mẫu trang có vấn đề: trang danh mục có bộ lọc, trang sản phẩm có tùy chọn biến thể, trang có form dài. Dùng DevTools mở đúng mẫu trang đó, bật CPU throttling, thao tác đúng hành vi người dùng hay làm, và xác định phần tử nào gây trễ. Sửa đúng ba phần tử thường hiệu quả hơn tối ưu chung chung toàn site.

Bước 3 — Cắt giảm JavaScript không cần thiết

Đây là bước cho cải thiện lớn nhất trên phần lớn website. Ba việc cụ thể:

• Kiểm kê toàn bộ script bên thứ ba. Liệt kê từng mã đang chạy và hỏi: mã này còn đang được dùng để ra quyết định không? Rất nhiều website vẫn đang tải pixel của chiến dịch kết thúc hai năm trước.
• Hoãn tải những gì không cần ngay. Chat widget, công cụ đánh giá, mã remarketing không cần chạy trong ba giây đầu. Tải chúng sau khi trang đã ổn định, hoặc chỉ tải khi người dùng cuộn tới.
• Gom mã đo lường về một mối. Quản lý tập trung qua Google Tag Manager giúp bạn nhìn thấy toàn bộ mã đang chạy ở một chỗ và tắt bớt có kiểm soát.

Bước 4 — Chia nhỏ tác vụ, nhường luồng chính cho giao diện

Kỹ thuật cốt lõi ở đây gọi là yielding: chủ động trả luồng chính về cho trình duyệt giữa các phần việc, để trình duyệt kịp vẽ khung hình phản hồi trước khi chạy tiếp. Nguyên tắc thực hành:

• Ưu tiên cập nhật giao diện ngay lập tức — đổi trạng thái nút, hiện spinner — rồi mới chạy phần xử lý nặng. Người dùng thấy phản hồi tức thì, INP dừng đồng hồ sớm.
• Bẻ vòng lặp dài thành nhiều đợt nhỏ, mỗi đợt nhường luồng một lần.
• Chuyển tính toán nặng sang Web Worker để chạy trên luồng riêng, không chạm vào luồng chính.
• Không gọi API đồng bộ trong hàm xử lý sự kiện.

Bước 5 — Theo dõi và đặt cảnh báo

Dữ liệu field cập nhật theo cửa sổ trượt 28 ngày, nên sau khi triển khai bạn phải chờ ít nhất 4 tuần mới thấy con số phản ánh đầy đủ. Đừng kết luận sau ba ngày. Đặt lịch kiểm tra Search Console hàng tháng, và đặc biệt kiểm tra lại mỗi khi cài thêm plugin hoặc mã theo dõi mới — đó là lúc INP hay âm thầm tụt lại.

Tối ưu INP cho website WordPress

WordPress chiếm phần lớn website Việt Nam và có những đặc thù riêng về INP. Nếu bạn đang chạy SEO cho WordPress, đây là những điểm cần soát:

• Plugin chồng plugin. Mỗi plugin có giao diện người dùng đều nạp thêm JS và CSS vào mọi trang, kể cả trang không dùng đến nó. Một site 40 plugin thường có INP kém không vì plugin nào tệ, mà vì tổng khối lượng.
• Theme đa năng. Các theme “làm được mọi thứ” thường kèm page builder nặng, tạo DOM rất sâu với nhiều lớp div lồng nhau — trực tiếp làm phình presentation delay.
• Slider và hiệu ứng trang chủ. Slider tự chạy là nguồn long task định kỳ. Cân nhắc thay bằng ảnh tĩnh, vừa giảm INP vừa cải thiện LCP.
• Plugin tối ưu tốc độ dùng sai cách. Nhiều plugin cache có tùy chọn “defer toàn bộ JavaScript”. Bật bừa có thể làm hỏng chức năng hoặc đẩy toàn bộ script dồn vào chạy cùng lúc sau khi tải, khiến INP tệ hơn. Bật từng nhóm và kiểm tra lại sau mỗi lần.

Lưu ý thêm: INP thường tệ hơn đáng kể trên di động vì CPU điện thoại yếu hơn nhiều so với máy tính. Việc tối ưu tốc độ tải trang mobile và tối ưu INP có chung phần lớn giải pháp, nên làm gộp.

Những sai lầm thường gặp khi xử lý INP

Đây là các lỗi lặp đi lặp lại, mỗi lỗi đều làm tốn thời gian mà không cải thiện con số:

• Dùng điểm Lighthouse làm thước đo INP. Lighthouse không đo INP. Điểm 100/100 không có nghĩa INP đạt. Nhiều đội đã ăn mừng nhầm vì điều này.
• Chỉ test trên máy tính đời mới. MacBook của bạn xử lý nhanh gấp nhiều lần chiếc điện thoại tầm trung mà khách hàng đang dùng. Không bật CPU throttling thì gần như không bao giờ tái hiện được vấn đề.
• Tối ưu ảnh để cải thiện INP. Nén ảnh giúp LCP, không giúp INP. Đây là hai vấn đề khác nhau — tối ưu ảnh vẫn cần làm, nhưng đừng kỳ vọng nó kéo INP xuống.
• Kết luận quá sớm. Dữ liệu 28 ngày cần thời gian để phản ánh thay đổi. Kiểm tra sau ba ngày rồi kết luận “không ăn thua” là bỏ phí công sức đã bỏ ra.
• Gỡ bỏ mã đo lường quan trọng để chạy theo con số. Tắt hết pixel thì INP đẹp nhưng bạn mất khả năng đo hiệu quả quảng cáo. Cân bằng: giữ mã cần cho quyết định kinh doanh, hoãn tải phần còn lại.
• Bỏ qua trang đích chiến dịch. Trang đích thường có nhiều mã theo dõi nhất và cũng là trang có giá trị chuyển đổi cao nhất. Đây phải là nhóm ưu tiên, không phải nhóm bỏ quên.

Checklist triển khai

Bản rút gọn để dán vào tài liệu nội bộ và tick theo:

1. Lấy con số INP p75 hiện tại từ Search Console, tách riêng di động và máy tính.
2. Liệt kê các nhóm URL đang ở mức “Cần cải thiện” và “Kém”.
3. Chọn ra 3 mẫu trang đại diện có lưu lượng cao nhất trong nhóm đó.
4. Mở DevTools, bật CPU throttling 4x, ghi lại thao tác người dùng thật.
5. Xác định 3 phần tử gây trễ nặng nhất trên mỗi mẫu trang.
6. Kiểm kê toàn bộ script bên thứ ba, đánh dấu cái nào còn dùng.
7. Gỡ mã chết, hoãn tải mã không cần chạy sớm.
8. Áp dụng yielding cho các hàm xử lý sự kiện nặng.
9. Chuyển animation sang transform và opacity.
10. Rà soát popup và lớp phủ hiện ngay sau tương tác.
11. Kiểm tra lại bằng DevTools, xác nhận cải thiện ở dữ liệu lab.
12. Chờ 28 ngày, đối chiếu dữ liệu field, ghi nhận mức thay đổi.
13. Đặt lịch kiểm tra hàng tháng và mỗi khi cài plugin mới.

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

INP bao nhiêu là đạt chuẩn?

Từ 200 mili giây trở xuống ở phân vị thứ 75 được Google đánh giá là “Tốt”. Từ 200 đến 500ms là “Cần cải thiện”, trên 500ms là “Kém”. Cần đạt ngưỡng trên cả di động và máy tính, trong đó di động thường là phần khó hơn.

INP kém có làm tụt hạng ngay không?

Không. INP là tín hiệu xếp hạng phụ, tác động rõ nhất khi các trang có chất lượng nội dung tương đương nhau. Tuy vậy ảnh hưởng gián tiếp qua tỷ lệ thoát và tỷ lệ chuyển đổi thường lớn hơn ảnh hưởng xếp hạng trực tiếp, nên vẫn đáng xử lý.

Vì sao PageSpeed Insights không hiển thị INP cho trang của tôi?

Vì trang chưa có đủ lượng người dùng Chrome thật để Google tổng hợp dữ liệu CrUX. Với website lưu lượng thấp, hãy xem dữ liệu ở cấp độ tên miền thay vì từng URL, hoặc nhúng thư viện web-vitals để tự thu thập.

Tối ưu INP mất bao lâu mới thấy kết quả?

Về mặt kỹ thuật, cải thiện xuất hiện ngay trong dữ liệu lab sau khi triển khai. Nhưng dữ liệu field của Google tính theo cửa sổ trượt 28 ngày, nên phải chờ đủ khoảng thời gian đó mới thấy con số chính thức thay đổi hoàn toàn.

Có cần thuê lập trình viên để tối ưu INP không?

Không phải lúc nào cũng cần. Phần cho cải thiện lớn nhất — gỡ mã bên thứ ba không dùng, hoãn tải chat widget, tắt slider, giảm plugin thừa — đều làm được ở mức quản trị website. Chỉ khi cần chia nhỏ tác vụ hoặc chuyển tính toán sang Web Worker mới cần đến lập trình viên.

Cuộn trang chậm có tính vào INP không?

Không. INP chỉ tính ba loại tương tác: bấm chuột, chạm màn hình và gõ phím. Cuộn và di chuột được trình duyệt xử lý riêng nên không ảnh hưởng con số INP.

Kết luận

INP là chỉ số đo độ nhạy của website — khoảng cách giữa lúc người dùng bấm và lúc màn hình thực sự thay đổi. Nó thay thế FID vì FID chỉ đo được nửa câu chuyện, và nửa bị bỏ sót lại đúng là nửa người dùng cảm nhận được.

Điều đáng nhớ nhất: INP không phải bài toán tốc độ tải trang, mà là bài toán giành lại luồng chính. Mọi kỹ thuật tối ưu hiệu quả đều quy về một việc — làm cho luồng chính rảnh đủ để trình duyệt kịp vẽ khung hình phản hồi.

Ba việc nên làm ngay trong tuần này:

1. Mở Search Console, ghi lại con số INP p75 hiện tại cho di động — đây là điểm mốc của bạn.
2. Kiểm kê danh sách script bên thứ ba đang chạy và gỡ những mã không còn phục vụ quyết định nào.
3. Mở DevTools với CPU throttling 4x, bấm thử nút quan trọng nhất trên đường dẫn chuyển đổi và xem nó mất bao nhiêu mili giây.

Ba việc này không cần lập trình viên, làm xong trong một buổi, và thường đủ để lộ ra phần lớn vấn đề. Sau đó, hãy xem INP như một chỉ số cần theo dõi định kỳ cùng các KPI SEO khác, thay vì một việc làm một lần rồi quên.