クイックダウンロード:
総ブロッキング時間は、重要な読み込みフェーズ中にウェブページが応答しなくなる時間を測定することで、ユーザーエクスペリエンスに直接影響を与えます。
-
TBTは、メインスレッドでFirst Contentful PaintからTime to Interactiveまでの間に50ms以上かかるタスクによるすべてのブロッキング期間の合計として計算されます。
-
TBTスコアは300ms未満が良好とされ、600msを超えるスコアは遅いとみなされ、ユーザーエクスペリエンスとSEOランキングに悪影響を及ぼします。
-
あるラテンアメリカの大手eコマースプラットフォームは、TBTを最適化することで、最大潜在FIDを1,710msから200msに短縮した。
-
サードパーティースクリプトを削減し、コード分割を実装し、コードをミニファイし、Webワーカーを使用してメインスレッドの処理をオフロードすることで、TBTを最適化します。
TBTとは何ですか?
合計ブロッキング時間(TBT) これは、ページ読み込み中にブラウザのメインスレッドが長時間かかる処理で占有され、クリック、タップ、キー入力に反応できなくなる瞬間を測定するものです。ページが完全にインタラクティブになる前の応答性と使いやすさを評価するための重要なラボ指標です。
TBTが測定するもの
TBTは、 First Contentful Paint(FCP) (NAIST) と 対話時間(TTI)ページがユーザーに応答するには「忙しすぎる」状態になっている場合。ブラウザのメインスレッドがページの読み込みに必要なすべての処理を実行すると、実行時間の長いタスクが蓄積され、TBT はそれらのタスクによって発生する合計ブロッキング時間を計測します。
メインスレッド
ブラウザのメインスレッドは、ウェブページのレンダリング中に、HTMLの解析、DOMの構築、JavaScriptとCSSの実行、ガベージコレクション、イベント処理など、重要なタスクを含む複数のタスクを実行します。
長時間の作業
長時間タスクとは、メインスレッド上で完了までに50ミリ秒以上かかる操作のことです。このタスクの実行中は、ブラウザはタスクを一時停止したり中断したりすることができないため、メインスレッドは事実上ブロックされ、その間はクリック、タップ、キー入力に応答できなくなります。
総ブロッキング時間は、ページ読み込み中に発生する長時間タスクによるすべてのブロッキング期間の合計です。下の図では、40ミリ秒のタスクを除くすべてのタスクが長時間タスクとしてカウントされ、それらのブロッキング時間を合計したものがページのTBTとなります。

下の図は、メインスレッドが長時間かかるタスクによってブロックされる時間を示しています。

| タスク | タスク実行時間(ミリ秒) | メインスレッドのブロッキング時間(ミリ秒) |
|---|---|---|
| 1 | 250 | 200 |
| 2 | 150 | 100 |
| 3 | 40 | 0 |
| 4 | 100 | 70 |
| 5 | 70 | 50 |
| トータル | 610 | 420 |
ここでの合計ブロッキング時間は420ミリ秒です。
TBTがユーザーエクスペリエンスに与える影響
ユーザーは、ウェブページの一部コンテンツが読み込まれた後、ページが完全にインタラクティブになる前でも、ページを操作することがあります。例えば、ユーザーはページの初期読み込み中に、マウスのクリック、キーボードの押下、画面のタップなどを使ってブラウザを操作する可能性があります。長時間実行されるタスクがあると、メインスレッドがこのような入力に応答できなくなり、ユーザーの不満につながります。さらに、TBTが大きいとTTIも長くなり、ページが完全にインタラクティブになるまで長時間待たなければならないため、ユーザーはさらに不満を感じることになります。このような状況はウェブサイト全体のユーザーエクスペリエンスに悪影響を及ぼし、ユーザーコンバージョン率の低下や離脱率の上昇につながります。
TBTがSEOに与える影響
検索エンジンのアルゴリズムは、ウェブページのランキング付けにおいてユーザーエクスペリエンスを考慮します。ウェブページに多くのブロック要素があると、迅速な応答を必要とするユーザーの検索クエリに影響を与える可能性があるため、ブロック要素が多いとページのSEOランキングに直接的な影響を与える可能性があります。
TBTが他の主要なWebバイタルとどのように関連しているか
TBT、TTI、 最初の入力遅延 (FID) はウェブページのインタラクティブ性に関連しているが、互いにかなり異なっている。
TBTとTTIの違い
インタラクティブになるまでの時間(TTI)とは、ページがユーザー操作に完全に対応できる状態になるまでの時間です。つまり、画面上に意味のあるコンテンツが表示され、主要な要素にイベントハンドラが設定されるまでの時間です。TTIが50ミリ秒以内であれば、ページはユーザー入力に確実に反応するため、動作がもたつくことなく、レスポンスの良い操作感が得られます。

