Web Performance

Total Blocking Time (TBT)

Tổng thời gian trong giai đoạn tải trang mà main thread bị chặn > 50ms, dự báo FID/INP.

3 lượt xem Cập nhật: 29/05/2026

Total Blocking Time (TBT) là gì?

Total Blocking Time (TBT) là tổng thời gian — tính bằng mili giây — mà main thread của trình duyệt bị chặn liên tục hơn 50ms trong giai đoạn tải trang, từ lúc bắt đầu tải đến khi trang đạt trạng thái Interactive (tức người dùng có thể tương tác ổn định). Mỗi khoảng thời gian chặn dài hơn 50ms được gọi là một 'blocking time', và TBT là tổng của tất cả các blocking time đó.

TBT không đo thời gian chờ hoặc thời gian xử lý ngắn — chỉ những khoảng trên 50ms mới được tính. Đây là chỉ số dự báo gián tiếp cho First Input Delay (FID) và gần đây hơn là Interaction to Next Paint (INP), vì cả ba đều phản ánh khả năng phản hồi của trang khi người dùng tương tác.

Tại sao quan trọng trong SEO?

TBT là một trong năm chỉ số Core Web Vitals do Google công bố, và được sử dụng trực tiếp trong xếp hạng tìm kiếm trên thiết bị di động từ tháng 6/2021. Dù không phải yếu tố xếp hạng độc lập, TBT góp phần xác định mức độ trải nghiệm người dùng — yếu tố ngày càng chiếm tỷ trọng cao trong thuật toán.

Một trang có TBT thấp thường đi kèm với:

  • Tỷ lệ thoát thấp hơn (do người dùng không phải chờ lâu để tương tác),
  • Tỷ lệ chuyển đổi cao hơn (đặc biệt ở các bước nhập liệu, nhấn nút, chọn sản phẩm),
  • Khả năng giữ chân người dùng tốt hơn trên thiết bị di động — nơi tài nguyên CPU và RAM hạn chế.

Google khuyến nghị: TBT ≤ 200ms là tốt, 200–600ms là cần cải thiện, và > 600ms là kém. Giá trị này áp dụng cho hầu hết các trang web tiêu chuẩn, nhưng có thể thay đổi tùy trường hợp (ví dụ: ứng dụng web phức tạp như Figma hay Miro).

Cách hoạt động

Khi trình duyệt tải một trang, nó thực hiện nhiều tác vụ trên main thread: phân tích HTML/CSS, chạy JavaScript, xây dựng DOM/CSSOM, render layout và paint. Nếu một tác vụ JavaScript chạy quá 50ms, nó sẽ chặn các tác vụ khác — như xử lý sự kiện click, nhập liệu hoặc scroll — khiến người dùng cảm thấy trang 'đơ'.

TBT được tính bằng cách:

  1. Xác định tất cả các tác vụ dài hơn 50ms trên main thread trong khoảng thời gian từ FMP (First Meaningful Paint) đến TTI (Time to Interactive),
  2. Với mỗi tác vụ dài T ms, tính T – 50 (phần vượt ngưỡng 50ms),
  3. Cộng toàn bộ giá trị đó lại → ra TBT.

Ví dụ: nếu có ba tác vụ lần lượt dài 80ms, 120ms và 40ms → chỉ hai tác vụ đầu được tính: (80–50) + (120–50) = 30 + 70 = 100ms.

Hướng dẫn thực hiện

