INP (Interaction to Next Paint): Vai trò và tối ưu

Ba dữ kiện chính về INP

• INP chính thức thay FID trong Core Web Vitals vào ngày 12/03/2024.
• Ngưỡng đánh giá hiện hành là: tốt không quá 200 ms, cần cải thiện trên 200 đến 500 ms và kém trên 500 ms.
• Google đánh giá Core Web Vitals theo phân vị thứ 75 của dữ liệu người dùng thực trong cửa sổ báo cáo 28 ngày, tách riêng thiết bị di động và máy tính.

Các ngưỡng này là mục tiêu trải nghiệm, không phải lời bảo đảm thứ hạng. Google vẫn xem nội dung phù hợp và hữu ích là yếu tố trọng tâm của kết quả tìm kiếm.

INP đo những tương tác nào?

INP theo dõi tương tác bắt đầu bằng nhấp chuột, chạm trên màn hình cảm ứng hoặc nhấn phím trên bàn phím vật lý và bàn phím ảo.

Một tương tác có thể chứa nhiều sự kiện liên quan. Chẳng hạn, một cú nhấp có thể phát sinh pointerdown, pointerup, mousedown, mouseup và click.

Hệ thống gom các sự kiện thuộc cùng một hành động để đánh giá thời gian từ lúc tương tác bắt đầu đến khi khung hình tiếp theo được trình bày.

INP không đo những thao tác nào?

Cuộn trang, rê chuột, phóng to hoặc thu nhỏ không được xem là tương tác dùng để tính INP.

Tuy nhiên, công việc JavaScript hoặc rendering phát sinh khi cuộn vẫn có thể chiếm main thread. Khi người dùng nhấp ngay lúc đó, tác vụ đang chạy có thể kéo dài input delay và làm INP xấu.

Vì vậy, việc một thao tác không trực tiếp được đo không có nghĩa code gắn với thao tác đó không ảnh hưởng khả năng phản hồi.

Một tương tác INP gồm gì?

Độ trễ của một tương tác được tạo bởi ba phần: input delay, processing duration và presentation delay.

Muốn tối ưu đúng nguyên nhân, đội kỹ thuật phải xác định phần nào chiếm nhiều thời gian nhất thay vì chỉ cắt giảm JavaScript theo cảm tính.

Input delay là gì?

Input delay xuất hiện khi người dùng đã thao tác nhưng trình duyệt chưa thể bắt đầu xử lý event callback.

Nguyên nhân phổ biến là main thread đang chạy một tác vụ dài, phân tích và thực thi JavaScript, xử lý timer hoặc cập nhật giao diện từ tác vụ trước đó.

Một button có handler rất nhẹ vẫn phản hồi chậm nếu người dùng nhấp trong lúc main thread đang bị một script khác chiếm dụng.

Processing duration là gì?

Processing duration là tổng thời gian trình duyệt thực thi các callback liên quan tới tương tác.

Phần này tăng khi handler làm quá nhiều việc: lọc dữ liệu lớn, đồng bộ nhiều trạng thái, render hàng loạt phần tử hoặc gọi chuỗi hàm tốn CPU.

Giải pháp thường là giảm công việc bắt buộc trước phản hồi đầu tiên, chia nhỏ tác vụ và trì hoãn phần không ảnh hưởng khung hình tiếp theo.

Presentation delay là gì?

Presentation delay bắt đầu sau khi callback xử lý xong và kết thúc khi trình duyệt trình bày khung hình mới.

Trong giai đoạn này, trình duyệt có thể phải tính lại style, layout, vẽ và tổng hợp các lớp giao diện.

DOM lớn, selector phức tạp, thay đổi layout lặp lại hoặc render quá nhiều nội dung có thể làm presentation delay cao dù event handler kết thúc nhanh.

INP được tính như thế nào?

Trình duyệt quan sát độ trễ của những tương tác đủ điều kiện trong suốt lượt xem trang.

