TBT là gì — Total Blocking Time, đo và liên hệ INP cho WordPress

TBT (Total Blocking Time) đo tổng thời gian main thread bị block bởi long task trên 50ms — đại diện cho INP trong môi trường lab. Ngưỡng “Tốt” của Lighthouse là dưới 200ms.

TBT là gì và đo ra sao

TBT là tổng thời gian main thread bị block không thể xử lý input của người dùng, tính từ FCP đến TTI (Time to Interactive). Long task trên 50ms được tính phần vượt ngưỡng 50ms vào TBT.

Ví dụ: task 120ms đóng góp 70ms vào TBT (120 − 50). TBT đo trong điều kiện lab (Lighthouse, PSI lab tab), không đo từ dữ liệu thực tế như INP.

Công thức tính TBT

TBT = tổng (thời gian long task − 50ms) cho mọi task trên 50ms giữa FCP và TTI. Task đúng 50ms hoặc dưới không được tính.

Task 200ms đóng góp 150ms. Task 1000ms đóng góp 950ms.

// Ví dụ phiên tải có 4 long task:
Task A: 80ms   → block 30ms (80-50)
Task B: 45ms   → 0ms (dưới ngưỡng 50ms)
Task C: 220ms  → block 170ms (220-50)
Task D: 110ms  → block 60ms (110-50)

TBT tổng = 30 + 0 + 170 + 60 = 260ms (Cần cải thiện)

Ngưỡng đánh giá TBT

TBT vs INP — quan hệ giữa lab và thực tế

TBT và INP đo cùng vấn đề (main thread bị block) nhưng từ 2 góc độ khác nhau. TBT đo trong điều kiện lab ngắn 5–10s sau khi tải — công cụ nhanh cho giai đoạn phát triển.

INP đo từ người dùng thực trong CrUX 28 ngày — tín hiệu xếp hạng của Google.

Site có TBT thấp thường có INP thấp, nhưng không phải luôn luôn.

4 khác biệt chính giữa TBT và INP

• Thời điểm đo: TBT chỉ đo giữa FCP và TTI (giai đoạn tải). INP đo suốt vòng đời trang, mọi lượt tương tác.
• Loại dữ liệu: TBT đo task block, không đo từng lượt tương tác cụ thể. INP đo từng click, chạm, nhấn phím.
• Nguồn dữ liệu: TBT là dữ liệu lab một lần chạy. INP là CrUX p98 từ dữ liệu thực trong 28 ngày.
• Tác động xếp hạng: TBT không phải Core Web Vital. INP là CWV chính thức từ tháng 3/2024.

Khi nào TBT thấp nhưng INP cao

Trường hợp điển hình: TBT dưới 200ms trên Lighthouse nhưng INP trên 200ms trong CrUX. Nguyên nhân thường là điểm nghẽn ở lượt tương tác sau khi tải, không phải lúc tải.

Ví dụ phổ biến: ngăn kéo giỏ hàng mở chậm, autocomplete tìm kiếm debounce kém, lag animation modal. Lighthouse không mô phỏng chuỗi click của người dùng nên không phát hiện được; INP từ người dùng thực bắt được.

4 nguồn TBT trong WordPress shop

WordPress shop điển hình có 4 nguồn TBT chính. Audit từng nguồn qua tab Performance của Chrome DevTools — ghi lại quá trình tải trang, lọc long task trên 50ms.

Click vào task để xem stack trace và xác định nguyên nhân.

Xác định đúng nguồn trước khi sửa — sửa sai nguồn thường không cải thiện TBT và lãng phí thời gian.

1. Plugin JavaScript nặng

WooCommerce cart fragment AJAX chạy mỗi lần tải trang — block main thread 100–300ms. Elementor ship bundle JS 200–500KB.

Plugin chat (Tawk.to, Crisp) tải đồng bộ khi không được defer.

Cách xác định: tắt từng plugin, đo delta TBT sau mỗi lần tắt để tìm thủ phạm.

2. Script tracker bên thứ ba không defer

• Google Tag Manager tải đồng bộ — block 100–200ms.
• Facebook Pixel và Google Analytics chạy đồng thời cùng lúc tải trang.
• Công cụ A/B test (Optimizely, VWO) chèn script đồng bộ để tránh nhấp nháy.
• Công cụ heatmap (Hotjar, Microsoft Clarity) ghi lại phiên người dùng.

3. JavaScript theme không tối ưu

Theme premium (Astra Pro, Flatsome, Avada) bundle JS 100–300KB. Code jQuery cũ tải đồng bộ, không lazy import.

Thư viện slider/carousel tải đầy đủ ngay cả khi trang không có slider.

Cách kiểm tra: mục “Reduce unused JavaScript” trong Lighthouse hiển thị từng file JS không được dùng đến.

4. Code tùy chỉnh nặng trên main thread

• Loop xử lý DOM lớn không chia thành micro-task.
• Phân tích JSON trên 1MB trong main thread.
• Regex phức tạp chạy trên sự kiện onChange của form input.
• Polyfill lazy-load ảnh kiểm tra 60 lần/giây.

Chiến lược giảm TBT cho shop WordPress

Giảm TBT cần kết hợp: defer, chia nhỏ code theo trang, và loại bỏ plugin không cần thiết. Không có công thức chung — chọn chiến lược phù hợp với quy mô shop.

Mỗi chiến lược giảm TBT điển hình 100–300ms. Kết hợp 3–4 chiến lược thường đủ để pass ngưỡng 200ms.

Defer và async cho script không critical

