Total Blocking Time (TBT) là một chỉ số quan trọng dùng để đánh giá hiệu suất và trải nghiệm người dùng trên website. Trong bài viết này, Vietnix sẽ giúp bạn nắm bắt rõ khái niệm TBT, cách đo lường cũng như một số phương pháp tối ưu chỉ số này, từ đó nâng cao chất lượng hoạt động của trang.
Total Blocking Time, hay còn gọi là “tổng thời gian bị chặn”, đo lường khoảng thời gian từ First Contentful Paint (FCP) đến khi luồng chính (main thread) bị chặn đủ lâu, khiến website không thể đáp ứng kịp các thao tác của người dùng. Trong các công cụ kiểm tra hiệu suất giả lập như Lighthouse, TBT thường dừng theo dõi sau khi trang đạt Time to Interactive (TTI).
Bất cứ khi nào luồng chính (main thread) của trình duyệt thực hiện một Long Task (tác vụ kéo dài hơn 50 mili giây), trình duyệt sẽ không thể dừng giữa chừng để xử lý yêu cầu khác. Chính vì thế, mọi tương tác của người dùng trong thời gian này sẽ bị trì hoãn, tạo cảm giác “đơ”, chậm hoặc giật lag.
Thời gian chặn của một Long Task là phần vượt quá 50 ms trong tổng thời lượng tác vụ đó. Tổng hợp tất cả các thời gian chặn phát sinh giữa FCP và TTI sẽ cho ra Total Blocking Time (TBT). Ví dụ dưới đây mô tả các tác vụ chạy trên main thread:
Có 5 tác vụ đang diễn ra, trong đó 3 tác vụ được xem là Long Task vì kéo dài hơn 50 ms.
Mặc dù tổng thời gian của mọi tác vụ là 560 ms, chỉ 345 ms được tính là thời gian bị chặn vì đó là phần vượt 50 ms của từng Long Task cộng lại.
TBT và Time to Interactive (TTI) có mối liên kết chặt chẽ, bởi cả hai đều đánh giá khả năng trang web sẵn sàng đáp ứng thao tác của người dùng. Trong môi trường giả lập, TBT thường được theo dõi đến thời điểm đạt TTI thì dừng. Tuy nhiên, nếu sử dụng chế độ Lighthouse Timespan, TBT có thể được ghi nhận sau khi trang đã đạt TTI.
Mặt khác, TTI định nghĩa một trang “tương tác ổn định” nếu trong ít nhất 5 giây sau đó, main thread không xuất hiện thêm Long Task.
Ví dụ 1: Ba tác vụ dài 60 ms, rải rác trong 5 giây, TBT chỉ 30 ms (do 3 × 10 ms chênh lệch so với 50 ms).
Ví dụ 2: Một tác vụ duy nhất kéo dài 5 giây, TBT có thể lên đến 4950 ms.
Cả hai trường hợp đều có thể dẫn đến TTI tương đương, nhưng người dùng sẽ nhận thấy sự khác biệt rõ ràng giữa TBT 30 ms và 4950 ms. TBT cao hơn thể hiện sự “chậm trễ” nhiều hơn, đồng nghĩa với trải nghiệm kém mượt mà.
Để đánh giá TBT trong môi trường thử nghiệm, Lighthouse là công cụ được khuyến khích sử dụng. Bạn cũng có thể áp dụng WebPageTest để lấy dữ liệu về TBT.
Lưu ý: Dù TBT vẫn có thể được quan sát trong môi trường thực tế, kết quả có thể thiếu chính xác do các tương tác ngẫu nhiên từ người dùng. Nếu muốn biết trang phản hồi ra sao khi chạy “thực chiến”, bạn nên ưu tiên theo dõi First Input Delay (FID) và Interaction to Next Paint (INP).
Để mang đến trải nghiệm tối ưu trên các thiết bị di động có cấu hình ở mức trung bình, bạn nên cố gắng duy trì chỉ số TBT dưới 200 ms. Chỉ số TBT càng thấp, website càng sẵn sàng tương tác và đáp ứng nhanh chóng.
Để giảm bớt thời gian bị chặn, trang web nên rút ngắn hoặc chia nhỏ các tác vụ dài, ưu tiên hoàn thành các phần quan trọng sớm nhất có thể. Dưới đây là một số gợi ý:
Hạn chế code bên thứ ba: Tận dụng plugin tối ưu, sử dụng lazy load hoặc CDN để giảm tải tài nguyên ngoài.
Tối ưu JavaScript: Giảm kích thước file, tách và chạy script bất đồng bộ (async/defer) nhằm giảm thời gian luồng chính bận rộn.
Giảm tải cho main thread: Phân chia các tác vụ lớn thành từng phần nhỏ, tránh để luồng chính phải xử lý nhiều việc quá lâu.
Giảm số lượng request và dữ liệu tải: Kết hợp file CSS/JS, nén ảnh, chuyển sang định dạng ảnh hiện đại (WebP/AVIF)… để rút ngắn quá trình tải.
Các công cụ kiểm tra như Lighthouse sẽ cho bạn biết cụ thể những điểm cần khắc phục, giúp trang vận hành trơn tru và cải thiện TBT đáng kể.
Hy vọng qua bài viết này, bạn đã hiểu thêm về Total Blocking Time (TBT), cách đo lường cũng như các phương pháp cải thiện để website vận hành hiệu quả hơn. Nếu có thắc mắc hoặc ý kiến đóng góp, đừng ngần ngại để lại bình luận để cùng Vietnix trao đổi và tìm giải pháp tối ưu cho trang của bạn.