Đối với phần lớn phiên, tương tác có độ trễ cao nhất sẽ đại diện cho INP. Với phiên có lượng thao tác rất lớn, thuật toán loại dần một số giá trị ngoại lệ cao nhất để tránh một hiccup ngẫu nhiên chi phối toàn bộ kết quả.

Giá trị được hoàn tất khi trang bị ẩn, người dùng rời trang hoặc vòng đời lượt xem kết thúc theo cơ chế đo.

INP khác thời gian chạy một sự kiện

Đo duration của hàm click chỉ phản ánh một phần processing duration.

INP còn tính thời gian người dùng phải chờ trước callback và thời gian trình duyệt cần để hiển thị phản hồi trực quan.

Vì vậy, log thời gian một hàm bằng console không đủ để kết luận tương tác có INP tốt.

INP khác Total Blocking Time

Total Blocking Time là chỉ số lab ước tính lượng thời gian main thread bị chặn bởi các tác vụ dài trong một giai đoạn tải trang.

INP là chỉ số responsiveness dựa trên tương tác thực hoặc tương tác được tái tạo trong phiên đo.

TBT tốt có thể hỗ trợ INP nhưng không bảo đảm mọi tương tác sau khi tải xong đều phản hồi nhanh.

INP khác Time to Interactive

Time to Interactive từng cố xác định thời điểm trang trở nên có khả năng phản hồi đáng tin cậy sau tải.

INP không tìm một mốc duy nhất. Chỉ số quan sát tương tác trong toàn bộ thời gian người dùng ở lại trang.

Điều này phù hợp với ứng dụng web nơi vấn đề responsiveness có thể xuất hiện lâu sau khi trang đã tải.

INP khác First Input Delay

FID chỉ quan sát input delay của tương tác đầu tiên và không tính thời gian xử lý hoặc trình bày khung hình.

INP xem xét nhiều tương tác trong toàn bộ phiên và đo đầy đủ từ lúc thao tác bắt đầu tới lúc frame tiếp theo xuất hiện.

Bài First Input Delay giúp hiểu rõ giới hạn của chỉ số đã được INP thay thế.

INP nằm ở đâu trong Core Web Vitals?

Bộ Core Web Vitals hiện tập trung ba chiều trải nghiệm: tải nội dung chính, khả năng phản hồi và độ ổn định thị giác.

INP đại diện cho responsiveness, trong khi Largest Contentful Paint theo dõi thời gian hiển thị nội dung lớn và CLS theo dõi dịch chuyển bố cục ngoài mong đợi.

Bài Core Web Vitals là gì giúp đặt INP trong bức tranh hiệu suất tổng thể.

INP có ảnh hưởng SEO không?

Core Web Vitals được các hệ thống xếp hạng của Google sử dụng trong đánh giá trải nghiệm trang.

Tuy nhiên, điểm tốt không bảo đảm đứng đầu kết quả. Google nhấn mạnh không nên tối ưu điểm số hoàn hảo chỉ vì SEO và vẫn ưu tiên nội dung phù hợp với truy vấn.

INP nên được cải thiện vì người dùng, đồng thời xem đây là một phần của trải nghiệm trang chứ không phải nút bấm tăng hạng.

INP có ảnh hưởng chuyển đổi không?

Giao diện phản hồi chậm có thể làm người dùng nhấp lặp, bỏ form, chọn sai hoặc nghĩ rằng website bị lỗi.

Tác động kinh doanh phụ thuộc điểm chạm. Độ trễ tại nút mua hàng, thanh toán hoặc bộ lọc sản phẩm thường quan trọng hơn một tương tác ít người dùng.

Doanh nghiệp nên liên kết dữ liệu INP với funnel và event kinh doanh thay vì chỉ xem giá trị trung bình toàn site.

Field data và lab data

Field data phản ánh trải nghiệm của người dùng thật trên thiết bị, mạng, trình duyệt và trạng thái hệ thống thực tế.

