Bạn đã bao giờ truy cập một website, nội dung gần như đã hiển thị đầy đủ nhưng bấm vào nút lại không phản hồi, giao diện bị đứng lại vài giây? Đây là trải nghiệm gây khó chịu, đặc biệt khi người dùng đang cần tìm thông tin, điền biểu mẫu hoặc thực hiện thanh toán. Chỉ một vài giây chờ đợi và những thao tác không phản hồi cũng có thể khiến người dùng mất kiên nhẫn, rời khỏi trang và bỏ dở hành trình chuyển đổi.
Nguyên nhân có thể đến từ trình duyệt phải xử lý quá nhiều JavaScript và các tác vụ kéo dài trên main thread, khiến website không thể phản hồi kịp thời. Total Blocking Time (TBT) là chỉ số giúp xác định mức độ main thread bị chặn trong quá trình tải trang, qua đó phát hiện những vấn đề đang ảnh hưởng đến khả năng phản hồi của website. Vậy Total Blocking Time là gì, bao nhiêu được xem là tốt và làm thế nào để tối ưu chỉ số này hiệu quả? Cùng tìm hiểu chi tiết trong bài viết dưới đây!

- Total Blocking Time là gì?
- Công thức tính toán và cách hiểu chỉ số Total Blocking Time
- Tầm quan trọng của Total Blocking Time đối với website
- Thang điểm đánh giá chỉ số Total Blocking Time
- Phân biệt Total Blocking Time với các chỉ số website khác
- Nguyên nhân chính khiến chỉ số Total Blocking Time tăng cao
- 5 kỹ thuật tối ưu chỉ số Total Blocking Time hiệu quả nhất cho website
- Top công cụ kiểm tra và đo lường chỉ số TBT chính xác nhất
- Một số lưu ý quan trọng khi tối ưu Total Blocking Time
- Câu hỏi thường gặp về chỉ số Total Blocking Time
Total Blocking Time là gì?
Total Blocking Time (TBT) là chỉ số đo tổng thời gian main thread bị chặn bởi các tác vụ dài (Long Tasks) trong quá trình trang tải. Khi main thread phải xử lý một tác vụ kéo dài, trình duyệt có thể tạm thời không đủ khả năng phản hồi các thao tác từ người dùng, dẫn đến hiện tượng giao diện phản hồi chậm hoặc thiếu mượt mà.
Một tác vụ được xem là Long Task khi thời gian thực thi vượt quá 50 ms. Trong trường hợp này, phần thời gian vượt quá mốc 50 ms được gọi là blocking time và được tính vào tổng TBT của trang.
Ví dụ, nếu một tác vụ JavaScript mất 120ms để hoàn thành thì thời gian blocking là: 120 ms - 50 ms = 70 ms
TBT sẽ cộng blocking time của tất cả Long Tasks được ghi nhận trong khoảng thời gian đo. Do đó, TBT càng cao cho thấy main thread càng dành nhiều thời gian xử lý các tác vụ dài, làm giảm khả năng phản hồi của website. Ngược lại, TBT thấp thường phản ánh khả năng xử lý tác vụ và đáp ứng tương tác tốt hơn.

Công thức tính toán và cách hiểu chỉ số Total Blocking Time
Chỉ số Total Blocking Time (TBT) được tính dựa trên tổng thời gian vượt quá 50ms của các Long Tasks:
TBT = Σ (Thời gian thực thi Long Task - 50 ms)
Trong đó, chỉ những tác vụ có thời gian thực thi lớn hơn 50ms mới tạo ra blocking time và được đưa vào phép tính.
Ví dụ, một trang có ba Long Tasks với thời gian thực thi lần lượt là 80ms, 150ms và 60ms:
- Task 1: 80 ms → Blocking time = 30ms.
- Task 2: 150 ms → Blocking time = 100ms.
- Task 3: 60 ms → Blocking time = 10ms.
Khi đó: TBT = 30 + 100 + 10 = 140ms.
TBT sẽ cộng blocking time của tất cả Long Tasks được ghi nhận trong khoảng thời gian đo. Do đó, TBT càng cao cho thấy main thread càng dành nhiều thời gian xử lý các tác vụ dài, làm giảm khả năng phản hồi của website. Ngược lại, TBT thấp thường phản ánh khả năng xử lý tác vụ và đáp ứng tương tác tốt hơn.
Chỉ số này đặc biệt hữu ích khi phân tích những nguyên nhân khiến website khó phản hồi trong giai đoạn tải, chẳng hạn như JavaScript có dung lượng lớn, mã JavaScript thực thi phức tạp, script của bên thứ ba hoặc các tác vụ cần nhiều tài nguyên xử lý.

