Total Blocking Time là gì? Cách hiểu đúng chỉ số TBT trong Lighthouse

Total Blocking Time là gì?

Total Blocking Time (TBT) là chỉ số đo tổng thời gian mà luồng chính của trình duyệt bị chặn trong giai đoạn tải trang, khiến website không thể phản hồi kịp với thao tác của người dùng. Trong Lighthouse, TBT thường được đo từ FCP đến TTI và chỉ cộng phần thời gian vượt quá 50ms của các long tasks.

Nói đơn giản, nếu website đã hiện giao diện nhưng vẫn “bận” xử lý script nên chưa phản hồi tốt khi người dùng bấm vào nút, menu hoặc form, thì chỉ số này sẽ tăng. Vì vậy, cách hiểu dễ nhất về Total Blocking Time là: Đây là thước đo khả năng phản hồi khi tải.

Trong ngữ cảnh Lighthouse, PageSpeed Insights và tài liệu từ web.dev, TBT được xem là một lab metric. Nghĩa là nó được đo trong môi trường mô phỏng, không phải dữ liệu tương tác thực tế của toàn bộ người dùng ngoài thị trường.

TBT đo điều gì trên thực tế?

TBT đo mức độ website có thể phản hồi thao tác trong lúc đang tải, chứ không chỉ đo việc nội dung đã xuất hiện trên màn hình hay chưa. Một trang có thể hiện rất nhanh phần đầu, nhưng nếu main thread vẫn bận xử lý, người dùng vẫn cảm thấy bấm không “ăn”.

Hiểu ngắn gọn: TBT không đo “trang đã hiện chưa”, mà đo “trang có sẵn sàng phản hồi khi người dùng muốn thao tác hay chưa”.

Long Task là gì?

Long Task là một tác vụ chạy trên main thread kéo dài hơn 50ms. Trong cách tính TBT, chỉ phần thời gian vượt quá 50ms mới được cộng vào chỉ số này. Ví dụ, một tác vụ mất 120ms thì phần tính vào TBT là 70ms, không phải toàn bộ 120ms. Đây là lý do các long tasks thường được xem là dấu hiệu cho thấy trình duyệt đang bị nghẽn trong lúc tải.

Cách Total Blocking Time hoạt động và cách tính đơn giản

Cách tính TBT khá dễ hiểu nếu nhìn theo từng bước. Trước hết, công cụ sẽ quan sát khoảng thời gian từ FCP (First Contentful Paint - thời điểm nội dung đầu tiên xuất hiện) đến TTI (Time to Interactive - thời điểm trang đạt mức có thể tương tác ổn định). Trong khoảng này, bất kỳ tác vụ nào trên main thread kéo dài quá 50ms đều được xem là long task.

Sau đó, hệ thống chỉ cộng phần thời gian vượt mốc 50ms của từng tác vụ. Tổng các phần vượt này chính là blocking time của trang trong giai đoạn đo.

Điểm quan trọng là: Một website vẫn có thể hiển thị khá sớm nhưng TBT vẫn cao. Đây là lý do nhiều doanh nghiệp nhìn thấy giao diện “đã lên”, nhưng người dùng thực tế vẫn cảm giác trang chậm phản hồi.

Ví dụ minh họa cách tính TBT

Giả sử trong khoảng FCP đến TTI có 3 tác vụ như sau:

Trong ví dụ này, cách tính TBT rất đơn giản: Chỉ cộng 70ms + 150ms = 220ms.

Vì sao TBT thường liên quan đến JavaScript?

Trong thực tế audit website, TBT rất thường gắn với JavaScript execution hơn là các yếu tố bề mặt như hình ảnh.

• JavaScript nặng có thể chiếm main thread quá lâu trong lúc tải.
• Third-party scripts như live chat, tracking, popup, heatmap hoặc tag quảng cáo rất dễ tạo long tasks.
• Với nhiều website doanh nghiệp, nguyên nhân chính không phải ảnh nặng, mà là script từ plugin, app hoặc page builder.

Đây là tình huống chúng tôi gặp khá thường xuyên: sau khi gắn thêm chat, pixel theo dõi và popup, điểm Lighthouse TBT tăng rõ rệt dù giao diện gần như không đổi.

Vì sao TBT quan trọng với trải nghiệm người dùng và SEO?

TBT quan trọng vì nó phản ánh một trải nghiệm rất thực tế: Website trông có vẻ đã tải, nhưng thao tác chưa mượt. Người dùng nhìn thấy menu, nút CTA hoặc form, nhưng khi bấm thì phản hồi chậm. Cảm giác này thường được mô tả rất đơn giản là “trang bị đơ”.

Với đội ngũ quản lý website, đây là một tín hiệu chẩn đoán hữu ích. Nó giúp phát hiện sớm các vấn đề tương tác trong môi trường lab trước khi chúng ảnh hưởng rộng hơn đến khả năng tương tác hoặc chuyển đổi.