Để đo và cải thiện TBT, bạn cần kết hợp công cụ đo lường và tối ưu kỹ thuật:

  1. Đo lường thực tế: Sử dụng WebPageTest, PageSpeed Insights hoặc Chrome DevTools (tab Performance → chọn 'Main' → lọc các task dài > 50ms).
  2. Xác định nguyên nhân chính: Thường là JavaScript nặng, đặc biệt các thư viện lớn (React, Vue, jQuery), script không được lazy-load, hoặc code chạy đồng bộ trên main thread.
  3. Tối ưu theo thứ tự ưu tiên:
    • Chia nhỏ (code-splitting) và trì hoãn (defer) script không cần thiết cho render ban đầu,
    • Thay thế polyfill nặng bằng giải pháp nhẹ hơn hoặc loại bỏ nếu không cần hỗ trợ IE,
    • Sử dụng requestIdleCallback hoặc setTimeout với delay nhỏ để chia nhỏ tác vụ dài thành nhiều phần dưới 50ms,
    • Loại bỏ hoặc thay thế các hiệu ứng CSS gây repaint/layout nặng (ví dụ: box-shadow, filter, transform trên phần tử không được hardware-accelerated).
  4. Giám sát định kỳ: Kết nối PageSpeed Insights với Google Search Console hoặc dùng Lighthouse CI để phát hiện tăng TBT sau mỗi lần deploy.

Lỗi thường gặp

Dưới đây là những sai lầm phổ biến khi xử lý TBT và cách khắc phục:

Lỗi Hệ quả Cách khắc phục
Chạy toàn bộ bundle JS trước khi render Main thread bị chiếm trong vài trăm ms, TBT tăng mạnh Dùng defer hoặc type='module' + dynamic import; tách vendor chunk riêng
Dùng document.write() hoặc script đồng bộ trong <head> Gây block render và kéo dài thời gian TTI Loại bỏ hoàn toàn document.write(); chuyển script sang cuối <body> hoặc dùng async
Không kiểm soát hiệu ứng scroll/resize Mỗi lần scroll kích hoạt hàm xử lý dài > 50ms → cộng dồn vào TBT Dùng throttle hoặc debounce; chuyển logic sang IntersectionObserver hoặc requestAnimationFrame

Ví dụ thực tế

Một trang thương mại điện tử Việt Nam (giao diện React) có TBT ban đầu là 840ms. Phân tích qua DevTools cho thấy:

  • Một script phân tích hành vi người dùng (analytics.js) chạy đồng bộ và mất 320ms,
  • Bộ component sản phẩm tải toàn bộ danh sách 50 sản phẩm cùng lúc, kèm render ảnh không lazy-load,
  • Hàm xử lý scroll để hiển thị thanh cố định kích hoạt 15 lần/giây, mỗi lần mất 60ms.

Sau tối ưu:

  • Di chuyển analytics.js sang async và khởi tạo sau 2s,
  • Áp dụng virtualization cho danh sách sản phẩm (chỉ render 10 item đầu),
  • Thay scroll handler bằng IntersectionObserver để kiểm soát thanh cố định.

Kết quả: TBT giảm còn 162ms, thời gian TTI rút ngắn 2,3s, tỷ lệ thoát giảm 18% trong 30 ngày.

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

TBT có giống với First Input Delay (FID) không?

Không. FID đo thời gian thực tế từ lần nhấn đầu tiên của người dùng đến khi trình duyệt phản hồi. TBT là chỉ số dự báo, đo tổng thời gian main thread bị chặn trước khi người dùng tương tác. FID chỉ tồn tại khi có input thật, còn TBT luôn được tính dù không có tương tác.

Có nên tối ưu TBT nếu trang chủ yếu là nội dung tĩnh?

Có. Ngay cả trang blog đơn giản cũng có thể bị ảnh hưởng bởi script quảng cáo, widget mạng xã hội hoặc plugin CMS nặng. Một trang tin tức có TBT 420ms thường chậm hơn 1,2s so với trang cùng cấu trúc đã tối ưu — đủ để làm tăng tỷ lệ thoát 12–15% (theo dữ liệu A/B test của 3 nhà xuất bản Việt Nam năm 2023).

TBT có được tính trên mọi thiết bị không?

Google đo TBT trên thiết bị di động mô phỏng (Moto G4, 4x CPU slowdown, 1.5MBps mạng 3G). Trên máy tính để bàn, giá trị thường thấp hơn 30–50%, nhưng không được dùng làm cơ sở đánh giá SEO. Giá trị tối ưu vẫn dựa trên điều kiện di động — vì đây là kênh chiếm hơn 62% lưu lượng tìm kiếm tại Việt Nam (theo StatCounter, Q1/2024).