Tầm quan trọng của Total Blocking Time đối với website
TBT không chỉ phản ánh mức độ phản hồi của website trong quá trình tải trang mà còn cung cấp góc nhìn quan trọng về hiệu quả xử lý JavaScript trên main thread. Khi tổng thời gian chặn ở mức cao, các tác vụ dài có thể chiếm dụng tài nguyên xử lý và khiến trình duyệt chậm phản hồi trước tương tác của người dùng. Vì vậy, theo dõi và tối ưu TBT là một phần quan trọng trong quá trình cải thiện hiệu suất, khả năng tương tác và trải nghiệm tổng thể của website.
1. Chiếm trọng số lớn nhất trong điểm Google Lighthouse Performance
Total Blocking Time (TBT) từng là một trong những chỉ số có trọng số cao nhất trong cách Google Lighthouse tính điểm Performance, bởi nó phản ánh trực tiếp khả năng xử lý tác vụ và mức độ sẵn sàng tương tác của trang trong giai đoạn tải. Khác với các chỉ số tập trung vào thời điểm nội dung xuất hiện trên màn hình, TBT đánh giá khoảng thời gian main thread bị chặn bởi các Long Tasks, đặc biệt là những tác vụ JavaScript có thời gian thực thi kéo dài. Khi main thread liên tục bị chiếm dụng, trình duyệt sẽ khó xử lý đồng thời các thao tác như nhấp chuột, nhập liệu hoặc cuộn trang.
Trong cơ chế chấm điểm của Lighthouse, TBT được tính dựa trên tổng blocking time của các Long Tasks và được quy đổi thành một mức điểm tương ứng. TBT càng thấp thì điểm đánh giá càng tốt, trong khi TBT cao có thể kéo điểm Performance xuống đáng kể, ngay cả khi các nội dung chính của trang đã được hiển thị tương đối nhanh. Đây là lý do một website có tốc độ hiển thị nội dung tốt nhưng chứa nhiều JavaScript nặng vẫn có thể nhận điểm Performance thấp. Tuy nhiên, trọng số cụ thể của TBT không cố định và có thể thay đổi theo từng phiên bản Lighthouse, vì vậy khi phân tích cần dựa trên phiên bản công cụ đang sử dụng.
2. Tiền đề quyết định các chỉ số Core Web Vitals
Mặc dù Total Blocking Time không phải là một chỉ số thuộc nhóm Core Web Vitals, chỉ số này có mối liên hệ chặt chẽ với khả năng phản hồi và hiệu suất tương tác của website. TBT đo lường tổng thời gian main thread bị chặn bởi các Long Tasks trong quá trình tải trang, qua đó cho thấy mức độ JavaScript và các tác vụ nặng đang ảnh hưởng đến khả năng xử lý của trình duyệt. Khi TBT ở mức cao, main thread thường phải dành nhiều thời gian hoàn thành các tác vụ đang chờ, khiến trình duyệt khó sẵn sàng tiếp nhận và xử lý tương tác của người dùng.
Mối liên hệ này đặc biệt rõ ràng với INP (Interaction to Next Paint) - một trong các Core Web Vitals hiện tại dùng để đánh giá khả năng phản hồi của trang trước tương tác. Các Long Tasks kéo dài có thể làm trì hoãn thời điểm trình duyệt bắt đầu xử lý sự kiện, từ đó khiến thời gian phản hồi tương tác tăng lên. Vì vậy, giảm Total Blocking Time thông qua tối ưu JavaScript, chia nhỏ tác vụ dài và hạn chế công việc trên main thread có thể tạo điều kiện thuận lợi để cải thiện INP
3. Giảm tỷ lệ thoát trang và tăng trải nghiệm người dùng
TBT cao thường phản ánh tình trạng main thread phải xử lý quá nhiều tác vụ kéo dài, khiến website mất nhiều thời gian để sẵn sàng phản hồi tương tác. Trong thực tế, người dùng có thể gặp tình trạng nhấp vào nút nhưng không phản hồi ngay, thao tác cuộn bị giật hoặc biểu mẫu phản ứng chậm dù nội dung trang đã được hiển thị. Những độ trễ này làm gián đoạn trải nghiệm, đặc biệt trên các thiết bị có cấu hình thấp hoặc kết nối mạng không ổn định.
Tối ưu TBT giúp giảm khối lượng công việc cần thực hiện trên main thread, từ đó cho phép trình duyệt ưu tiên xử lý các tương tác quan trọng của người dùng. Khi website phản hồi nhanh và ổn định hơn, người dùng có xu hướng tiếp tục khám phá nội dung thay vì rời khỏi trang do phải chờ đợi. Điều này có thể góp phần giảm nguy cơ thoát trang và nâng cao mức độ hài lòng, đặc biệt đối với những website yêu cầu người dùng thực hiện nhiều thao tác liên tiếp.
4. Tác động trực tiếp đến tỷ lệ chuyển đổi
hoàn thành các hành động chuyển đổi như đăng ký, gửi biểu mẫu, đặt hàng, thêm sản phẩm vào giỏ hàng hoặc yêu cầu tư vấn. Khi TBT cao, các tác vụ JavaScript kéo dài có thể khiến những hành động này bị trì hoãn, đặc biệt trong giai đoạn người dùng vừa truy cập và bắt đầu tương tác với trang. Chỉ một khoảng thời gian chờ đợi ngắn nhưng lặp lại ở nhiều điểm chạm cũng có thể tạo ra sự gián đoạn trong hành trình chuyển đổi.
Ngược lại, khi TBT được tối ưu, main thread có thêm khả năng xử lý các sự kiện tương tác mà không phải chờ quá lâu để hoàn thành những tác vụ khác. Các nút CTA, biểu mẫu, bộ lọc sản phẩm, chức năng tìm kiếm hoặc quy trình thanh toán vì thế có thể mang lại cảm giác phản hồi nhanh và liền mạch hơn. Trải nghiệm tương tác tốt giúp giảm ma sát trong hành trình khách hàng, qua đó tạo điều kiện thuận lợi để người dùng hoàn thành hành động có giá trị đối với doanh nghiệp.
5. Hỗ trợ gián tiếp cho chiến dịch SEO
Total Blocking Time không phải là một yếu tố xếp hạng độc lập của Google. Tuy nhiên, chỉ số này vẫn có giá trị trong quá trình tối ưu SEO kỹ thuật vì TBT cao thường cho thấy website đang phải xử lý quá nhiều JavaScript hoặc các tác vụ kéo dài trên main thread. Những vấn đề này có thể ảnh hưởng đến khả năng tương tác, tốc độ phản hồi và trải nghiệm người dùng, từ đó làm giảm chất lượng trải nghiệm trên trang.
Tối ưu TBT thường đi kèm với việc giảm JavaScript không cần thiết, loại bỏ script dư thừa, tối ưu mã nguồn và phân bổ tài nguyên hiệu quả hơn. Những cải thiện này không chỉ giúp main thread hoạt động nhẹ hơn mà còn hỗ trợ website đạt hiệu suất tổng thể tốt hơn. Khi kết hợp với việc tối ưu LCP, INP, CLS và các yếu tố kỹ thuật khác, website có thể đáp ứng tốt hơn các yêu cầu về Page Experience và tạo nền tảng thuận lợi cho quá trình triển khai SEO dài hạn.

