Total Blocking Time: Vai trò, tác động và cách tối ưu

Total Blocking Time là gì?

Total Blocking Time có thể dịch là tổng thời gian chặn. Chỉ số này cộng dồn phần thời gian vượt quá 50 mili giây của các tác vụ dài diễn ra sau First Contentful Paint trong khoảng đo của công cụ.

Trong Lighthouse mặc định, khoảng đo thường kéo dài từ First Contentful Paint đến Time to Interactive. Một số chế độ đo khác có thể tiếp tục quan sát TBT trong toàn bộ thời gian ghi hiệu suất.

Điểm quan trọng nằm ở chữ “blocking”. Khi main thread đang xử lý một tác vụ dài, trình duyệt không thể ngắt tác vụ đó ngay lập tức để ưu tiên cú nhấp chuột, thao tác chạm hoặc việc cập nhật giao diện.

Người dùng có thể nhìn thấy nút “Mua ngay”, nhưng thao tác chưa được xử lý vì JavaScript vẫn đang chạy. Đây là lý do một trang trông như đã tải xong nhưng vẫn tạo cảm giác chậm hoặc bị lỗi.

Main thread và long task là gì?

Main thread là luồng chính nơi trình duyệt thực hiện nhiều công việc quan trọng như chạy JavaScript, xử lý sự kiện, tính toán bố cục và vẽ nội dung lên màn hình.

Ở phần lớn website, nhiều công việc phải dùng chung luồng này. Khi một đoạn mã giữ main thread quá lâu, những việc khác phải xếp hàng chờ.

Có thể hình dung main thread như một quầy xử lý duy nhất. Nếu quầy đang giải quyết một giao dịch phức tạp, khách tiếp theo chưa thể được phục vụ dù họ đã đứng trước quầy.

Một tác vụ kéo dài trên 50 mili giây được xem là long task trong cách tính TBT. Ngưỡng này không có nghĩa mọi tác vụ 51 mili giây đều khiến người dùng khó chịu rõ rệt, nhưng nó tạo cơ sở nhất quán để đo phần thời gian có nguy cơ chặn tương tác.

Long task không chỉ đến từ một hàm JavaScript lớn. Việc phân tích và thực thi bundle, xử lý DOM quá mức, tính lại bố cục, thu gom bộ nhớ hoặc mã từ bên thứ ba đều có thể góp phần chiếm dụng main thread.

Cách tính Total Blocking Time

TBT không cộng toàn bộ thời lượng của mọi tác vụ. Công cụ chỉ cộng phần thời gian vượt quá 50 mili giây của từng long task.

Công thức có thể hiểu như sau:

TBT = tổng của từng giá trị max(0, thời lượng tác vụ − 50 mili giây).

Trong ví dụ trên, Total Blocking Time bằng 20 cộng 70, tức 90 mili giây. Tác vụ 40 mili giây không đóng góp vào tổng TBT.

Một trang có thể có nhiều tác vụ chỉ vượt ngưỡng một ít nhưng vẫn tạo TBT lớn nếu chúng xuất hiện liên tục. Vì vậy, cần xem cả tổng thời gian chặn, số lượng long task và thời điểm chúng xảy ra.

Total Blocking Time bao nhiêu là tốt?

Theo hướng dẫn của web.dev, website nên hướng đến TBT dưới 200 mili giây khi kiểm tra trên phần cứng di động trung bình. Lighthouse cũng phân loại kết quả theo thiết bị và điều kiện kiểm thử.

Không nên coi 200 mili giây là mục tiêu duy nhất cho mọi website. Kết quả còn phụ thuộc thiết bị thử nghiệm, cấu hình Lighthouse, nhiệt độ CPU, tiện ích trình duyệt, mạng và các script động.

Hãy đo nhiều lần trong điều kiện nhất quán và theo dõi xu hướng sau mỗi thay đổi. Một lần chạy điểm cao không chứng minh toàn bộ người dùng đều có trải nghiệm tốt.