Lab data đến từ môi trường kiểm thử có cấu hình và kịch bản được kiểm soát, phù hợp tái tạo và chẩn đoán nguyên nhân.

Hai loại dữ liệu bổ trợ nhau. Field data cho biết vấn đề đang xảy ra ở đâu; lab data giúp đội kỹ thuật tìm lý do và kiểm tra bản sửa.

Đo INP bằng PageSpeed Insights

PageSpeed Insights hiển thị dữ liệu CrUX nếu URL hoặc origin có đủ dữ liệu người dùng thực.

Phần field data mới là nơi dùng để đánh giá trạng thái Core Web Vitals. Kết quả Lighthouse bên dưới là một lần kiểm thử lab và không tự tạo ra giá trị INP field hoàn chỉnh.

Bài Google PageSpeed Insights là gì giải thích cách đọc đúng hai nhóm dữ liệu trong cùng báo cáo.

Lighthouse có đo INP không?

Một lần chạy Lighthouse tự động không thể tái hiện toàn bộ chuỗi tương tác của người dùng thật trong vòng đời trang.

Lighthouse cung cấp các chỉ số và chẩn đoán liên quan khả năng main thread bị chặn, JavaScript, DOM và rendering.

Hãy dùng Lighthouse để tìm cơ hội kỹ thuật, không dùng một điểm Performance đơn lẻ thay cho dữ liệu INP ngoài thực tế.

Đo INP bằng Search Console

Báo cáo Core Web Vitals trong Search Console lấy dữ liệu CrUX và nhóm các URL có đặc điểm tương tự.

Trạng thái được tách theo thiết bị. Một URL ví dụ đại diện cho nhóm, nên việc sửa chỉ một trang chưa chắc giải quyết toàn bộ template bị ảnh hưởng.

Sau khi triển khai bản sửa, dữ liệu field cần thời gian tích lũy trước khi báo cáo phản ánh đầy đủ thay đổi.

Đo INP bằng Chrome DevTools

Performance panel có thể ghi lại thao tác thực hiện cục bộ và hiển thị interaction trên timeline.

Đội kỹ thuật nên ghi phiên, thao tác vào nút hoặc form đang nghi ngờ, rồi xem input delay, event callback, style, layout và paint.

Đây là công cụ quan trọng để chuyển từ câu hỏi “INP kém” sang câu hỏi cụ thể “tương tác nào và phần nào đang chậm”.

Đo INP bằng thư viện web-vitals

Thư viện web-vitals giúp thu thập Core Web Vitals từ người dùng thật theo cách gần với dữ liệu Chrome.

Bản attribution bổ sung thông tin chẩn đoán để xác định target, interaction type và thành phần độ trễ.

Dữ liệu nên được gửi về hệ thống analytics hoặc RUM cùng URL, loại thiết bị và thông tin phiên cần thiết, đồng thời tuân thủ chính sách quyền riêng tư.

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  sendToAnalytics({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    attribution: metric.attribution
  });
});

Vì sao đoạn code cũ cần cập nhật?

Bài nguồn dùng đường dẫn CDN gắn với phiên bản thư viện cũ. API, cách đóng gói và thông tin attribution đã thay đổi theo thời gian.

Dự án hiện đại nên cài package qua hệ thống build, khóa phiên bản đã kiểm thử và theo dõi changelog chính thức.

Nếu dùng CDN, cần cân nhắc bảo mật, độ ổn định và khả năng một dịch vụ bên ngoài trở thành điểm phụ thuộc của website.

Vì sao website không có dữ liệu INP?

INP không được báo cáo nếu người dùng không thực hiện tương tác đủ điều kiện trong lượt xem trang.

CrUX và Search Console còn yêu cầu lượng dữ liệu phù hợp để bảo vệ quyền riêng tư và tạo kết quả thống kê có ý nghĩa.

Trang mới, ít traffic, nội dung đọc thuần túy hoặc URL được phân nhóm có thể không có giá trị INP riêng.

Iframe gây khác biệt dữ liệu thế nào?