TBT và trải nghiệm “trang tải rồi nhưng chưa dùng được”

Một trang có thể đã hiện logo, banner, menu và cả nút đăng ký. Nhưng nếu người dùng bấm vào menu mà chưa mở, hoặc nhấn CTA mà phải chờ vài trăm mili giây, trải nghiệm thực tế vẫn kém. TBT giúp phát hiện đúng giai đoạn này.

Ví dụ quen thuộc là landing page có popup, script đo hành vi và live chat cùng khởi chạy lúc đầu. Trang nhìn thì đầy đủ, nhưng thao tác đầu tiên của người dùng lại chậm thấy rõ.

TBT có ảnh hưởng SEO trực tiếp không?

Không trực tiếp. TBT không phải là yếu tố xếp hạng SEO trực tiếp giống như các chỉ số Core Web Vitals chính thức. Tuy nhiên, đây vẫn là chỉ số rất hữu ích để chẩn đoán các vấn đề tương tác có thể ảnh hưởng gián tiếp đến trải nghiệm người dùng, tỷ lệ thoát, tương tác và chuyển đổi.

Điều cần nhớ:

• TBT là lab signal, không phải dữ liệu field trực tiếp.
• INP (Interaction to Next Paint - chỉ số đo độ trễ tương tác thực tế) hiện phù hợp hơn để đánh giá trải nghiệm thật.
• TBT cao vẫn là dấu hiệu nên xử lý, đặc biệt nếu website phụ thuộc nhiều vào JavaScript.

TBT bao nhiêu là tốt? Cách đọc chỉ số trong Lighthouse/PageSpeed

Nếu cần một mốc thực hành dễ nhớ, hãy xem <200ms là tốt. Đây là ngưỡng thường được dùng để hướng tới trải nghiệm phản hồi tốt trên thiết bị di động trung bình. Tuy nhiên, bạn cũng sẽ thấy một số tài liệu hoặc công cụ tham chiếu mốc <300ms là chấp nhận được trong vài bối cảnh đánh giá.

Khác biệt này không mâu thuẫn. <200ms là mục tiêu chặt hơn và an toàn hơn. <300ms là mốc tham chiếu rộng hơn, thường dùng để phân loại mức độ cần ưu tiên xử lý.

Lưu ý: đây là mốc tham chiếu thực hành, không phải luật cứng cho mọi website.

Đọc TBT ở đâu trong Lighthouse và PageSpeed?

1. Mở báo cáo Performance trong Lighthouse hoặc PageSpeed Insights.
2. Tìm chỉ số Total Blocking Time trong nhóm các metric hiệu năng.
3. Xem tiếp phần Opportunities và Diagnostics để truy nguyên tác vụ, file JS hoặc script bên thứ ba gây nghẽn.

Nếu bạn đang quản lý website nhưng chưa rõ nên bắt đầu từ đâu, cách đọc theo 3 bước này thường đủ để xác định hướng xử lý ban đầu.

Vì sao điểm Lighthouse thấp nhưng chưa chắc đã ảnh hưởng đến trải nghiệm người dùng?

Vì TBT là lab metric. Nó đo trong môi trường mô phỏng, còn trải nghiệm thực tế còn phụ thuộc vào thiết bị, mạng, thời điểm người dùng tương tác và hành vi sử dụng thật. Có trường hợp điểm lab chưa đẹp, nhưng người dùng thật vẫn thấy ổn ở các tác vụ quan trọng.

Dù vậy, nếu PageSpeed TBT quá cao, đó vẫn là tín hiệu đáng ưu tiên xử lý. Đặc biệt với website có nhiều script marketing, landing page hoặc ứng dụng web nặng JavaScript.

TBT khác gì với INP, FCP và TTI?

Đây là chỗ nhiều người dễ nhầm:

• FCP đo thời điểm nội dung đầu tiên xuất hiện.
• TBT đo mức chặn phản hồi trong khi tải.
• INP phản ánh độ trễ tương tác thực tế tốt hơn.
• TTI là mốc kỹ thuật cho thấy trang đạt trạng thái tương tác tương đối ổn định.

Vì vậy, các chỉ số này không thay thế hoàn toàn cho nhau. Mỗi chỉ số trả lời một câu hỏi khác nhau.

Bảng phân biệt nhanh các chỉ số

Nên ưu tiên chỉ số nào?

Nếu mục tiêu là audit trong Lighthouse, hãy xem TBT như một tín hiệu chẩn đoán rất hữu ích. Nếu mục tiêu là đánh giá trải nghiệm người dùng thật, hãy ưu tiên INP vì đây là chỉ số gần hơn với hành vi ngoài thực tế.

Cách tiếp cận an toàn là:

• Audit lab để phát hiện vấn đề sớm: nhìn TBT
• Đánh giá tác động thực tế: nhìn INP
• Kiểm tra tốc độ hiển thị ban đầu: nhìn FCP
• Không dùng một metric duy nhất để kết luận toàn bộ chất lượng website

Nguyên nhân phổ biến khiến TBT cao

Trong đa số trường hợp, nguyên nhân TBT cao không nằm ở một yếu tố duy nhất, mà là tổng hợp của nhiều script cùng cạnh tranh tài nguyên trên main thread. Tuy nhiên, có một thủ phạm xuất hiện lặp đi lặp lại trong các website doanh nghiệp: JavaScript execution nặng.

Tiếp theo là third-party scripts và các thành phần được thêm vào trong quá trình làm marketing, tracking hoặc tối ưu chuyển đổi. Đây là lý do một website mới redesign xong hoặc mới gắn thêm nhiều công cụ thường bị tăng TBT đột ngột.

Những tình huống thường gặp trên website doanh nghiệp Việt

• WordPress: Cài nhiều plugin SEO, popup, form, chat, tracking rồi thêm page builder, khiến JS phình to nhanh.
• Shopify: Gắn nhiều app upsell, review, pixel, app chat và script đo hành vi, làm main thread bận ngay khi tải.
• Landing page: Dùng countdown, popup exit intent, sticky CTA, heatmap và form đa bước cùng lúc.
• Page builder: Tạo layout nhanh, nhưng thường kéo theo nhiều tài nguyên và xử lý JavaScript không thật sự cần thiết.
• Framework hiện đại: Trong một số dự án React/Next.js, chi phí hydration cũng có thể làm tăng TBT nếu không kiểm soát tốt.

Dấu hiệu cho thấy vấn đề nằm ở script bên thứ ba

• TBT tăng rõ sau khi gắn thêm live chat, popup, tracking hoặc công cụ phân tích.
• Phần Diagnostics trong Lighthouse báo nặng main-thread work hoặc JavaScript execution.
• Tắt thử một số script và đo lại thấy kết quả cải thiện đáng kể.
• Website trên desktop có vẻ ổn, nhưng mobile bị chậm phản hồi rõ hơn.
• Các trang landing page marketing có TBT xấu hơn nhiều so với trang nội dung thông thường.

Nếu đội ngũ của bạn đang gặp tình huống này, nên bắt đầu bằng việc rà soát toàn bộ script bên thứ ba trước khi yêu cầu dev tối ưu sâu hơn.

Cách cải thiện Total Blocking Time ở mức tổng quan

Nguyên tắc quan trọng nhất khi tối ưu Total Blocking Time là: đừng bắt đầu bằng các kỹ thuật phức tạp nếu bạn vẫn chưa loại bỏ được phần JavaScript không cần thiết. Trong nhiều dự án, bước mang lại hiệu quả nhanh nhất không phải viết lại hệ thống, mà là cắt bớt plugin, app và script không tạo giá trị rõ ràng.

Sau đó bạn mới đến các lớp tối ưu kỹ thuật hơn như defer script, async, code splitting hoặc chia nhỏ long tasks. Cuối cùng, mọi thay đổi đều cần đo lại bằng Lighthouse, PageSpeed Insights hoặc WebPageTest để tránh tối ưu theo cảm tính.

Danh sách ưu tiên ngắn gọn để cách giảm TBT rõ ràng hơn:

1. Cắt bớt script, plugin hoặc app không thực sự cần.
2. Trì hoãn script không quan trọng bằng async hoặc defer khi phù hợp.
3. Giảm khối lượng JavaScript phải chạy lúc đầu.
4. Chia nhỏ các long tasks để main thread đỡ bị nghẽn liên tục.
5. Kiểm tra lại từng thay đổi bằng Lighthouse hoặc WebPageTest.
6. Theo dõi thêm INP để xem tác động ngoài thực tế.

Checklist ưu tiên cho marketer/chủ website trước khi giao dev

1. Liệt kê toàn bộ script, plugin, app và công cụ đang gắn trên site.
2. Đánh dấu cái nào thực sự phục vụ chuyển đổi, tracking hoặc vận hành.
3. Tắt thử những thành phần nghi ngờ và đo lại TBT trên từng trang chính.
4. Xác định trang nặng nhất, thường là homepage, landing page hoặc trang có nhiều popup.
5. Loại bỏ các script chỉ được giữ vì “biết đâu sau này dùng”.

Đây là bước rất thực tế. Chỉ riêng việc gỡ bỏ các script marketing không cần thiết cũng đã giúp cải thiện đáng kể chỉ số này, trước khi đội ngũ kỹ thuật cần can thiệp sâu vào mã nguồn.

Checklist cho team dev khi bắt đầu xử lý

