Từ tháng 3/2024, Google chính thức loại bỏ FID (First Input Delay) khỏi bộ chỉ số Core Web Vitals và thay thế bằng INP (Interaction to Next Paint). Quyết định này không phải ngẫu nhiên – FID chỉ đo tương tác đầu tiên và bỏ qua 93% các vấn đề hiệu năng còn lại trên trang web. INP ra đời để lấp khoảng trống này: theo dõi toàn bộ vòng đời tương tác, từ lúc bạn click chuột đến khi màn hình thực sự phản hồi. Nếu website bạn đạt điểm FID tốt nhưng người dùng vẫn phàn nàn về giao diện “giật lag”, đó chính là lý do bạn cần hiểu rõ sự khác biệt giữa hai chỉ số này và cách tối ưu theo tiêu chuẩn mới.
INP vs FID: Sự khác biệt & tại sao Google đổi là gì?
First Input Delay (FID) đo khoảng thời gian từ khi người dùng tương tác lần đầu (click, tap, nhấn phím) đến khi trình duyệt bắt đầu xử lý sự kiện đó. FID chỉ quan tâm đến độ trễ đầu vào (input delay), không theo dõi thời gian xử lý hay render giao diện.
Interaction to Next Paint (INP) đánh giá khả năng phản hồi tổng thể bằng cách đo tất cả tương tác trong suốt phiên truy cập. INP tính toàn bộ vòng đời: từ lúc bạn click → trình duyệt xử lý JavaScript → vẽ khung hình mới lên màn hình.
| Đặc điểm | FID | INP |
|---|---|---|
| Phạm vi đo | Chỉ tương tác đầu tiên | Toàn bộ tương tác trong phiên |
| Giai đoạn đo | Input Delay duy nhất | Input Delay + Processing + Presentation |
| Điểm kết thúc | Bắt đầu chạy event handler | Khung hình mới xuất hiện màn hình |
| Môi trường đo | Chỉ Field Data | Field Data + Lab simulation |
| Tỷ lệ đạt chuẩn | >93% trang web | <60% trang web |
Công thức toán học:
FID = t_processingStart - t_startTime
INP = Input Delay + Processing Duration + Presentation Delay
INP vs FID hoạt động như thế nào?
Khi bạn click một nút, trình duyệt trải qua 3 giai đoạn:
Giai đoạn 1: Input Delay – Thời gian chờ đợi vì Main Thread đang bận xử lý Long Tasks (thường là JavaScript đang load). FID chỉ đo giai đoạn này.
Giai đoạn 2: Processing Duration – Trình duyệt thực thi các event handler đồng bộ. Nếu code chứa vòng lặp nặng hay cập nhật DOM phức tạp, giai đoạn này kéo dài.
Giai đoạn 3: Presentation Delay – Trình duyệt tính toán lại CSS, layout, và vẽ khung hình mới. INP đo cả 3 giai đoạn này.
Dưới đây là ví dụ minh họa sự chênh lệch:
<!DOCTYPE html>
<html lang="vi">
<head>
<meta charset="UTF-8">
<title>Demo INP vs FID</title>
</head>
<body>
<button id="btn">Bắt đầu xử lý</button>
<p id="status">Đang chờ...</p>
<script>
const btn = document.getElementById('btn');
const status = document.getElementById('status');
function blockMainThread(ms) {
const start = performance.now();
while (performance.now() - start < ms) {}
}
btn.addEventListener('click', () => {
status.textContent = "Đang xử lý...";
blockMainThread(400); // Khóa Main Thread 400ms
});
</script>
</body>
</html>
Khi click lần đầu trên trang rỗng, Input Delay chỉ ~3ms → FID báo “Tốt”. Nhưng hàm blockMainThread(400) khóa luồng chính 400ms, khiến trình duyệt không thể render text mới → INP báo “Kém” (>400ms).
Ngưỡng chuẩn INP vs FID 2025
Google đánh giá hiệu năng ở phân vị thứ 75 (75th percentile) trên dữ liệu CrUX:
| Chỉ số | Tốt | Cần cải thiện | Kém |
|---|---|---|---|
| FID | ≤100ms | 100–300ms | >300ms |
| INP | ≤200ms | 200–500ms | >500ms |
Cơ chế lọc outlier của INP: Trên các trang có >50 tương tác/phiên, Google bỏ qua 1 tương tác tệ nhất mỗi 50 lần để tránh điểm số bị méo do sự cố hệ thống ngẫu nhiên. Với hầu hết trang web (<50 tương tác), tương tác chậm nhất vẫn là giá trị INP cuối cùng.
Cách đo INP vs FID: Công cụ & hướng dẫn
PageSpeed Insights
Truy cập PageSpeed Insights, nhập URL và chọn Mobile/Desktop. Phần Field Data hiển thị dữ liệu thực từ CrUX (28 ngày gần nhất). Mục “Interaction to Next Paint target” chỉ rõ phần tử HTML gây chậm nhất.
Chrome DevTools Performance Panel
- Mở DevTools (F12) → tab Performance
- Nhấn biểu tượng bánh răng → chọn CPU throttling 4x slowdown
- Nhấn Record, thực hiện tương tác (click menu, gõ text), rồi Stop
- Tìm track Interactions → click vào khối tương tác màu đỏ
- DevTools phân tích chi tiết 3 giai đoạn: Input Delay, Processing, Presentation
- Track Main bên dưới hiển thị Long Tasks (tam giác đỏ) → tab Bottom-Up chỉ file JS và dòng code gây nghẽn
Lighthouse
Lighthouse (Lab environment) không đo trực tiếp INP vì không có tương tác thật. Thay vào đó, chỉ số Total Blocking Time (TBT) là đại lượng tương quan – giảm TBT xuống <200ms giúp cải thiện INP đáng kể.
Long Animation Frames API
API hiện đại (Chrome 123+) khắc phục hạn chế của Long Tasks API:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 100) {
console.warn(`LoAF detected: ${entry.duration.toFixed(2)}ms`);
console.log(`Blocking: ${entry.blockingDuration}ms`);
entry.scripts.forEach((script) => {
console.log(`- Invoker: ${script.invoker}`);
console.log(`- Duration: ${script.duration}ms`);
console.log(`- File: ${script.sourceURL}`);
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
}
Nguyên nhân INP kém: 5 lỗi phổ biến nhất
1. Long Tasks khóa Main Thread
JavaScript chạy liên tục >50ms khiến trình duyệt không thể xử lý tương tác mới. Ví dụ: vòng lặp xử lý 10,000 sản phẩm cùng lúc, parsing JSON lớn, hay tính toán phức tạp không tách batch.
2. Third-party scripts tích tụ
Google Analytics, Facebook Pixel, chat widgets, ads scripts – mỗi thằng chiếm 50–200ms trên Main Thread. Khi tích hợp 10+ dịch vụ, tổng thời gian chặn có thể vượt 1 giây.
3. Delay JavaScript Execution sai cách
Plugin tối ưu WP Rocket, Perfmatters trì hoãn toàn bộ JS đến lúc có tương tác đầu tiên. Khi user click, trình duyệt phải load/parse/compile hàng chục file cùng lúc → menu Hamburger đơ 2–3 giây.
4. DOM tree quá tải
Page builders tạo ra 5,000–15,000 DOM nodes. Mỗi lần cập nhật giao diện, trình duyệt phải duyệt lại toàn bộ cây, tính CSS matching, recalculate layout → Presentation Delay tăng vọt.
5. Layout Thrashing
Code JavaScript đọc-ghi DOM xen kẽ trong cùng 1 task:
// Anti-pattern
element.style.width = '100px';
const height = element.offsetHeight; // Force sync layout
element.style.height = height + 'px';
const width = element.offsetWidth; // Force sync layout again
Mỗi lần đọc offsetHeight/offsetWidth, trình duyệt phải dừng để tính layout ngay lập tức → gây nghẽn Processing Duration.
Cách tối ưu INP: Hướng dẫn từng bước
Bước 1: Yield to Main Thread
Chia nhỏ Long Tasks bằng cách “nhường” quyền kiểm soát sau mỗi 50ms:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
// Áp dụng trong event handler
submitBtn.addEventListener('click', async () => {
showLoadingSpinner();
await yieldToMain(); // Trình duyệt paint spinner trước
processHeavyData();
await yieldToMain();
saveToStorage();
hideLoadingSpinner();
});
Bước 2: Xử lý batch cho vòng lặp lớn
async function processBatch(items, threshold = 50) {
let lastYield = performance.now();
for (const item of items) {
processItem(item);
if (performance.now() - lastYield > threshold) {
await yieldToMain();
lastYield = performance.now();
}
}
}
Bước 3: Sửa lỗi Delay JS trên WordPress
Nếu menu Hamburger phải tap 2 lần mới mở:
- Truy cập
https://tenmien.com/?nowprocket(bypass WP Rocket) - DevTools → Ctrl+Shift+F → tìm class CSS của menu (vd:
.menu-toggle) - Xác định file JS chịu trách nhiệm (vd:
/wp-content/themes/mytheme/js/navigation.min.js) - WP Rocket → Settings → File Optimization → Delay JavaScript Execution
- Thêm vào Excluded JavaScript Files:
/wp-content/themes/mytheme/js/navigation.min.js
/jquery(-migrate)?-?([0-9.]+)?(.min|.slim|.slim.min)?.js
- Clear cache và test lại trên mobile thật
Bước 4: Chuyển third-party lên Server-Side
Dùng Cloudflare Zaraz để xử lý tracking ở edge server thay vì client:
- Cloudflare Dashboard → Zaraz → Tools Configuration
- Add Google Analytics 4, Facebook Pixel, Hotjar…
- Browser chỉ gửi event siêu nhẹ, Cloudflare forward server-to-server
Giảm được 60–80% blocking time từ third-party scripts.
Bước 5: Tối ưu CSS rendering
/* Áp dụng cho content below-the-fold */
.footer-section,
.related-products {
content-visibility: auto;
contain-intrinsic-size: 0 500px;
}
Thuộc tính content-visibility: auto giúp trình duyệt bỏ qua render các vùng ngoài viewport → giảm Presentation Delay.
Bước 6: Tránh Layout Thrashing
// Đúng: Gom đọc trước, ghi sau
const heights = elements.map(el => el.offsetHeight); // Đọc hết
elements.forEach((el, i) => {
el.style.height = heights[i] + 'px'; // Ghi hết
});
Dùng transform và opacity thay vì thay đổi width, height, top, left – 2 thuộc tính này chỉ trigger Composite (GPU) mà không cần Layout/Paint.
INP vs FID ảnh hưởng đến SEO thế nào?
Core Web Vitals (bao gồm INP) là ranking signal chính thức trong thuật toán Page Experience của Google. INP không thể đẩy trang nội dung kém lên top, nhưng đóng vai trò tie-breaker – khi 2 trang có chất lượng nội dung tương đương, trang nào INP tốt hơn sẽ được ưu tiên.
Tác động thực tế:
- redBus: Giảm INP → tăng 80–100% conversion rate trên mobile
- Trendyol: Cắt 50% INP → CTR tăng 1% toàn hệ thống
- The Economic Times: INP từ 1,000ms xuống 257ms → bounce rate giảm 50%, pageviews tăng 43%
Trong kỷ nguyên AI Overviews, Google ưu tiên trích dẫn từ các trang có INP <150ms – nguồn phản hồi nhanh được xem là đáng tin cậy hơn.
Câu hỏi thường gặp về INP vs FID
1. Tôi có thể đo INP hoàn toàn trong Lab không?
Không. INP cần tương tác thực từ người dùng. Trong Lab, dùng Total Blocking Time (TBT) làm chỉ số tương quan – giảm TBT xuống <200ms là nền tảng để đạt INP tốt trên thực tế.
2. Tại sao FID tốt (<50ms) nhưng INP lại kém (>500ms)?
FID chỉ đo Input Delay của tương tác đầu tiên. INP đo tất cả tương tác và bao gồm cả Processing + Presentation. Nếu JavaScript xử lý lâu hoặc DOM phức tạp khiến render chậm, FID bỏ qua nhưng INP ghi nhận đầy đủ.
3. Scroll và zoom có ảnh hưởng INP không?
Không. Scroll/zoom chạy trên Compositor Thread độc lập. Nhưng nếu dùng JavaScript tạo smooth scroll tùy chỉnh, các callback đó chạy trên Main Thread và có thể gây nghẽn INP.
Kết luận
Sự chuyển đổi từ FID sang INP đánh dấu bước tiến lớn trong cách Google đánh giá trải nghiệm web thực tế. FID chỉ đo 7% vấn đề (tương tác đầu tiên), trong khi INP theo dõi toàn bộ hành trình người dùng và bao gồm cả thời gian render giao diện.
Để đạt ngưỡng tốt (≤200ms), bạn cần: yield to Main Thread đúng cách, tách batch Long Tasks, loại bỏ/dịch chuyển third-party scripts, và tối ưu CSS rendering. Đừng chỉ dựa vào Lighthouse score – kiểm tra Field Data trên PageSpeed Insights và test thực tế trên thiết bị di động tầm trung mới phản ánh đúng trải nghiệm người dùng.
Đọc tiếp:
Cách đo LCP chính xác với Chrome DevTools | Tối ưu CLS cho WordPress
Tối ưu JavaScript và CSS: Hướng dẫn giảm bundle và tăng tốc web từ A–Z (2026)