JavaScript của trang mẹ không có khả năng quan sát đầy đủ tương tác bên trong iframe thông qua các API đo thông thường.

CrUX có thể phản ánh trải nghiệm gồm nội dung iframe theo cách mà RUM triển khai trên trang mẹ không nhìn thấy.

Điều này tạo chênh lệch giữa báo cáo field của Chrome và dashboard tự thu thập, nhất là với video, thanh toán hoặc widget nhúng.

Vì sao mobile INP thường kém hơn?

Thiết bị di động có dải năng lực CPU và bộ nhớ rộng, trong đó nhiều máy chậm hơn máy phát triển của đội kỹ thuật.

Main thread còn phải xử lý JavaScript, style, layout và paint trong điều kiện tài nguyên hạn chế.

Do đó, kiểm thử trên laptop mạnh mà không giảm tốc CPU hoặc không xem field data dễ bỏ sót vấn đề của người dùng thật.

Vì sao cùng URL có INP khác nhau?

Giá trị thay đổi theo thiết bị, trình duyệt, trạng thái cache, lượng dữ liệu trên trang, script bên thứ ba và hành vi người dùng.

Một người mở menu đơn giản có thể không gặp lỗi, trong khi người khác dùng bộ lọc phức tạp hoặc giỏ hàng dài tạo tương tác chậm.

RUM nên phân đoạn theo template, interaction target và nhóm thiết bị thay vì chỉ lưu một giá trị tổng.

Cách tìm interaction gây INP cao

Tối ưu input delay

Mục tiêu là giải phóng main thread để callback của tương tác bắt đầu sớm nhất có thể.

Hãy giảm JavaScript khởi tạo, trì hoãn tính năng không cần ngay, loại script không tạo giá trị và chia bundle theo trang hoặc tính năng.

Đặc biệt kiểm tra giai đoạn trang vừa hiển thị nhưng vẫn còn phân tích và thực thi nhiều script, vì người dùng có thể tương tác ngay lúc đó.

Giảm long task

Long task giữ main thread quá lâu, khiến tương tác mới phải xếp hàng.

Thay vì chạy một khối công việc lớn liên tục, hãy chia thành nhiều task nhỏ và nhường main thread giữa các phần.

Cần ưu tiên phản hồi trực quan trước, sau đó mới thực hiện cập nhật không bắt buộc cho frame kế tiếp.

Yield về main thread

Yield cho phép trình duyệt xử lý input và rendering trước khi tiếp tục phần việc còn lại.

Có thể dùng scheduler API khi phù hợp hoặc cơ chế tạo task mới với fallback được kiểm thử trên trình duyệt mục tiêu.

Không nên yield tùy tiện trong mọi dòng code. Hãy đặt ranh giới sau phần cập nhật UI quan trọng và trước công việc nền.

Tối ưu event handler

Handler nên làm lượng công việc tối thiểu cần thiết để người dùng nhận được phản hồi.

Không đọc và ghi layout xen kẽ, không render toàn bộ danh sách khi chỉ một phần tử thay đổi và không gọi logic phân tích nặng đồng bộ.

Đối với form, có thể cập nhật trạng thái trực quan trước rồi thực hiện validation phức tạp theo phần hoặc ở task sau.

Debounce và throttle có luôn tốt?

Debounce phù hợp tác vụ chỉ cần chạy sau khi người dùng tạm dừng, chẳng hạn gọi gợi ý tìm kiếm.

Throttle phù hợp tác vụ cần giới hạn tần suất trong một chuỗi sự kiện.

Dùng sai có thể làm phản hồi cảm giác chậm hơn. Tín hiệu giao diện cơ bản vẫn nên xuất hiện ngay, còn tác vụ mạng hoặc tính toán mới được trì hoãn.

Dùng Web Worker khi nào?

Web Worker phù hợp tác vụ JavaScript nặng có thể chạy tách khỏi main thread, như xử lý dữ liệu hoặc tính toán phức tạp.