Phân biệt TBT, INP, FID và TTI

Các chỉ số này đều liên quan đến khả năng phản hồi nhưng không thể thay thế trực tiếp cho nhau. Nhầm lẫn giữa dữ liệu lab và dữ liệu người dùng thực có thể khiến đội ngũ tối ưu sai vấn đề.

TBT thấp thường có quan hệ tích cực với INP, nhưng không bảo đảm INP tốt. TBT có thể phát hiện tác vụ dài khi người dùng chưa tương tác, trong khi INP đo trải nghiệm tương tác thật trong toàn bộ thời gian người dùng ở lại trang.

Ngược lại, một vấn đề chỉ xuất hiện sau khi người dùng mở menu, gửi biểu mẫu hoặc tương tác với ứng dụng có thể làm INP kém nhưng không xuất hiện trong bài kiểm tra TBT ở giai đoạn tải ban đầu.

Cách dùng đúng là xem TBT như tín hiệu chẩn đoán trong lab và dùng INP từ Chrome UX Report hoặc hệ thống Real User Monitoring để xác nhận trải nghiệm ngoài thực tế.

TBT có phải Core Web Vital không?

Không. Total Blocking Time là chỉ số lab của Lighthouse, không phải một trong ba Core Web Vitals hiện hành.

Core Web Vitals hiện tập trung vào LCP cho tốc độ tải nội dung chính, INP cho khả năng phản hồi và CLS cho độ ổn định bố cục. Các chỉ số này được đánh giá bằng dữ liệu người dùng thực khi đủ điều kiện thu thập.

TBT vẫn quan trọng vì nó giúp đội kỹ thuật tìm ra nguyên nhân làm main thread bận trong quá trình tải. Trên Lighthouse 10, TBT chiếm 30% trọng số điểm Performance, cao hơn từng chỉ số riêng lẻ còn lại.

Tuy nhiên, điểm Lighthouse và TBT không phải tín hiệu xếp hạng trực tiếp. Không nên viết rằng chỉ cần giảm TBT thì từ khóa chắc chắn tăng hạng.

Hiệu suất kỹ thuật có thể cải thiện trải nghiệm, khả năng sử dụng và hiệu quả chuyển đổi. Trong SEO, nó cần được kết hợp với nội dung hữu ích, khả năng thu thập dữ liệu, cấu trúc website và mức độ phù hợp với nhu cầu tìm kiếm.

TBT ảnh hưởng đến người dùng và doanh thu thế nào?

Khi giao diện không phản hồi, người dùng khó biết hệ thống đang xử lý hay đã bị lỗi. Họ có thể nhấp nhiều lần, đóng biểu mẫu, làm mới trang hoặc rời đi.

Vấn đề đặc biệt nghiêm trọng ở các bước có giá trị cao như thêm sản phẩm vào giỏ, chọn phương thức thanh toán, gửi yêu cầu báo giá hoặc mở số điện thoại trên thiết bị di động.

Nghiên cứu Milliseconds Make Millions của Deloitte theo dõi dữ liệu mobile trong bốn tuần ở nhiều thương hiệu bán lẻ, du lịch, hàng xa xỉ và tạo khách hàng tiềm năng. Khi tốc độ mobile cải thiện 0,1 giây, nhóm bán lẻ ghi nhận tỷ lệ chuyển đổi tăng trung bình 8,4%.

Kết quả trên phản ánh mối liên hệ giữa hiệu suất mobile và hành vi kinh doanh trong bối cảnh nghiên cứu, không có nghĩa mọi website giảm 0,1 giây đều tăng chuyển đổi đúng 8,4%.

TBT chỉ là một phần của hiệu suất. Doanh nghiệp nên theo dõi thêm LCP, INP, CLS, tỷ lệ lỗi, tỷ lệ hoàn tất biểu mẫu và chuyển đổi thực tế để đánh giá tác động toàn diện.

Nguyên nhân khiến Total Blocking Time cao

JavaScript được tải và thực thi quá nhiều