Thang điểm đánh giá chỉ số Total Blocking Time
Total Blocking Time được sử dụng để đánh giá mức độ main thread bị trì hoãn bởi các tác vụ dài trong quá trình tải trang. Đối chiếu TBT với các ngưỡng đánh giá giúp xác định website đang có hiệu suất xử lý JavaScript tốt, cần cải thiện hay đang gặp vấn đề nghiêm trọng. Dựa trên mức TBT, lập trình viên có thể ưu tiên các hoạt động tối ưu phù hợp nhằm giảm thời gian blocking và cải thiện khả năng phản hồi của trang.
1. Bảng tiêu chuẩn đánh giá chỉ số TBT từ Google
Theo tiêu chuẩn được sử dụng trong Google Lighthouse, TBT được phân thành ba mức dựa trên tổng thời gian main thread bị blocking. Chỉ số càng thấp càng tốt, bởi điều này cho thấy trình duyệt ít phải dành thời gian xử lý các Long Tasks và có nhiều khả năng phản hồi tương tác của người dùng hơn.
| Mức đánh giá | Total Blocking Time (TBT) | Ý nghĩa |
| Tốt (Good) | ≤ 200 ms | Main thread ít bị chặn, website có khả năng phản hồi tốt. |
| Cần cải thiện (Needs Improvement) | 200 – 600 ms | Xuất hiện một lượng đáng kể tác vụ gây blocking, cần tối ưu. |
| Kém (Poor) | > 600 ms | Main thread bị chặn đáng kể, có nguy cơ ảnh hưởng đến khả năng tương tác. |
Với mục tiêu tối ưu hiệu suất, website nên duy trì TBT ở mức 200 ms hoặc thấp hơn trong môi trường kiểm thử Lighthouse. TBT vượt quá 600 ms thường là dấu hiệu cần kiểm tra kỹ các tác vụ JavaScript kéo dài, script bên thứ ba và những công việc đang chiếm dụng main thread. Tuy nhiên, các ngưỡng này chủ yếu phục vụ đánh giá hiệu suất trong Lighthouse, không nên được xem là tiêu chuẩn trực tiếp để xác định trải nghiệm người dùng thực tế trên mọi thiết bị và điều kiện mạng.
2. Sự khác biệt về TBT trên mobile vs desktop
Total Blocking Time có thể có sự chênh lệch đáng kể giữa mobile và desktop do hai môi trường kiểm thử có sự khác nhau về năng lực xử lý phần cứng, cấu hình trình duyệt và điều kiện mô phỏng. Trong Lighthouse, môi trường mobile thường sử dụng cấu hình CPU yếu hơn để mô phỏng thiết bị di động phổ biến, khiến các tác vụ JavaScript mất nhiều thời gian xử lý hơn. Vì vậy, cùng một website nhưng TBT trên mobile thường có xu hướng cao hơn so với desktop.
Trên mobile, CPU và tài nguyên hệ thống thường hạn chế hơn, trong khi website hiện đại có thể phải thực thi nhiều JavaScript cho menu, animation, tracking, quảng cáo, biểu mẫu hoặc các chức năng tương tác khác. Một tác vụ chỉ mất khoảng 60 - 80 ms trên desktop có thể kéo dài đáng kể khi được xử lý trên thiết bị có năng lực thấp hơn, từ đó làm tăng blocking time. Đây cũng là lý do khi tối ưu hiệu suất, không nên chỉ dựa vào kết quả desktop mà cần đặc biệt quan tâm đến kết quả mobile.
| Tiêu chí | Mobile | Desktop |
| Năng lực CPU | Thường thấp hơn. | Thường cao hơn. |
| Thời gian thực thi JavaScript | Có xu hướng dài hơn. | Thường ngắn hơn. |
| TBT | Dễ cao hơn. | Thường thấp hơn. |
| Mức độ ảnh hưởng của JavaScript | Cao. | Thấp hơn tương đối. |
| Ưu tiên tối ưu | Rất cao. | Cao. |
Do đó, TBT trên mobile thường là thước đo khắt khe hơn đối với hiệu suất JavaScript. Nếu website đạt TBT tốt trên desktop nhưng kết quả mobile vẫn cao, nên kiểm tra các Long Tasks, JavaScript không cần thiết, script bên thứ ba và những tác vụ có thể trì hoãn hoặc chia nhỏ. Tối ưu theo hướng mobile-first không chỉ giúp cải thiện điểm Lighthouse mà còn mang lại trải nghiệm tương tác ổn định hơn cho nhóm người dùng sử dụng thiết bị di động.
Phân biệt Total Blocking Time với các chỉ số website khác
Total Blocking Time không phản ánh toàn bộ khía cạnh về tốc độ và trải nghiệm của một website mà tập trung vào thời gian main thread bị chặn bởi các tác vụ dài. Trong khi đó, mỗi chỉ số hiệu suất như LCP, INP, CLS hay FCP lại đo lường một khía cạnh khác nhau, từ tốc độ hiển thị nội dung, khả năng phản hồi đến mức độ ổn định của giao diện. Phân biệt rõ TBT với các chỉ số này giúp xác định chính xác vấn đề mà website đang gặp phải và lựa chọn phương án tối ưu phù hợp, thay vì chỉ tập trung cải thiện một chỉ số riêng lẻ.
| Tiêu chí | TBT | LCP | INP | CLS | FCP | TTFB |
| Tên đầy đủ | Total Blocking Time. | Largest Contentful Paint. | Interaction to Next Paint. | Cumulative Layout Shift. | First Contentful Paint. | Time to First Byte |
| Đo lường | Thời gian main thread bị chặn bởi Long Tasks. | Thời gian hiển thị nội dung lớn nhất. | Khả năng phản hồi trước tương tác. | Mức độ ổn định của bố cục. | Thời gian hiển thị nội dung đầu tiên. | Thời gian nhận byte dữ liệu đầu tiên. |
| Đơn vị | ms | giây | ms | điểm | giây | ms |
| Ngưỡng tốt | ≤ 200 ms. | ≤ 2,5 giây. | ≤ 200 ms. | ≤ 0,1. | ≤ 1,8 giây. | ≤ 800 ms. |
| Trọng tâm | Xử lý tác vụ trên main thread. | Tốc độ hiển thị nội dung chính. | Khả năng phản hồi tương tác. | Độ ổn định giao diện. | Tốc độ hiển thị nội dung đầu tiên. | Khả năng phản hồi của máy chủ. |
| Khác biệt với TBT | — | Đo tốc độ hiển thị thay vì thời gian blocking. | Đo phản hồi tương tác thay vì blocking trong quá trình tải. | Đo sự ổn định bố cục. | Đo thời điểm nội dung đầu tiên xuất hiện. | Đo thời gian phản hồi từ máy chủ. |
Nguyên nhân chính khiến chỉ số Total Blocking Time tăng cao
Total Blocking Time tăng cao khi main thread phải dành quá nhiều thời gian để xử lý các tác vụ kéo dài, khiến trình duyệt không thể phản hồi kịp thời các yêu cầu từ người dùng. Nguyên nhân thường xuất phát từ JavaScript có khối lượng lớn, mã nguồn thực thi chưa tối ưu, script bên thứ ba hoặc quá nhiều tác vụ được thực hiện đồng thời trong quá trình tải trang.
1. Dung lượng và thời gian thực thi JavaScript quá lớn
JavaScript có dung lượng lớn và thời gian thực thi kéo dài là một trong những nguyên nhân phổ biến khiến tổng thời gian chặn tăng cao. Khi trình duyệt tải và phân tích một lượng lớn JavaScript, main thread phải dành nhiều tài nguyên cho các hoạt động như parsing, compiling và execution trước khi có thể xử lý đầy đủ các tác vụ khác. Nếu các đoạn mã này tạo ra nhiều Long Tasks vượt quá 50 ms, phần thời gian vượt ngưỡng sẽ được cộng vào chỉ số TBT.
Vấn đề không chỉ nằm ở kích thước tệp JavaScript mà còn ở khối lượng công việc mà mã nguồn phải thực hiện sau khi được tải xuống. Một tệp có dung lượng không quá lớn vẫn có thể gây TBT cao nếu chứa các thuật toán phức tạp, xử lý DOM lớn, nhiều event listener hoặc thực hiện quá nhiều thao tác đồng bộ trên main thread. Ngược lại, giảm dung lượng JavaScript nhưng không giảm thời gian thực thi chưa chắc mang lại sự cải thiện đáng kể về TBT.
2. Sự xuất hiện của các tác vụ kéo dài (Long Tasks > 50ms)
Long Task là những tác vụ được thực thi trên main thread trong thời gian dài hơn 50 ms, khiến trình duyệt tạm thời không thể xử lý các công việc khác một cách kịp thời. Khi một tác vụ vượt qua mốc 50ms, phần thời gian vượt quá ngưỡng này được xem là blocking time và được cộng vào tổng chỉ số Total Blocking Time. Vì vậy, website càng xuất hiện nhiều Long Tasks hoặc các tác vụ có thời gian thực thi càng dài thì TBT càng có xu hướng tăng cao.
Các Long Tasks thường phát sinh khi JavaScript phải thực hiện khối lượng xử lý lớn trong một lần, chẳng hạn như tính toán phức tạp, thao tác trên DOM với số lượng lớn phần tử, xử lý dữ liệu hoặc thực thi nhiều hàm JavaScript liên tiếp. Những tác vụ này chiếm dụng main thread và khiến trình duyệt phải trì hoãn các công việc như xử lý thao tác nhấp chuột, nhập liệu, cuộn trang hoặc cập nhật giao diện. Đặc biệt, trên các thiết bị có năng lực xử lý thấp, cùng một đoạn JavaScript có thể mất nhiều thời gian hơn để hoàn thành và tạo ra mức TBT cao hơn.
3. Lạm dụng và quản lý kém các Script bên thứ ba
Các Script bên thứ ba (Third-party Scripts) như công cụ phân tích dữ liệu, quảng cáo, chatbot, bản đồ hoặc hệ thống theo dõi hành vi có thể tạo thêm nhiều công việc cho main thread. Khi website tích hợp quá nhiều script hoặc tải chúng không đúng cách, trình duyệt phải dành thêm thời gian để tải, phân tích, biên dịch và thực thi JavaScript, từ đó làm tăng nguy cơ xuất hiện các Long Tasks. Phần thời gian xử lý vượt quá 50 ms của những tác vụ này sẽ được tính vào TBT.
Vấn đề thường không nằm ở sử dụng một script bên thứ ba đơn lẻ mà ở số lượng, cách triển khai và thời điểm tải các script. Chẳng hạn, tải đồng thời nhiều công cụ tracking, quảng cáo và widget ngay khi trang bắt đầu hiển thị có thể khiến main thread bị chiếm dụng trong thời gian dài. Một số script còn tiếp tục thực hiện các tác vụ nền hoặc đăng ký nhiều event listener, làm gia tăng khối lượng công việc mà trình duyệt phải xử lý.
4. Nạp tài nguyên không sử dụng ở lần tải đầu
Nạp quá nhiều tài nguyên không cần thiết trong lần tải đầu có thể làm tăng khối lượng công việc mà trình duyệt phải xử lý trên main thread, đặc biệt khi các tài nguyên này đi kèm JavaScript cần được phân tích, biên dịch và thực thi. Website có thể tải trước nhiều module, thư viện, component hoặc đoạn mã chỉ được sử dụng ở những trang hay thao tác nhất định. Khi lượng JavaScript phải xử lý tăng lên, thời gian main thread bị chiếm dụng cũng kéo dài và làm TBT tăng.
Tình trạng này thường xuất hiện ở các website có bundle JavaScript lớn, SPA hoặc những trang tích hợp nhiều tính năng nhưng không áp dụng cơ chế tải tài nguyên theo nhu cầu. Ví dụ, một trang sản phẩm thương mại điện tử chỉ cần hiển thị hình ảnh, tên sản phẩm, giá bán và nút “Thêm vào giỏ hàng” khi người dùng vừa truy cập. Tuy nhiên, website lại tải ngay toàn bộ JavaScript phục vụ cho bộ lọc sản phẩm, biểu đồ thống kê, bản đồ cửa hàng, popup khuyến mãi và hệ thống đánh giá dù người dùng chưa sử dụng các tính năng này. Lượng mã JavaScript dư thừa khiến trình duyệt phải thực hiện thêm nhiều công việc trên main thread, làm tăng nguy cơ xuất hiện Long Tasks và khiến TBT cao hơn.
5. Cấu trúc DOM quá lớn và thao tác rendering phức tạp
DOM (Document Object Model) có kích thước lớn hoặc cấu trúc quá phức tạp có thể làm tăng khối lượng công việc mà trình duyệt phải thực hiện trên main thread. Khi một trang chứa quá nhiều phần tử HTML, nhiều cấp độ lồng nhau hoặc thường xuyên thay đổi cấu trúc DOM, trình duyệt phải thực hiện thêm các bước style calculation, layout và rendering để cập nhật giao diện. Nếu những công việc này kéo dài và tạo thành Long Tasks, phần thời gian vượt quá 50 ms sẽ được tính vào TBT.
Tình trạng này thường gặp ở các trang có danh sách sản phẩm dài, bảng dữ liệu lớn, nhiều component tương tác hoặc giao diện được xây dựng với cấu trúc HTML phức tạp. Chẳng hạn, một trang thương mại điện tử có thể hiển thị hàng trăm sản phẩm cùng lúc, mỗi sản phẩm lại chứa nhiều phần tử con như hình ảnh, thông tin, nút chức năng, đánh giá và bộ lọc. Khi người dùng tương tác hoặc JavaScript liên tục cập nhật các phần tử này, trình duyệt phải tính toán lại layout và rendering nhiều lần, làm tăng thời gian main thread bị chiếm dụng.