Worker không trực tiếp thao tác DOM, nên ứng dụng phải thiết kế luồng trao đổi dữ liệu và cập nhật UI hợp lý.

Chi phí truyền dữ liệu, serialization và độ phức tạp kiến trúc cần được cân nhắc trước khi chuyển mọi logic sang worker.

Tối ưu presentation delay

Sau callback, trình duyệt phải tạo khung hình mới. DOM lớn hoặc thay đổi giao diện rộng có thể làm giai đoạn này kéo dài.

Hãy giảm phạm vi cập nhật, tránh render lại toàn bộ component tree và chỉ thêm số lượng node cần thiết.

Performance trace cần được xem ở các sự kiện Recalculate Style, Layout, Update Layer Tree và Paint.

Giảm kích thước DOM

DOM lớn làm tăng chi phí style và layout, nhất là khi một tương tác thay đổi class hoặc cấu trúc ở cấp cao.

Loại wrapper không cần thiết, phân trang danh sách, virtualize dữ liệu dài và không render trước toàn bộ nội dung ít khả năng được xem.

Bài JavaScript là gì giúp đội nội dung và quản trị website hiểu vai trò của script đối với tương tác và DOM.

Tránh layout thrashing

Layout thrashing xảy ra khi code liên tục đọc thông tin layout rồi ghi thay đổi khiến trình duyệt phải tính lại bố cục nhiều lần.

Hãy gom các thao tác đọc, sau đó gom các thao tác ghi và tránh vòng lặp vừa đo kích thước vừa thay đổi style.

Framework không tự loại bỏ hoàn toàn vấn đề này nếu component hoặc thư viện vẫn ép synchronous layout.

content-visibility có giúp INP không?

Thuộc tính content-visibility có thể giảm rendering cho nội dung ngoài màn hình trong một số cấu trúc trang.

Nó không phải giải pháp tự động cho mọi website. Việc áp dụng cần kiểm tra accessibility, kích thước dự phòng, tìm kiếm trong trang và hành vi khi nội dung tiến gần viewport.

Hiệu quả phải được xác minh bằng Performance trace và trải nghiệm thực.

CSS animation và JavaScript animation

Animation dùng transform và opacity thường có cơ hội chạy hiệu quả hơn những thay đổi liên tục vào thuộc tính gây layout.

Tuy nhiên, không phải cứ chuyển sang CSS là INP sẽ tốt. Animation quá nhiều, vùng paint lớn hoặc layer phức tạp vẫn tiêu tốn tài nguyên.

Ưu tiên phản hồi rõ, ngắn và không cản trở thao tác tiếp theo.

Có nên dùng will-change?

will-change là gợi ý để trình duyệt chuẩn bị cho thay đổi sắp xảy ra, nhưng sử dụng rộng có thể tăng bộ nhớ và số layer.

Chỉ áp dụng cho phần tử thực sự thường xuyên thay đổi, trong phạm vi kiểm soát và sau khi đo.

Không thêm will-change hàng loạt như một mẹo tăng tốc chung.

Tối ưu script bên thứ ba

Chat widget, heatmap, quảng cáo, A/B testing và tag Marketing có thể cạnh tranh main thread với chức năng chính.

Hãy lập danh sách owner, mục tiêu, dữ liệu thu thập, chi phí tải và tác động runtime của từng script.

Loại công cụ trùng chức năng, chỉ tải khi cần và kiểm tra INP sau mỗi thay đổi tag.

async và defer không giải quyết mọi vấn đề

async hoặc defer giúp thay đổi thời điểm tải và thực thi script so với phân tích HTML.

Script vẫn có thể chạy tác vụ dài sau khi tải và chặn tương tác của người dùng.

Đội kỹ thuật phải đo chi phí runtime, không chỉ kiểm tra thuộc tính tải trong mã nguồn.

Lazy load widget theo tương tác

Một số widget không cần thiết trước khi người dùng mở, chẳng hạn chat hỗ trợ hoặc bản đồ chi tiết.