Đây là nguyên nhân phổ biến nhất. Trình duyệt phải tải, phân tích, biên dịch và chạy mã trước khi nhiều chức năng trở nên sẵn sàng.

Một file đã được nén nhỏ chưa chắc chạy nhanh. Minify và Brotli giảm dung lượng truyền tải, nhưng không tự động giảm khối lượng công việc khi JavaScript được thực thi.

Bundle lớn và không chia theo nhu cầu

Nếu toàn bộ mã cho trang sản phẩm, tài khoản, giỏ hàng và dashboard quản trị được gộp vào cùng bundle, người dùng có thể phải xử lý nhiều code không liên quan đến trang đang xem.

Code splitting và dynamic import giúp chỉ tải phần cần thiết cho route hoặc thành phần hiện tại.

Mã bên thứ ba

Analytics, pixel quảng cáo, trình quản lý thẻ, live chat, heatmap, A/B testing, video nhúng và widget mạng xã hội đều có thể tạo long task.

Vì mã được vận hành bởi nhà cung cấp khác, website khó kiểm soát cách nó thay đổi theo thời gian. Một script từng nhẹ có thể trở nên nặng sau khi nhà cung cấp cập nhật.

Plugin WordPress chèn script trên mọi trang

Nhiều plugin tải JavaScript và CSS toàn site dù chức năng chỉ xuất hiện ở một vài trang. Trình tạo giao diện, slider, popup, biểu mẫu, đánh giá, chia sẻ xã hội và thống kê có thể tạo tải chồng chéo.

Việc cài nhiều plugin tối ưu cùng lúc cũng có thể gây xung đột, trì hoãn sai script hoặc tạo lại bundle lớn hơn.

Xử lý DOM và layout quá mức

JavaScript truy vấn hàng nghìn phần tử, thêm nhiều node liên tục hoặc đọc–ghi layout xen kẽ có thể buộc trình duyệt tính toán bố cục nhiều lần.

DOM quá lớn làm tăng chi phí selector, style calculation và layout. Đây là lý do tối ưu HTML gọn cũng hỗ trợ giảm công việc main thread.

Hydration nặng

Website render phía máy chủ có thể hiển thị HTML sớm nhưng vẫn phải tải JavaScript để “hydrate” toàn bộ giao diện. Trong giai đoạn này, nội dung đã nhìn thấy nhưng thành phần tương tác có thể chưa sẵn sàng.

Hydration toàn trang thường tạo nhiều công việc khởi tạo. Partial hydration, islands architecture hoặc server components có thể giảm lượng JavaScript phía khách hàng tùy nền tảng.

Tác vụ tính toán đặt trên main thread

Lọc dữ liệu lớn, phân tích chuỗi, tạo báo cáo, mã hóa, xử lý ảnh hoặc tính toán phức tạp có thể giữ luồng chính trong thời gian dài.

Nếu công việc không cần truy cập DOM, đây là ứng viên phù hợp để chuyển sang Web Worker.

Cách kiểm tra nguyên nhân TBT cao

Đo bằng PageSpeed Insights

PageSpeed Insights cung cấp hai nhóm dữ liệu. Phần dữ liệu người dùng thực cho biết Core Web Vitals khi có đủ mẫu; phần Lighthouse cung cấp TBT trong môi trường lab.

Hãy kiểm tra riêng mobile và desktop. Mobile thường bộc lộ rõ vấn đề CPU vì cấu hình mô phỏng chậm hơn.

Chạy Lighthouse trong cửa sổ ẩn danh

Tiện ích trình duyệt có thể chèn mã và làm sai kết quả. Nên thử ở cửa sổ ẩn danh, đóng các tab không cần thiết và chạy nhiều lần.

Giữ nguyên thiết bị, chế độ throttling và phiên bản trình duyệt khi so sánh trước–sau.

Dùng Chrome DevTools Performance

Tab Performance cho biết main thread đã làm gì theo thời gian. Các long task thường xuất hiện thành khối có dấu hiệu cảnh báo trên timeline.