• Tìm các tác vụ dài (long tasks) thông qua Chrome DevTools hoặc báo cáo trong Lighthouse.
• Ưu tiên các file JS nặng, third-party scripts và chi phí hydration nếu có.
• Áp dụng async hoặc defer cho script không quan trọng với hiển thị ban đầu.
• Chia nhỏ xử lý trên main thread để tránh tác vụ kéo dài liên tục.
• Đo lại sau mỗi thay đổi để biết chính xác hạng mục nào đang tạo khác biệt.

Nếu cần phối hợp hiệu quả giữa marketing và dev, đây là một trong những checklist nên chuẩn hóa thành quy trình nội bộ.

Khi nào doanh nghiệp nên audit hiệu năng tổng thể thay vì chỉ nhìn mỗi TBT?

TBT chỉ là một phần của bức tranh hiệu năng. Nếu website vừa redesign, vừa gắn thêm nhiều tool marketing hoặc vừa đổi nền tảng, chỉ nhìn riêng chỉ số này là chưa đủ. Khi đó, doanh nghiệp nên làm audit hiệu năng website ở mức rộng hơn để tránh xử lý triệu chứng mà bỏ sót nguyên nhân hệ thống.

Các dấu hiệu nên audit tổng thể:

• Website mới redesign xong nhưng điểm hiệu năng giảm mạnh.
• Gắn nhiều tracking, app, chat, popup trong thời gian ngắn.
• Tốc độ hiển thị, tương tác và ổn định layout đều có vấn đề.
• Đội SEO thấy ảnh hưởng đến crawl, trải nghiệm mobile hoặc chuyển đổi.

Ngoài TBT, nên nhìn thêm INP, LCP, CLS và một số hạng mục technical SEO liên quan đến cấu trúc tải trang.

Nếu bạn cần một quy trình đánh giá có hệ thống hơn, seoon.top có thể hỗ trợ audit nhẹ theo hướng hiệu năng, SEO kỹ thuật, tập trung vào các điểm gây ảnh hưởng thật đến trải nghiệm và chuyển đổi.

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

Total Blocking Time (TBT) là gì?

Total Blocking Time (TBT) là chỉ số đo lường tổng thời gian luồng chính của trình duyệt bị "chặn" trong giai đoạn tải trang, khiến website không thể phản hồi các tương tác từ người dùng như nhấp chuột hay cuộn trang.

Làm thế nào để tính chỉ số TBT?

TBT được tính bằng tổng thời gian vượt quá 50ms của tất cả các "tác vụ dài" (long tasks) xảy ra từ thời điểm First Contentful Paint (FCP) đến khi trang tương tác ổn định (TTI).

TBT có phải là một yếu tố xếp hạng SEO trực tiếp không?

Không. TBT không phải là yếu tố xếp hạng trực tiếp của Google. Tuy nhiên, TBT là chỉ số dự báo quan trọng cho INP (Core Web Vital), nên việc tối ưu TBT gián tiếp giúp cải thiện trải nghiệm người dùng và SEO.

Chỉ số TBT bao nhiêu là tốt?

Theo tiêu chuẩn thực hành tốt nhất, bạn nên phấn đấu đạt TBT dưới 200 mili giây (ms) khi kiểm tra trên các thiết bị di động để đảm bảo trải nghiệm người dùng mượt mà và hiệu quả.

Tại sao website của tôi hiển thị nhanh nhưng TBT vẫn cao?

Trang web có thể đã hiển thị nội dung (FCP) nhanh chóng nhưng vẫn bị đơ do luồng chính phải xử lý quá nhiều tệp JavaScript nặng hoặc script bên thứ ba, khiến trình duyệt không thể phản hồi tương tác ngay lập tức.

Cách đơn giản nhất để giảm TBT là gì?

Hãy bắt đầu bằng việc cắt giảm các script không cần thiết, trì hoãn (defer) các tệp JavaScript bên thứ ba và chia nhỏ các tác vụ xử lý nặng trên luồng chính để trình duyệt có không gian "thở" và phản hồi người dùng.

Xem thêm:

• Rich Results Test: Cách kiểm tra Structured Data trên Google
• Audit Core Web Vitals: Quy trình kiểm tra hiệu suất chuẩn xác
• Render Blocking Resources là gì? Cách tối ưu để tăng tốc website

Kết luận

Hiểu đúng total blocking time sẽ giúp bạn đọc chính xác hơn một trong những chỉ số quan trọng nhất của Lighthouse về khả năng phản hồi khi tải. TBT không đo việc trang đã hiện hay chưa, mà đo website bị chặn đến mức nào trước khi người dùng có thể thao tác mượt. Nếu chỉ số này cao, hướng xử lý thực tế nhất thường là cắt bớt script hoặc JavaScript không cần thiết, ưu tiên các thành phần bên thứ ba, rồi đo lại sau mỗi thay đổi.