5 kỹ thuật tối ưu chỉ số Total Blocking Time hiệu quả nhất cho website
Tối ưu chỉ số Total Blocking Time tập trung vào giảm thời gian main thread bị chiếm dụng bởi các tác vụ JavaScript kéo dài trong quá trình tải trang. Thay vì chỉ giảm dung lượng tài nguyên, website cần kiểm soát cách JavaScript được tải, thực thi và phân bổ công việc để trình duyệt có thể nhanh chóng xử lý các tương tác của người dùng. Dưới đây là 5 kỹ thuật quan trọng giúp giảm tổng thời gian chặn và cải thiện khả năng phản hồi của website.
1. Chia nhỏ Long Tasks
Chia nhỏ Long Tasks là một trong những kỹ thuật trực tiếp và hiệu quả để giảm TBT. Thay vì để một tác vụ JavaScript thực hiện liên tục trong hàng trăm mili giây, có thể tách công việc thành nhiều tác vụ nhỏ hơn để main thread có thời gian xử lý các công việc ưu tiên ở giữa. Khi thời lượng mỗi tác vụ được rút ngắn, phần thời gian vượt quá ngưỡng 50 ms giảm xuống, từ đó góp phần hạ tổng TBT.
Về mặt triển khai, có thể sử dụng setTimeout(), requestIdleCallback() hoặc chia nhỏ vòng lặp để phân tách các công việc dài thành nhiều lượt xử lý. Với những tác vụ tính toán nặng, Web Workers có thể được sử dụng để chuyển phần xử lý sang worker thread, qua đó giảm áp lực lên main thread. Mục tiêu không chỉ là rút ngắn tổng thời gian thực thi mà quan trọng hơn là tránh để main thread bị chiếm dụng liên tục bởi một tác vụ quá dài.
Ví dụ:
function processBatch (items, start = 0) {
const batchSize = 100;
const end = Math. min(start + batchSize, items.length);
for (let i = start; i < end; i++) {
processItem(items[i]);
}
if (end < items.length) {
setTimeout(() => processBatch(items, end), 0);
}
}
processBatch(items);
Trong ví dụ trên, JavaScript chỉ xử lý 100 phần tử mỗi lượt thay vì toàn bộ danh sách cùng lúc. Sau mỗi batch, setTimeout() đưa phần xử lý tiếp theo sang một lượt event loop khác, tạo khoảng thời gian để trình duyệt xử lý các tác vụ ưu tiên. Nhờ đó, một tác vụ JavaScript quá dài được phân tách thành nhiều phần nhỏ hơn, giúp hạn chế Long Tasks và cải thiện khả năng phản hồi của website.
2. Tối ưu hóa tệp và thực thi JavaScript
JavaScript là một trong những yếu tố ảnh hưởng trực tiếp đến TBT vì trình duyệt phải thực hiện nhiều bước như download, parsing, compilation và execution trước khi hoàn tất xử lý mã. Khi tệp JavaScript quá lớn hoặc chứa nhiều đoạn mã không cần thiết, main thread phải dành nhiều thời gian hơn để xử lý, làm tăng nguy cơ xuất hiện Long Tasks. Vì vậy, tối ưu JavaScript cần tập trung đồng thời vào giảm lượng mã phải tải và giảm thời gian thực thi.
Có thể áp dụng các kỹ thuật sau:
- Loại bỏ JavaScript không sử dụng: Xóa các đoạn mã, thư viện hoặc module không cần thiết để giảm khối lượng JavaScript phải xử lý.
- Sử dụng tree shaking: Loại bỏ những phần mã không được sử dụng trong quá trình build, đặc biệt hữu ích với các thư viện JavaScript lớn.
- Minification: Rút gọn mã nguồn bằng cách loại bỏ khoảng trắng, chú thích và các ký tự không cần thiết để giảm kích thước tệp.
- Code splitting: Chia bundle JavaScript lớn thành nhiều phần nhỏ, chỉ tải những module cần thiết cho từng trang hoặc tính năng.
- Dynamic import và lazy loading: Trì hoãn việc tải các module chưa cần thiết cho đến khi người dùng thực sự sử dụng chức năng tương ứng.
- Sử dụng defer: Với các script không cần thực thi ngay trong quá trình phân tích HTML, defer giúp trì hoãn việc thực thi cho đến khi HTML được phân tích xong.
- Tối ưu logic JavaScript: Cải thiện thuật toán, giảm các phép tính dư thừa và hạn chế thao tác DOM liên tục để rút ngắn thời gian thực thi.