Mở Bottom-up hoặc Call tree để tìm hàm chiếm nhiều thời gian. Kiểm tra script thuộc mã nội bộ hay bên thứ ba trước khi quyết định cách xử lý.

Kiểm tra Coverage

Coverage cho biết bao nhiêu phần JavaScript và CSS được tải nhưng chưa sử dụng trong lần ghi hiện tại. Tỷ lệ unused cao là tín hiệu để xem xét tách bundle hoặc chỉ tải tài nguyên theo trang.

Không nên xóa code chỉ dựa trên một lần Coverage. Một chức năng có thể chưa được kích hoạt trong kịch bản kiểm tra nhưng vẫn cần cho thao tác khác.

So sánh khi chặn script bên thứ ba

DevTools hoặc WebPageTest có thể hỗ trợ chặn domain để kiểm tra ảnh hưởng của từng nhà cung cấp. Nếu TBT giảm mạnh khi chặn chat hoặc heatmap, đội ngũ đã tìm thấy ứng viên cần trì hoãn hay thay thế.

10 cách tối ưu Total Blocking Time

1. Loại bỏ JavaScript không tạo giá trị

Giải pháp hiệu quả nhất thường là gửi ít JavaScript hơn. Hãy bắt đầu từ danh sách plugin, thư viện, widget và tag đang hoạt động.

Mỗi script cần trả lời được ba câu hỏi: nó phục vụ mục tiêu nào, có người chịu trách nhiệm không và dữ liệu thu được có được sử dụng không. Script không có giá trị rõ ràng nên được gỡ bỏ.

2. Chia nhỏ bundle theo trang và tính năng

Áp dụng code splitting để người dùng chỉ tải mã cần cho trang hiện tại. Các chức năng hiếm dùng có thể tải khi người dùng mở modal, chuyển tab hoặc đi đến route liên quan.

Việc chia quá nhỏ cũng tạo nhiều request và overhead. Cần đo lại thay vì mặc định càng nhiều chunk càng tốt.

3. Chia nhỏ long task

Một vòng lặp hoặc chuỗi xử lý dài nên được chia thành các phần nhỏ để trình duyệt có cơ hội xử lý tương tác giữa các lần chạy.

scheduler.yield() có thể chủ động nhường main thread trên trình duyệt hỗ trợ. Cần feature detection và phương án dự phòng, chẳng hạn setTimeout(), cho môi trường chưa hỗ trợ.

Không nên dùng việc chia tác vụ để che giấu thuật toán kém hiệu quả. Hãy giảm tổng lượng công việc trước, sau đó mới tổ chức lịch thực thi.

4. Dùng defer và async đúng trường hợp

Script đồng bộ có thể chặn quá trình phân tích HTML. Thuộc tính defer cho phép tải song song và thực thi sau khi HTML được phân tích, đồng thời giữ thứ tự giữa các script defer.

async phù hợp với script độc lập và có thể chạy ngay khi tải xong. Nếu script phụ thuộc thứ tự hoặc DOM, dùng async thiếu kiểm soát có thể gây lỗi.

5. Trì hoãn mã bên thứ ba không thiết yếu

Chat, video nhúng, bản đồ tương tác hoặc công cụ khảo sát có thể chỉ tải khi người dùng sắp sử dụng. Placeholder nhẹ giúp giữ bố cục trước khi thành phần thật được kích hoạt.

Với tracking, cần cân bằng giữa hiệu suất, độ chính xác dữ liệu và yêu cầu về sự đồng ý. Không nên trì hoãn tùy tiện các tag cần thiết cho đo lường chuyển đổi mà chưa kiểm tra tác động.

6. Quản trị Google Tag Manager

Tag Manager giúp quản lý thẻ nhưng không tự làm website nhanh hơn. Nếu mọi tag cùng kích hoạt ở Page View, trình duyệt vẫn phải xử lý tất cả.