Thêm defer hoặc async cho mọi script bên thứ ba. defer chạy sau khi DOM parse xong; async chạy bất đồng bộ. Plugin “Async JavaScript” tự động áp dụng cho mọi script được enqueue trong WordPress.

<!-- Sai: tải đồng bộ, block parser -->
<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXX"></script>

<!-- Đúng: defer, chạy sau khi DOM parse xong -->
<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXX" defer></script>

Chia nhỏ code theo loại trang

Trang chủ tải code khác trang sản phẩm. Trang sản phẩm không cần code filter tìm kiếm của trang danh mục.

Plugin “Asset CleanUp” hoặc “Perfmatters” cho phép tắt script per loại trang.

Xem thêm tại code splitting là gì và defer vs async — khi nào dùng cái nào.

Loại bỏ plugin nặng không cần thiết

• Dùng plugin Query Monitor để xem plugin nào tải nhiều file trên frontend.
• Tắt plugin chỉ dành cho admin nhưng đang chạy trên frontend (ví dụ: Advanced Custom Fields dành cho admin).
• Thay plugin nặng bằng code nhẹ hơn (ví dụ: Contact Form 7 → Fluent Forms).

Lazy load với IntersectionObserver

Component phần dưới trang (footer, sản phẩm liên quan, bình luận) tải qua IntersectionObserver khi người dùng cuộn đến gần. Không block lần tải đầu và giảm bundle ban đầu đáng kể.

Xem thêm tại hướng dẫn lazy load ảnh 2026 và tree shaking là gì.

Theo dõi long task trên production

// Theo dõi long task trong production
new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    if (entry.duration > 50) {
      // Gửi vào GA4 hoặc logging service
      console.warn(`Long task: ${entry.duration}ms`, entry);
    }
  });
}).observe({type: 'longtask', buffered: true});

Cách đo TBT — 3 cách thực tế

TBT là chỉ số lab nên cách đo khác với INP (cần người dùng thật). Cả ba cách dưới đây đo TBT trong điều kiện kiểm soát để phát triển và debug.

Luôn chạy nhiều lần và lấy trung vị — TBT có biến động ±50–150ms giữa các lần chạy do mô phỏng CPU và mạng.

Lighthouse trong Chrome DevTools

1. Mở DevTools (F12) → tab Lighthouse.
2. Chọn “Performance” và thiết bị “Mobile” (ưu tiên cho VN).
3. Click “Analyze page load”.
4. Kết quả hiển thị TBT trong phần “Metrics”.
5. Chạy 3–5 lần, lấy trung vị để có con số đáng tin.

PageSpeed Insights — tab Lab Data

PSI tab “Lab Data” hiển thị TBT từ lần chạy Lighthouse đơn lẻ. Nhanh hơn DevTools khi cần kiểm tra nhanh không cần mở trình duyệt.

Nhớ đọc tab “Origin” cho dữ liệu CrUX thực tế (INP) song song.

Chrome DevTools — Performance tab với Long Tasks

1. Mở tab Performance, giả lập mạng “Slow 4G” và CPU 4x.
2. Click record → tải lại trang → dừng sau 10s.
3. Xem track “Main” — block đỏ là long task trên 50ms.
4. Click vào từng long task để xem stack trace và xác định file/function gây ra.
5. Tổng thời gian vượt ngưỡng 50ms của tất cả long task = TBT thủ công.

TBT điển hình trong WordPress shop — các mức cấu hình

Bảng dưới đây là ngưỡng tham chiếu theo cấu hình WordPress. Dùng để so sánh với con số hiện tại của site trước khi lập kế hoạch tối ưu.

Số liệu này là điển hình — site của bạn có thể khác đáng kể tùy số lượng plugin và chất lượng theme.

TBT theo cấu hình WordPress điển hình

Tác động TBT đến trải nghiệm người dùng

TBT cao không chỉ ảnh hưởng INP — còn ảnh hưởng cảm giác trang “phản hồi” khi người dùng lần đầu tương tác. Shop có TBT trên 600ms thường nhận phản hồi “trang chậm” từ khách dù LCP đã pass.

Google nghiên cứu chỉ ra tương quan rõ giữa TBT thấp và tỉ lệ hoàn thành đơn hàng cao hơn. Đặc biệt rõ ở bước thêm vào giỏ hàng và nhập địa chỉ giao hàng.

Checklist giảm TBT cho shop VN

1. Đo TBT baseline qua Lighthouse, chạy 3–5 lần lấy trung vị.
2. Ghi lại danh sách long task từ tab Performance DevTools.
3. Tắt từng plugin nghi ngờ, đo delta TBT sau mỗi lần tắt.
4. Thêm defer hoặc async cho tất cả script bên thứ ba.
5. Dùng “Asset CleanUp” hoặc “Perfmatters” để tắt script theo loại trang.
6. Kiểm tra mục “Reduce unused JavaScript” trong Lighthouse.
7. Loại bỏ hoặc thay thế plugin admin đang chạy trên frontend.
8. Thêm IntersectionObserver cho component phần dưới trang.
9. Đo lại TBT sau mỗi thay đổi, so sánh với baseline.
10. Thiết lập PerformanceObserver để theo dõi long task trên production.

Bài liên quan

• INP thay thế FID — chỉ số tương tác mới 2024
• Core Web Vitals 2026 — tổng quan 3 chỉ số
• Tối ưu LCP — đo và sửa toàn diện
• Defer vs async — khi nào dùng cái nào
• Tree shaking là gì — giảm bundle size JavaScript

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

Cần audit TBT và INP cho shop WordPress? Web22 xác định long task, defer code và thiết lập theo dõi production.

Xem dịch vụ tối ưu Core Web Vitals của Web22.