3. Chuyển đổi tác vụ nặng sang web workers
Web Workers cho phép JavaScript thực hiện một số tác vụ trên một luồng riêng thay vì xử lý trực tiếp trên main thread. Đây là kỹ thuật hữu ích với những công việc có khối lượng tính toán lớn, bởi main thread có thể tiếp tục đảm nhiệm rendering và phản hồi tương tác của người dùng. Khi giảm được lượng công việc nặng trên main thread, website có thể hạn chế các Long Tasks và cải thiện chỉ số TBT.
Web Workers đặc biệt phù hợp với những tác vụ không yêu cầu thao tác trực tiếp với DOM, chẳng hạn:
- Xử lý dữ liệu lớn: Phân tích, lọc, sắp xếp hoặc chuyển đổi hàng nghìn bản ghi.
- Tính toán phức tạp: Thực hiện các phép tính toán học, thống kê hoặc xử lý thuật toán với khối lượng lớn.
- Xử lý văn bản: Phân tích, tìm kiếm hoặc chuyển đổi nội dung có kích thước lớn.
- Xử lý dữ liệu JSON: Parse hoặc biến đổi các tập dữ liệu lớn trước khi đưa kết quả lên giao diện.
- Xử lý hình ảnh và dữ liệu đồ họa: Thực hiện một số công việc xử lý dữ liệu hình ảnh mà không cần truy cập trực tiếp vào DOM.
Ví dụ, thay vì xử lý trực tiếp một tập dữ liệu lớn trên main thread, website có thể tạo một Worker và gửi dữ liệu sang luồng này:
// main. js
const worker = new Worker("worker.js");
worker. postMessage(largeData);
worker. onmessage = (event) => {
renderResult(event.data);
};
Phần xử lý có thể được thực hiện trong Worker:
// worker. js
self.onmessage = (event) => {
const result = processLargeData(event.data);
self.postMessage(result);
};
Trong trường hợp này, main thread không phải thực hiện toàn bộ quá trình xử lý dữ liệu nặng mà chỉ gửi dữ liệu cho Worker và nhận kết quả trả về. Điều này giúp giảm nguy cơ một tác vụ JavaScript kéo dài làm chặn rendering hoặc phản hồi tương tác.
4. Kiểm soát và nạp muộn các script bên thứ ba
Script bên thứ ba (Third-party Scripts) như Google Analytics, công cụ quảng cáo, chatbot, bản đồ hoặc widget mạng xã hội có thể tạo thêm nhiều tác vụ JavaScript trên main thread. Nếu các script này được tải và thực thi ngay khi trang bắt đầu mở, chúng có thể cạnh tranh tài nguyên với mã nguồn chính và làm phát sinh Long Tasks. Vì vậy, kiểm soát số lượng và thời điểm thực thi script bên thứ ba là một trong những cách hiệu quả để giảm TBT.
Có thể áp dụng các phương pháp sau:
- Loại bỏ script không cần thiết: Kiểm tra toàn bộ script đang được tích hợp và xóa những công cụ không còn sử dụng hoặc có mức độ đóng góp thấp.
- Ưu tiên script quan trọng: Chỉ tải ngay những script thực sự cần thiết cho chức năng hoặc nội dung ban đầu của trang.
- Sử dụng async và defer: Với các script không cần thực thi ngay, sử dụng thuộc tính phù hợp để hạn chế việc chúng làm gián đoạn quá trình phân tích HTML.
- Lazy-load script: Chỉ tải script khi người dùng thực sự cần đến chức năng tương ứng, chẳng hạn chatbot khi người dùng mở cửa sổ hỗ trợ hoặc bản đồ khi người dùng cuộn đến khu vực bản đồ.
- Trì hoãn script không quan trọng: Các công cụ tracking, quảng cáo hoặc widget không cần thiết ngay khi trang hiển thị có thể được khởi chạy sau khi nội dung chính đã tải và giao diện đã sẵn sàng tương tác.
- Giới hạn số lượng nhà cung cấp: Tránh tích hợp nhiều công cụ có chức năng tương tự, vì mỗi nhà cung cấp có thể kéo theo thêm JavaScript, request và các tác vụ xử lý riêng.
5. Giảm kích thước DOM và tối ưu hóa Rendering
DOM quá lớn và cấu trúc HTML phức tạp khiến trình duyệt phải xử lý nhiều phần tử hơn trong quá trình tính toán style, layout và rendering. Khi JavaScript liên tục thay đổi các phần tử này, trình duyệt có thể phải thực hiện lại quá trình tính toán và cập nhật giao diện, làm tăng khối lượng công việc trên main thread. Vì vậy, giảm kích thước DOM và hạn chế các thao tác rendering không cần thiết có thể giúp giảm Long Tasks và cải thiện TBT.
Có thể áp dụng các kỹ thuật sau:
- Giảm số lượng DOM node: Loại bỏ các phần tử HTML không cần thiết và tránh xây dựng cấu trúc lồng nhau quá sâu.
- Đơn giản hóa cấu trúc HTML: Hạn chế các wrapper hoặc container chỉ được sử dụng để phục vụ bố cục nhưng không mang lại giá trị cần thiết.
- Sử dụng virtualization: Với danh sách hoặc bảng có hàng trăm, hàng nghìn phần tử, chỉ render những phần tử đang nằm trong vùng nhìn thấy thay vì tạo toàn bộ DOM ngay từ đầu.
- Hạn chế thay đổi DOM liên tục: Gom nhiều thay đổi thành một lần cập nhật thay vì thực hiện từng thao tác riêng lẻ.
- Tránh Layout Thrashing: Không liên tục đọc các thuộc tính layout như offsetHeight, offsetWidth rồi ngay lập tức thay đổi style, vì điều này có thể buộc trình duyệt thực hiện lại layout.
- Tối ưu animation: Ưu tiên các thuộc tính như transform và opacity cho animation để hạn chế việc kích hoạt lại layout và giảm áp lực rendering.