Hãy rà soát trigger, xóa tag cũ, tránh biến JavaScript tùy chỉnh nặng và giới hạn tag theo đúng trang hoặc sự kiện cần đo.

7. Chuyển tính toán phù hợp sang Web Worker

Web Worker chạy trong luồng nền tách khỏi main thread, phù hợp cho công việc tính toán không cần trực tiếp thao tác DOM.

Không phải tác vụ nào cũng nên chuyển sang worker. Chi phí truyền dữ liệu, tổ chức mã và đồng bộ kết quả có thể lớn hơn lợi ích với công việc nhỏ.

8. Giảm công việc DOM và layout

Giữ cấu trúc DOM gọn, hạn chế selector quá rộng và gom các thay đổi giao diện thành nhóm. Tránh đọc kích thước rồi ghi style lặp đi lặp lại trong cùng vòng xử lý.

Ảnh và thành phần có kích thước rõ ràng cũng giúp giảm tính toán lại bố cục, đồng thời hỗ trợ CLS.

9. Giảm hydration và JavaScript phía client

Với ứng dụng hiện đại, hãy xem thành phần nào thật sự cần tương tác. Nội dung tĩnh không nhất thiết phải hydrate.

Partial hydration, islands architecture và render phía máy chủ có chọn lọc giúp tập trung JavaScript vào các “đảo” tương tác thay vì toàn bộ trang.

10. Kiểm thử sau từng thay đổi

Tối ưu hiệu suất có thể làm hỏng menu, slider, form, theo dõi quảng cáo hoặc checkout. Mỗi thay đổi cần được thử trên staging trước khi áp dụng cho website thật.

Ghi lại phiên bản, TBT trước–sau, script đã thay đổi và các chức năng đã kiểm tra. Điều này giúp quay lại nhanh nếu xảy ra lỗi.

Tối ưu TBT cho website WordPress

WordPress thường có TBT cao không phải do lõi hệ thống, mà do giao diện, plugin và mã theo dõi được tích hợp theo thời gian.

Cache trang và CDN giúp giảm thời gian phản hồi máy chủ, nhưng không tự giải quyết JavaScript thực thi quá lâu. Một website có TTFB tốt vẫn có thể có TBT cao.

Khi sử dụng dịch vụ quản trị website, doanh nghiệp nên yêu cầu theo dõi cả lỗi chức năng và ngân sách hiệu suất sau mỗi lần cài plugin hoặc thêm mã marketing.

TBT trong chiến lược SEO tổng thể

TBT không nên được tối ưu tách rời nội dung và mục tiêu kinh doanh. Một trang rất nhẹ nhưng thiếu thông tin vẫn không đáp ứng nhu cầu tìm kiếm.

Ngược lại, bài viết dài không mặc định gây TBT cao. HTML văn bản và ảnh được tối ưu thường ít làm main thread bận hơn slider, hiệu ứng hoặc các bundle JavaScript lớn.

Một kế hoạch SEO tổng thể nên phối hợp giữa technical SEO, content, UX và đo lường. Đội ngũ cần biết thành phần nào tạo giá trị cho người dùng và thành phần nào chỉ làm giao diện phức tạp.

Đối với bài blog, cấu trúc HTML gọn và nội dung rõ ràng giúp giảm nhu cầu sử dụng component nặng. Dịch vụ viết bài SEO cũng cần bàn giao nội dung phù hợp với hệ thống xuất bản thay vì lạm dụng shortcode, bảng rộng hoặc hiệu ứng không cần thiết.

Quy trình tối ưu TBT an toàn

Những sai lầm khi tối ưu TBT

Chỉ chạy PageSpeed một lần

Lighthouse có thể biến động giữa các lần đo. Kết luận dựa trên một lần chạy dễ dẫn đến đánh giá sai.

Chỉ nhìn điểm 100

Điểm tổng hợp hỗ trợ so sánh nhưng không thay thế việc hiểu người dùng và chức năng. Một trang đạt 100 trong lab vẫn có thể có INP kém khi người dùng mở component nặng.

Gộp toàn bộ JavaScript thành một file