Có thể hiển thị placeholder nhẹ và tải module khi người dùng thể hiện ý định sử dụng.

Phản hồi ban đầu phải rõ để người dùng biết hệ thống đã nhận thao tác trong khi tính năng hoàn tất khởi tạo.

Self-host script có luôn nhanh hơn?

Tự lưu trữ giúp kiểm soát cache, phiên bản và độ tin cậy của một số tài nguyên.

Tuy nhiên, điều này không làm code nhẹ hơn hoặc giảm chi phí thực thi trên main thread.

Doanh nghiệp còn phải chịu trách nhiệm cập nhật bảo mật, bản quyền và quy trình phát hành.

Tối ưu INP cho WordPress

WordPress thường tích lũy JavaScript từ theme, plugin, trình tạo trang, tracking và widget.

Hãy audit theo template, tắt plugin không sử dụng, tránh nạp asset toàn site khi chỉ một trang cần và kiểm tra event handler trùng.

Cache giúp giảm thời gian tải nhưng không tự sửa logic JavaScript hoặc rendering chậm sau tương tác.

Tối ưu INP cho WooCommerce

Các tương tác quan trọng gồm chọn biến thể, thêm giỏ hàng, mở mini cart, áp mã giảm giá, lọc sản phẩm và thanh toán.

Dữ liệu sản phẩm lớn, plugin checkout và script tracking có thể làm handler hoặc render nặng.

Đội kỹ thuật nên đo từng hành động kinh doanh trên thiết bị di động, không chỉ chạy test trang sản phẩm khi chưa tương tác.

Tối ưu INP cho form

Form có thể chậm vì validation toàn bộ dữ liệu sau mỗi phím, thư viện mask, tính phí động hoặc DOM lỗi hiển thị quá lớn.

Chỉ validate phần cần thiết tại thời điểm phù hợp và phản hồi trạng thái input ngay.

Không để request đồng bộ hoặc tính toán nặng chặn việc hiển thị focus, checkbox hoặc thông báo đang xử lý.

Tối ưu INP cho menu và bộ lọc

Menu mega, bộ lọc sản phẩm và tìm kiếm tức thời thường tạo nhiều DOM hoặc chạy logic lọc lớn.

Hãy giảm dữ liệu render, cache kết quả phù hợp, chia tính toán và hiển thị trạng thái đang cập nhật.

Nếu người dùng phải nhấp nhiều lần vì không thấy phản hồi, vấn đề trải nghiệm có thể nghiêm trọng hơn giá trị metric đơn thuần.

Tối ưu INP trong React

Kiểm tra component render lại do state hoặc context thay đổi quá rộng.

Đưa state về phạm vi cần thiết, tránh tính toán nặng trong render, memoize có chọn lọc và virtualize danh sách dài.

Profiler của framework và Chrome Performance phải được dùng cùng nhau để liên kết component với thời gian main thread.

Tối ưu INP trong ứng dụng SPA

SPA có vòng đời dài, nên interaction chậm có thể phát sinh sau nhiều lần điều hướng nội bộ.

Memory leak, listener không được dọn, cache tăng vô hạn và DOM tồn tại ngoài màn hình có thể làm hiệu suất giảm dần.

RUM cần theo dõi route và trạng thái ứng dụng, không chỉ URL tải ban đầu.

Tối ưu INP không làm hỏng chức năng

Việc trì hoãn hoặc tách code có thể tạo race condition, giao diện sai trạng thái hoặc gửi dữ liệu lặp.

Mỗi bản sửa cần kiểm tra chức năng, accessibility, analytics, lỗi JavaScript và các Core Web Vitals khác.

Không nên đổi hành vi quan trọng chỉ để làm đẹp một trace lab.

Checklist audit INP

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

Cho rằng INP chỉ đo event handler

INP còn gồm input delay và presentation delay tới khung hình tiếp theo.

Cho rằng INP luôn lấy đúng tương tác cao nhất