Top công cụ kiểm tra và đo lường chỉ số TBT chính xác nhất
Để đánh giá và tối ưu Total Blocking Time (TBT), cần sử dụng các công cụ có khả năng phân tích hoạt động của main thread và xác định những tác vụ JavaScript gây blocking. Mỗi công cụ có cách đo lường và mức độ chi tiết khác nhau, từ kiểm tra nhanh trực tiếp trên trình duyệt đến phân tích chuyên sâu hiệu suất tải trang. Ba công cụ phổ biến dưới đây có thể hỗ trợ phát hiện Long Tasks và xác định nguyên nhân khiến TBT tăng cao.
1. Google Lighthouse (Chrome DevTools)
Google Lighthouse là công cụ kiểm tra hiệu suất được tích hợp trực tiếp trong Chrome DevTools, cho phép phân tích hoạt động của trình duyệt trong quá trình tải và hiển thị một trang web. Khi chạy Lighthouse, công cụ mô phỏng quá trình tải trang trong một điều kiện thiết bị và mạng nhất định, sau đó đánh giá nhiều yếu tố liên quan đến hiệu suất, trong đó có Total Blocking Time. Người dùng có thể mở Chrome DevTools bằng phím F12 hoặc Ctrl + Shift + I, chọn tab Lighthouse, thiết lập chế độ kiểm tra phù hợp rồi tiến hành phân tích trang.
Sau khi hoàn tất, Lighthouse cung cấp báo cáo Performance cùng các thông tin liên quan đến TBT và hoạt động của main thread. Nếu TBT cao, bạn có thể tiếp tục kiểm tra các Long Tasks, JavaScript và những tác vụ chiếm nhiều thời gian xử lý để xác định nguyên nhân. Đây là lựa chọn phù hợp khi cần kiểm tra nhanh hiệu suất của một trang ngay trong môi trường trình duyệt và đánh giá tác động của các thay đổi trong quá trình tối ưu website.