一方、TBTは、TTIに到達する前にウェブページがユーザーイベントに応答しない期間を測定します。そのため、FCPからTTIの間にユーザーがウェブページを操作すると、メインスレッドがビジー状態のため、応答に遅延が発生します。
TBTとFIDの関係
初回入力遅延(FID)は、クリックやタップなど、ユーザーの最初の操作に対してページが応答するまでにかかる時間を測定します。FCP(初回入力)とTTI(Teaching Time Intensification)の間に長い時間があり、その間にユーザーが操作を行った場合、メインスレッドで実行中の長時間タスクが完了するまで、最初の応答が遅延します。そのため、メインスレッドの処理が活発なほどFIDが高くなる傾向があり、TBT(Teaching Time Time)が高いほどFIDスコアが低くなることが多いのです。
TBTのビジネスへの影響:ケーススタディ
メルカドリブレ ラテンアメリカ最大のeコマース企業の1つであり、18か国に拠点を持ち、ブラジル、メキシコ、アルゼンチンで市場をリードしている。 ケーススタディ同社は、 最大潜在FID Lighthouse で FID と TBT の両方を最適化することで、これを実現しました。そのために、Mercado Libre は、より良いユーザー エクスペリエンス、より長いショッピング セッション、より低い直帰率、ひいてはより高い売上につながる Web サイトの改善領域を特定するチームを結成しました。Web アプリケーションのパフォーマンスの遅さが、最適でないユーザー エクスペリエンスの主な原因です。同社は、製品詳細ページの FID が劣っていることを発見しました。 Chromeユーザーエクスペリエンスレポートそのため、ウェブページのインタラクティブ性の向上に重点を置きました。その過程で、WebPageTestsを使用してメインスレッドをブロックするタスクをいくつか特定しました(下図参照)。さらに、Lighthouseを使用して最大潜在FIDが1710msであることを確認しました。

Mercado Libreの商品詳細ページの読み込み中にメインスレッドをブロックするタスク
同社はこれらの問題を軽減するためにいくつかの対策を講じた。まず、メインの JavaScript バンドルのサイズを縮小し、コンパイルと解析時間を最適化した。さらに、コード分割と 部分的な水和 メインスレッドを最適化して使用する手法を採用しました。これらの最適化により、同社は最大潜在FIDを1710msから200msに短縮しました。コード分割、サードパーティースクリプトの最適化、アセットバンドルの改善を通じて、TBTの最適化に向けた取り組みを継続しました。
TBTの測定方法
良いTBTスコアとは?
一般的に、TBTスコアは 300ミリ秒以下の表は、TBT値がウェブページのパフォーマンスとどのように一致するかを示しています。 グーグル灯台.
| TBT(ミリ秒) | カラーコードによる解釈 |
|---|---|
| 0-200 | 高速(グリーン) |
| 200-600 | 中程度(オレンジ) |
| 600以上 | 遅い(赤) |
TBTの測定
TBTは、以下のツールを使用して計算できます。
TBTの低迷に寄与する要因
1. 大規模なサードパーティ製スクリプト
ウェブページ上のサードパーティ製JavaScriptは、分析データの収集、ソーシャルシェア機能の有効化、動画プレーヤーの埋め込みなど、さまざまな目的で使用されます。しかし、これらのスクリプトには最適化されていないコンテンツが含まれている場合があり、パフォーマンスを著しく低下させ、ネットワークリクエストも増加させます。さらに、サードパーティサーバーで要求されたリソースの配信に問題が発生した場合、レンダリングがブロックされる可能性があります。このように、サードパーティ製スクリプトは、処理時間の長いタスクの原因となることがあります。

WebPageTest を使用すると、実行速度の遅いサードパーティ スクリプトを特定できます。たとえば、以下のスクリーンショットは、ページの Web バイタルを示しています。 https://www.bbc.com/news/worldTBTが7334msというのは非常に低いスコアです。