Phần lớn phiên đúng như vậy, nhưng phiên có rất nhiều thao tác có cơ chế giảm ảnh hưởng của ngoại lệ.

Dùng Lighthouse làm INP field

Lighthouse lab không thay dữ liệu người dùng thực trong CrUX hoặc RUM.

Nhìn điểm trung bình toàn site

Giá trị tổng có thể che interaction chậm tại checkout hoặc nhóm thiết bị yếu.

Chỉ tối ưu JavaScript tải ban đầu

INP còn bị ảnh hưởng bởi code chạy sau tải, render, DOM và script bên thứ ba.

Dùng lazy loading cho mọi thứ

Tải tính năng đúng lúc người dùng nhấp có thể làm chính tương tác đó chậm nếu không có chiến lược chuẩn bị.

Lạm dụng debounce

Debounce có thể làm phản hồi cảm giác chậm nếu trì hoãn cả tín hiệu UI cần xuất hiện ngay.

Dùng will-change hàng loạt

Cách này có thể tăng bộ nhớ và layer mà không giải quyết nguyên nhân.

Cho rằng async và defer đủ

Script tải bất đồng bộ vẫn có thể tạo long task khi thực thi.

Tự lưu trữ là tự động nhanh

Self-host không làm giảm chi phí parse, compile hoặc runtime của code.

Chỉ sửa URL ví dụ trong Search Console

Báo cáo nhóm các trang tương tự, nên nguyên nhân có thể nằm ở template dùng chung.

Cam kết INP tốt sẽ tăng hạng

Core Web Vitals góp phần vào trải nghiệm trang nhưng không bảo đảm thứ hạng tìm kiếm.

“Tối ưu INP không bắt đầu bằng việc cài thêm plugin tăng tốc. Hãy tìm đúng tương tác người dùng đang chờ, xác định main thread bận ở giai đoạn nào và giảm công việc trước khi khung hình phản hồi được hiển thị.”

Anh Thắng Giấu Tên – CEO Xuyên Việt Media

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

INP là viết tắt của gì?

INP là viết tắt của Interaction to Next Paint, chỉ số đo khả năng phản hồi đối với tương tác người dùng.

INP bao nhiêu là tốt?

Trang nên hướng tới INP không quá 200 ms tại phân vị thứ 75 của lượt xem, tách theo mobile và desktop.

INP đo click hay tải trang?

INP đo phản hồi sau click, tap và key press; nó không phải chỉ số thời gian tải nội dung chính.

Scroll có tính vào INP không?

Không trực tiếp. Tuy nhiên, tác vụ chạy khi scroll có thể chiếm main thread và làm tương tác tiếp theo chậm.

INP có đo hover không?

Không. Hover không thuộc nhóm tương tác được dùng để tính INP.

INP có thay FID không?

Có. INP đã thay FID trong bộ Core Web Vitals.

Lighthouse có đo INP chính xác không?

Lighthouse giúp chẩn đoán lab nhưng không thay dữ liệu INP từ người dùng thực.

Vì sao PageSpeed Insights không có INP?

URL hoặc origin có thể chưa đủ dữ liệu CrUX, hoặc người dùng không tạo đủ tương tác được đo.

INP có phải yếu tố xếp hạng không?

Core Web Vitals được dùng trong hệ thống xếp hạng, nhưng INP tốt không bảo đảm trang đứng đầu.

Cache có cải thiện INP không?

Cache có thể giảm công việc tải ban đầu, nhưng không tự sửa handler, DOM hoặc rendering chậm.

Plugin tối ưu có sửa được INP không?

Một số plugin có thể giảm script hoặc trì hoãn asset, nhưng hiệu quả phụ thuộc nguyên nhân và có nguy cơ làm hỏng chức năng.

Cách đo INP tốt nhất là gì?

Hãy kết hợp CrUX hoặc Search Console, RUM có attribution và Chrome DevTools để tái tạo interaction chậm.