2. Google PageSpeed Insights
Google PageSpeed Insights (PSI) là công cụ trực tuyến của Google giúp đánh giá hiệu suất website thông qua cả dữ liệu phòng thí nghiệm và dữ liệu người dùng thực tế khi có sẵn. Để kiểm tra, người dùng chỉ cần nhập URL của trang web vào PageSpeed Insights và bắt đầu phân tích. Trong phần Performance, công cụ cung cấp các chỉ số liên quan đến quá trình tải trang và khả năng xử lý của trình duyệt, trong đó TBT được sử dụng như một chỉ số Lab để đánh giá mức độ main thread bị chặn.
Điểm cần lưu ý là TBT không phải Core Web Vital và không được đo trực tiếp từ dữ liệu người dùng thực tế như INP. Vì vậy, khi sử dụng PageSpeed Insights, TBT nên được xem như một chỉ báo giúp phát hiện các vấn đề trong môi trường kiểm thử, đặc biệt là những vấn đề liên quan đến JavaScript và Long Tasks.
3. WebPageTest
WebPageTest là công cụ kiểm tra hiệu suất chuyên sâu, phù hợp khi cần phân tích chi tiết nguyên nhân khiến TBT tăng cao thay vì chỉ xem một giá trị tổng hợp. Công cụ cho phép thiết lập nhiều điều kiện kiểm thử như thiết bị, trình duyệt, vị trí máy chủ, tốc độ mạng và mức độ giới hạn CPU. Nhờ đó, có thể quan sát cách website hoạt động trong những môi trường khác nhau và đánh giá tác động của JavaScript đối với main thread.
Bên cạnh TBT, WebPageTest cung cấp waterfall, filmstrip, biểu đồ hoạt động của CPU và thông tin về Long Tasks, giúp xác định thời điểm trình duyệt bị chiếm dụng và những tài nguyên hoặc đoạn mã liên quan. Đây là lựa chọn hữu ích khi website có cấu trúc phức tạp, nhiều JavaScript hoặc script bên thứ ba và cần phân tích sâu để tìm ra nguyên nhân gốc rễ của vấn đề hiệu suất.