Gộp file có thể giảm request trong một số cấu hình cũ, nhưng dễ tạo bundle lớn phải phân tích và thực thi ngay. Với HTTP hiện đại, code splitting thường có giá trị hơn việc combine máy móc.

Delay mọi script

Trì hoãn không phân loại có thể làm menu, consent, đo lường hoặc checkout hoạt động sai. Cần hiểu quan hệ phụ thuộc trước khi thay đổi thứ tự chạy.

Dùng plugin tối ưu để che vấn đề

Plugin có thể hỗ trợ nhưng không thay thế audit. Nếu website đang tải nhiều chức năng không cần thiết, giải pháp bền vững là loại bỏ hoặc thiết kế lại.

Tối ưu TBT nhưng bỏ qua INP

TBT chủ yếu phản ánh giai đoạn được đo trong lab. Website vẫn có thể chậm sau khi người dùng tương tác nếu event handler hoặc DOM update quá nặng.

Câu hỏi thường gặp về Total Blocking Time

TBT có phải tốc độ tải trang không?

TBT không đo trực tiếp thời điểm nội dung xuất hiện. Nó đo thời gian main thread bị chặn, vì vậy tập trung vào khả năng phản hồi trong quá trình tải.

TBT có phải chỉ số xếp hạng Google không?

Không. TBT là lab metric của Lighthouse, không phải Core Web Vital và không phải tín hiệu xếp hạng trực tiếp.

Tại sao TBT tốt nhưng INP vẫn kém?

TBT có thể tốt trong bài kiểm tra tải trang nhưng một tương tác xảy ra sau đó vẫn kích hoạt công việc nặng. INP quan sát tương tác thực trong suốt phiên truy cập nên có thể phát hiện vấn đề này.

Tại sao mobile có TBT cao hơn desktop?

Thiết bị mobile thường có CPU yếu hơn và Lighthouse mobile sử dụng điều kiện mô phỏng hạn chế hơn. Cùng một đoạn JavaScript có thể cần nhiều thời gian thực thi hơn.

Minify JavaScript có giảm TBT không?

Minify giúp giảm dung lượng file nhưng không chắc giảm đáng kể thời gian thực thi. Loại bỏ code, chia bundle và giảm công việc runtime thường tác động trực tiếp hơn.

CDN có giảm TBT không?

CDN giúp tài nguyên đến người dùng nhanh hơn, nhưng không giải quyết trực tiếp việc JavaScript giữ main thread. Nó có thể cải thiện tải xuống mà TBT vẫn cao.

Có nên trì hoãn Google Analytics không?

Cần đánh giá yêu cầu đo lường, consent và ảnh hưởng hiệu suất. Không nên trì hoãn hoặc loại bỏ tùy tiện vì có thể làm mất dữ liệu kinh doanh quan trọng.

Bao lâu nên kiểm tra TBT?

Nên kiểm tra sau thay đổi giao diện, plugin, tag marketing hoặc tính năng lớn. Website có quy trình phát triển liên tục nên thiết lập kiểm tra hiệu suất trong mỗi đợt phát hành.

Kết luận

Total Blocking Time đo tổng phần thời gian main thread bị các long task chặn trong môi trường lab. Chỉ số này giúp đội ngũ phát hiện JavaScript dư thừa, mã bên thứ ba, hydration nặng và công việc DOM đang làm trang phản hồi chậm.

TBT tốt không tự động bảo đảm SEO hoặc doanh thu tăng. Giá trị thật đến từ việc dùng kết quả chẩn đoán để giảm công việc không cần thiết, sau đó xác nhận bằng INP và chuyển đổi từ người dùng thực.

Doanh nghiệp nên quản lý hiệu suất như một phần của vận hành website, không phải chiến dịch xử lý một lần. Xuyên Việt Media ưu tiên sự cân bằng giữa nội dung, chức năng marketing và trải nghiệm kỹ thuật để website vừa cung cấp đủ thông tin vừa phản hồi ổn định.