テストの結果、このページにはメインスレッドを300ミリ秒以上ブロックする複数のサードパーティ製スクリプトが含まれていることが判明しました。

ここでの解決策は、冗長なサードパーティースクリプトの数を制限し、基本的なページ読み込みが完了した後にのみ読み込むようにすることです。
2. JavaScriptの実行時間が長い
ネットワーク、メモリ、コンパイル、実行のコストは、JavaScript の実行時間に影響します。最適化されていないコード、未使用のスクリプト、コーディングエラーなどの問題により、JavaScript の実行時間が長くなります。非効率なスクリプト ファイルの解析、コンパイル、実行にはかなりの時間がかかり、ページ全体の読み込み時間に影響します。WebPageTest は、スクリプトの実行時間 (CPU 時間) を表示できます。たとえば、次の画像は、前の例のすべての Web ページ リクエストを一覧表示する表から抽出したものです (https://www.bbc.com/news/world).

上記の表からわかるように、一部のJavaScriptスクリプトは実行に1000ミリ秒以上かかる場合があり、これが処理速度の低下を引き起こす可能性があります。
問題を解決する方法
- コード分割: コード分割 長時間実行されるJavaScriptがページ読み込み速度に与える影響を大幅に軽減できます。最初のページを読み込む際にすべてのJavaScriptスクリプトを一度に含めるのではなく、複数のバンドルに分割し、必要なファイルのみを必要に応じて読み込むようにします。
- サードパーティ製JavaScriptの使用を減らす: ウェブページは、多くの外部JavaScriptライブラリに依存している場合があります。可能な限りそれらの使用を減らし、ページに必要な場合にのみ読み込むようにしてください。
- コードの最小化: JavaScriptファイルやCSSファイルには、改行やスペースなどの不要な文字が含まれていることがあり、ページの読み込み速度が低下する原因となります。コードのミニファイ化は、不要なコードを削除して圧縮します。
3. 作業量が多すぎるメインスレッド
メインスレッドは、Webページの処理の大部分を担う重要な部分です。デフォルトでは、JavaScriptとCSSの解析、評価、実行、DOMの構築、指定されたスタイルの適用、ユーザーイベントの処理など、ほとんどのコアプロセスを処理します。メインスレッドがこれらのタスクでビジー状態になっている場合、ページがインタラクティブになるまでに時間がかかることがあります。たとえば、WebpageTestのページのテスト結果は次のようになります。 https://www.bbc.com/news/world メインスレッドのすべてのアクティビティ時間(アイドル時間を含む)の詳細なビューを提供します。

その PageSpeed Insightsの このツールは、メインスレッドがさまざまなタスクを実行するのにどれだけの時間を費やしているかも表示します。結果によると、メインスレッドはスクリプトの評価に多くの時間を費やしています。

メインスレッドの処理時間が長い箇所が分かれば、最適化すべき箇所を特定できます。
問題を解決する方法
メインスレッドの処理を最適化するには、以下の方法を使用します。
- 使い方 ウェブワーカー
- スクリプト評価時間の短縮
- スタイルとレイアウトの再計算を削減する
- CSSの圧縮
- 未使用のコードを削除
- 未使用および重要度の低いJavaScriptの実行を延期する
- 長時間実行される入力ハンドラの使用は避けてください。
4. DOMサイズが大きすぎる
TBTはDOMツリーが大きい場合にも増加します。これは、ページの初期読み込み時に多くの目に見えないノードが含まれることを意味し、メモリ使用量が増加します。それだけでなく、DOMツリーに複雑なスタイルが設定されている場合、ユーザーが操作するたびにブラウザはスタイルとノードの位置を再計算する必要があります。DOMサイズが大きすぎると、メインスレッドが長時間実行されるタスクによってブロックされる可能性があります。 PageSpeed Insightsの このツールは、ページのDOMサイズが過剰かどうかを示すこともできます。以下の画像は、この例の結果を示しています。 https://www.bbc.com/news/world結果によると、このウェブページには3,750個のDOM要素が含まれています。

問題を解決する方法
- ページ上で同じノードを繰り返し読み込む必要をなくすJavaScriptライブラリを選択してください。例えば、Reactを使用するWebページであれば、React-Windowを使用できます。
- 遅延読み込みを使用してください。
- ウェブページを複数のページに分割する。
5. ネットワークリクエスト数と転送サイズが大きい
ネットワークリクエスト数が多いほど、TBT値も高くなります。例えば、次の図は、例におけるドメインごとのリクエスト数の内訳を示しています。 https://www.bbc.com/news/world結果によると、自社ドメイン以外のサードパーティドメインからのリクエストの方が多かった。さらに、 PageSpeed Insights 画像、スクリプト、スタイルシート、サードパーティドメインなど、各タイプのリクエストがどれくらい到着するか、またペイロードのサイズを把握するためのツール。

問題を解決する方法
- コードの最小化、未使用スクリプトの削除、コード分割、最新のコードの提供などにより、JavaScriptファイルとCSSファイルを最適化します。
- 画像圧縮、適切な画像フォーマットの選択、画像CDNの利用、アニメーションGIFの代わりに動画を使用する、レスポンシブ画像の配信、遅延読み込みなどの技術を用いて画像を最適化しましょう。
- フォントサイズを小さくし、見えないテキストは削除してください。
- サードパーティ製コードを選択することで、サードパーティ製スクリプトを最適化します。
締めくくり
TBTは、ウェブページがインタラクティブになる前の応答性とユーザビリティを評価する重要なラボ指標です。この記事で学んだように、TBTはウェブサイトのユーザーエクスペリエンスとSEOに直接影響します。TBTが低い原因はいくつかあり、WebPageTestを使用して調べることができます。TBTが低い主な原因は、最適化されていないサードパーティのJavaScriptコードです。多くの企業が既に実施しているように、ウェブサイトの所有者はこの記事で説明されている最適化オプションに従うことでTBTを改善できます。
サイトのメインスレッドのブロックを解除して、ユーザーエクスペリエンスを向上させましょう。
総ブロッキング時間(TBT)が高いと、ユーザーの不満、離脱率の上昇、そして収益の損失につながります。LogicMonitorは、TBTをはじめとする重要なパフォーマンス指標を測定することで、処理速度の遅いサードパーティースクリプト、過剰なJavaScriptバンドル、実行時間の長いタスクなどが収益に悪影響を及ぼす前に特定するのに役立ちます。
よくあるご質問
トータルブロッキング時間が実際にユーザーに悪影響を与えているかどうかを知るにはどうすればよいですか?
ユーザーがクリックやタップしても何も起こらない、セッション再生で怒りのクリックが発生する、商品詳細ページやチェックアウトページなどのページ読み込み中に離脱するといった兆候を探してください。TBTが高いほど直帰率が高くなったり、コンバージョン率が低下したりする場合は、タスクのブロックがユーザーエクスペリエンスと収益に悪影響を与えている可能性が高いです。
既にINPやその他のコアウェブバイタルを追跡している場合でも、TBTに注力すべきでしょうか?
はい、TBTはファースト・コンテンツフル・ペイントからインタラクティブになるまでのメインスレッドのビジー度を示すラボメトリクスであり、INPやFIDといった実際のユーザーメトリクスに直接影響を与えます。ラボテストでTBTが高い場合、たとえ現在のフィールドメトリクスが許容範囲内に見えても、本番環境ではユーザーが遅い、あるいは遅延したインタラクションを経験している可能性が高いです。
フロントエンド全体を書き換えることなく、TBT(Through-Before Time:時間的制約)を削減するための最も手っ取り早い方法は何ですか?
まず、不要なサードパーティースクリプトを削除または遅延読み込みし、コード分割とミニファイ化によって大きなJavaScriptバンドルを削減することで、メインスレッドの負荷を軽減します。その後、Webワーカーを使用して負荷の高い処理をメインスレッドから切り離し、重要度の低いUIコンポーネントを遅延ロードすることで、ユーザーが主要な要素をより早く操作できるようになります。
LogicMonitorは、TBTのリグレッションを長期的に未然に防ぐためにどのように役立ちますか?
LogicMonitorの合成監視機能は、他のWebバイタル指標と並行してTBTを継続的に測定するため、新しいコード、タグ、またはサードパーティースクリプトがデプロイされた時点でリグレッションを検出できます。収益が落ち込んでから数週間後に問題に気づく必要はありません。ダッシュボード、アラート、詳細なウォーターフォールビューにより、TBTの問題が顧客に大規模に影響を与える前に、どのスクリプト、ドメイン、またはページが問題を引き起こしているかをチームが特定できます。