Một số lưu ý quan trọng khi tối ưu Total Blocking Time
Tối ưu Total Blocking Time (TBT) không chỉ đơn giản là giảm thời gian thực thi JavaScript mà cần xem xét tổng thể quá trình tải và xử lý trang web. Một số thay đổi có thể giúp TBT giảm nhưng đồng thời làm chậm thời điểm hiển thị giao diện hoặc ảnh hưởng đến các chỉ số hiệu suất khác. Vì vậy, quá trình tối ưu cần được thực hiện dựa trên sự cân bằng giữa khả năng phản hồi của main thread, tốc độ hiển thị và trải nghiệm thực tế của người dùng. Dưới đây là một số lưu ý quan trọng khi tối ưu Total Blocking Time:
- Cân bằng giữa tổng thời gian chặn và tốc độ hiển thị giao diện ban đầu: Giảm TBT không đồng nghĩa với việc trì hoãn toàn bộ JavaScript, bởi một số mã vẫn cần thiết để hiển thị và vận hành giao diện ban đầu. Vì vậy, nên ưu tiên các tài nguyên quan trọng cho lần tải đầu, đồng thời trì hoãn hoặc tải muộn những mã chưa cần thiết. Cách phân bổ này giúp giảm áp lực lên main thread mà không làm ảnh hưởng đến tốc độ hiển thị nội dung.
- TBT là dữ liệu phòng lab, không phải chỉ số đo trải nghiệm người dùng thực: TBT được đo trong môi trường Lab với cấu hình thiết bị, CPU và mạng được mô phỏng, nên không phản ánh trực tiếp trải nghiệm của toàn bộ người dùng thực tế. Do đó, TBT nên được kết hợp với Field Data và các Core Web Vitals như LCP, INP, CLS để đánh giá hiệu suất toàn diện hơn. Đặc biệt, INP giúp phản ánh khả năng phản hồi của website trước tương tác thực tế.
- Tự động hóa quá trình giám sát chỉ số TBT trong quy trình phát triển: TBT có thể thay đổi khi website bổ sung tính năng, thư viện hoặc JavaScript mới. Vì vậy, nên tích hợp kiểm thử hiệu suất vào quy trình CI/CD để tự động theo dõi TBT sau mỗi lần cập nhật mã nguồn. Thiết lập ngưỡng cảnh báo giúp phát hiện sớm những thay đổi làm gia tăng thời gian main thread bị chặn.
- Chú trọng cấu hình thiết bị và môi trường kiểm thử: Kết quả TBT có thể khác nhau tùy thuộc vào CPU, thiết bị, trình duyệt và điều kiện mạng được sử dụng khi kiểm tra. Để so sánh kết quả chính xác, nên duy trì môi trường kiểm thử tương đối nhất quán và thực hiện nhiều lần thay vì chỉ dựa trên một lần đo. Điều này giúp đánh giá đúng xu hướng thay đổi của TBT sau mỗi lần tối ưu.

Câu hỏi thường gặp về chỉ số Total Blocking Time
Total Blocking Time là chỉ số giúp đánh giá mức độ main thread bị bận trong quá trình tải trang. Dưới đây là một số câu hỏi thường gặp giúp bạn hiểu rõ hơn về TBT và cách đánh giá chỉ số này.
1. Tại sao chỉ số TBT trên desktop tốt nhưng trên mobile lại rất cao?
TBT trên mobile thường cao hơn desktop vì thiết bị di động có CPU và khả năng xử lý thấp hơn máy tính. Khi phải xử lý cùng một lượng JavaScript, điện thoại có thể mất nhiều thời gian hơn, khiến main thread bị chặn lâu hơn. Ngoài ra, các công cụ như Lighthouse thường sử dụng cấu hình mô phỏng thiết bị và CPU để đánh giá hiệu suất mobile. Đây là lý do cùng một website có thể đạt TBT tốt trên desktop nhưng lại có kết quả kém hơn đáng kể trên mobile.
2. Total Blocking Time có phải là một chỉ số Core Web Vitals không?
Không. TBT không phải là một trong ba chỉ số Core Web Vitals hiện tại. Ba chỉ số này gồm LCP để đo tốc độ hiển thị nội dung chính, INP để đánh giá khả năng phản hồi khi người dùng tương tác và CLS để đo độ ổn định của bố cục. Tuy nhiên, TBT vẫn rất hữu ích để phát hiện các vấn đề JavaScript và Long Tasks có thể ảnh hưởng đến khả năng phản hồi của website. Vì vậy, TBT thường được sử dụng như một chỉ số hỗ trợ trong quá trình tối ưu hiệu suất, đặc biệt khi phân tích nguyên nhân khiến INP kém.
3. Chỉ số Total Blocking Time thấp có đồng nghĩa website hoạt động nhanh không?
Không hoàn toàn. Chỉ số TBT thấp cho thấy main thread ít bị chặn và website có khả năng phản hồi tốt hơn, nhưng đây chỉ là một khía cạnh của hiệu suất. Website vẫn có thể tải nội dung chậm, phản hồi máy chủ lâu hoặc xảy ra hiện tượng bố cục thay đổi dù Total Blocking Time ở mức tốt. Vì vậy, bạn nên đánh giá TBT cùng với LCP, INP, CLS và các chỉ số hiệu suất khác để có kết luận chính xác. Một website có hiệu suất tốt cần đảm bảo cả tốc độ tải, khả năng phản hồi và sự ổn định của giao diện.

Qua bài viết của Phương Nam Vina, có thể thấy Total Blocking Time là chỉ số quan trọng giúp đánh giá mức độ main thread bị chặn bởi các tác vụ JavaScript kéo dài trong quá trình tải trang. Thông qua theo dõi TBT, doanh nghiệp và đội ngũ phát triển có thể phát hiện các vấn đề liên quan đến JavaScript, Long Tasks, script bên thứ ba và hoạt động rendering, từ đó đưa ra hướng tối ưu phù hợp. Tuy nhiên, TBT chỉ là một phần trong bức tranh tổng thể về hiệu suất website và không phải Core Web Vital. Để xây dựng website có tốc độ tốt và trải nghiệm mượt mà, cần kết hợp TBT với LCP, INP, CLS cùng dữ liệu người dùng thực tế. Theo dõi và tối ưu các chỉ số này thường xuyên sẽ giúp website hoạt động ổn định hơn, cải thiện trải nghiệm người dùng và tạo nền tảng tốt cho hiệu quả SEO lâu dài.
Tham khảo thêm:
Giải mã các chỉ số đánh giá website quan trọng hàng đầu
NPS là gì? Cách đo lường và chiến thuật cải thiện chỉ số NPS
TTFB là gì? Yếu tố ảnh hưởng và cách tối ưu Time To First Byte
