Webサイトの表示速度改善において、最近特に注目されている指標の一つが「Total Blocking Time(TBT)」です。この指標は、ユーザーがWebページにアクセスした際に「実際に操作できるようになるまでの時間」を測定する重要な指標で、Core Web Vitalsの評価にも大きく影響します。
本記事では、TBTの基本的な概念から具体的な改善方法まで、初心者の方でも理解できるよう詳しく解説していきます。特に、Web表示速度改善サービス「LandingHub」を運営する私たちの経験から、実践的なアドバイスもお伝えします。
目次
TBTとは?基本概念を理解しよう
Total Blocking Timeの定義
Total Blocking Time(TBT)は、日本語で「合計ブロッキング時間」や「総ブロック時間」と訳されます。これは、ユーザーがWebページにアクセスしてから、実際にそのページを操作できるようになるまでの「待機時間」を測定する指標です。
具体的には、First Contentful Paint(FCP:初回コンテンツ表示時間)からTime to Interactive(TTI:操作可能時間)までの間で、メインスレッドが50ミリ秒以上ブロックされた時間の合計を指します。
「えっ、なんだか難しそう…」と思われるかもしれませんが、実はとてもシンプルな概念なんです。想像してみてください。あなたがWebサイトにアクセスして、リンクをクリックしようとしたとき、なぜかクリックが反応しない時間がありますよね。その「反応しない時間」がTBTに関係しているのです。
FCP(First Contentful Paint)とTTI(Time to Interactive)
TBTを理解するには、まずFCPとTTIについて知っておく必要があります。
**FCP(First Contentful Paint)**は、ページの読み込みが開始されてから、最初のコンテンツ(テキストや画像など)が画面に表示されるまでの時間です。「あ、何かが表示され始めた」という瞬間ですね。
**TTI(Time to Interactive)**は、ページが完全に読み込まれ、ユーザーが実際に操作(クリック、タップ、キーボード入力など)できるようになるまでの時間です。
TBTは、このFCPからTTIまでの間に発生する「操作できない時間」の合計を測定しています。
メインスレッドとブロッキングの概念
Webブラウザには「メインスレッド」という、重要な処理を担当する部分があります。このメインスレッドは、画面の描画、JavaScript の実行、ユーザーの操作への反応などを担当しています。
メインスレッドが何らかの処理(JavaScriptの実行など)で忙しくなると、ユーザーの操作に反応できなくなります。この状態を「ブロックされた」と表現します。
TBTでは、50ミリ秒以上メインスレッドがブロックされた場合に、その時間を「問題のある時間」として計算に含めています。なぜ50ミリ秒なのかというと、人間が「反応が遅い」と感じ始める閾値がだいたいこの辺りだからなんです。
TBTの仕組み:どのように計算されるのか?
TBTの計算方法
TBTの計算は、実は意外とシンプルです。FCP(初回コンテンツ表示)からTTI(操作可能時間)までの間に発生する各タスクについて、以下の計算を行います:
- 各タスクの実行時間が50ミリ秒を超えているかをチェック
- 超えている場合は、「実行時間 – 50ミリ秒」を計算
- すべてのタスクの超過時間を合計
例えば、3つのタスクがあったとします:
- タスク1:30ミリ秒(50ミリ秒以下なので対象外)
- タスク2:120ミリ秒(120 – 50 = 70ミリ秒が対象)
- タスク3:80ミリ秒(80 – 50 = 30ミリ秒が対象)
この場合のTBTは、70 + 30 = 100ミリ秒となります。
TBTスコアの評価基準
PageSpeed InsightsでのTBTスコアは、以下の基準で評価されます:
- 良好(緑): 0〜200ミリ秒未満
- 要改善(オレンジ): 200ミリ秒以上〜600ミリ秒以下
- 不良(赤): 600ミリ秒超
理想的には200ミリ秒以下を目指したいところですが、実際のWebサイトでは様々な要因により、この数値を達成するのは簡単ではありません。
Core Web VitalsとTBTの関係
TBTは、Googleが重要視するCore Web Vitalsの指標の一つであるINP(Interaction to Next Paint)と密接な関係があります。INPは実際のユーザーの操作データを基に計算されるため、リアルタイムでの測定が難しいのですが、TBTはPageSpeed Insightsなどのツールで簡単に測定できます。
そのため、INPの改善を目指す際の指標として、TBTを活用することが非常に有効です。TBTを改善することで、間接的にINPの改善、ひいてはSEOランキングの向上にも繋がります。
TBT低下の主な原因
TBTが悪化する原因は様々ですが、主に以下の要因が挙げられます:
1. JavaScript の過度な使用・最適化不足
最も大きな原因の一つが、JavaScript の問題です。特に以下のような状況でTBTが悪化しやすくなります:
大容量のJavaScriptファイル 多機能なWebサイトほど、JavaScript のファイルサイズが大きくなりがちです。これらのファイルを読み込み・実行する際に、メインスレッドが長時間ブロックされてしまいます。
非効率なJavaScriptコード 古いJavaScript(ES5以前)や、最適化されていないコードは実行時間が長くなり、TBTの悪化に直結します。
不要なJavaScriptの読み込み 使用していないJavaScriptライブラリやプラグインも、読み込み時間を増加させる要因となります。
2. サードパーティスクリプトの影響
多くのWebサイトでは、以下のようなサードパーティのスクリプトを使用しています:
- Google Analytics や Google Tag Manager
- SNSのシェアボタン
- 広告配信システム
- チャットボットツール
- A/Bテストツール
これらのスクリプトは外部サーバーからの読み込みが必要で、そのサーバーの応答速度によっては大きな遅延を引き起こします。
3. HTML構造の複雑化
過大なDOMサイズ HTMLの要素数が多すぎたり、階層が深すぎると、ブラウザでの処理時間が長くなります。PageSpeed Insightsでは「過大な DOM サイズの回避」として警告されることが多い問題です。
不適切なHTML構造 table要素の過度な使用や、必要以上に複雑なネストなども、処理時間増加の原因となります。
4. 画像・メディアファイルの最適化不足
大容量の画像ファイルや動画ファイルは、直接的にはTBTに影響しませんが、ページ全体の読み込み時間を延長し、結果的にTBTの悪化に繋がることがあります。
5. サーバーの応答速度
サーバーの処理能力やネットワークの速度も、間接的にTBTに影響します。特に、サーバーからのレスポンスが遅い場合、その間にメインスレッドがブロックされる可能性があります。
TBTの改善方法:実践的なアプローチ
ここからは、TBTを改善するための具体的な方法をご紹介します。技術的な知識がない方でも実践できる方法から、開発者向けの詳細な対策まで、幅広くカバーしています。
1. 基本的な設定の見直し
viewportメタタグの設定
最も基本的でありながら、効果的な改善方法の一つです。HTMLの<head>
部分に以下のメタタグを追加します:
Copy<meta name="viewport" content="width=device-width, initial-scale=1.0">
このタグがないと、モバイル端末でページを表示する際に、一度デスクトップ表示でレンダリングしてからモバイル表示に変換するため、余計な処理時間が発生してしまいます。
文字エンコーディングの指定
Copy<meta charset="UTF-8">
このタグも、ブラウザがエンコーディングを推測する時間を短縮できます。
2. JavaScript の最適化
不要なJavaScriptの削除
まず、現在使用しているJavaScriptライブラリやプラグインを見直しましょう。本当に必要なものだけを残し、使用していないものは削除します。
JavaScript の非同期読み込み
JavaScriptファイルを読み込む際に、async
やdefer
属性を使用することで、メインスレッドのブロックを避けることができます:
Copy<script async src="script.js"></script>
<script defer src="script.js"></script>
async
: スクリプトの読み込みと実行を並行して行うdefer
: スクリプトの実行をHTMLの解析完了後まで遅延
最新のJavaScriptの使用
ES6以降の最新JavaScriptは、ES5以前のものよりも高速で効率的です。可能な限り最新の記法を使用しましょう。
Copy// ES6以降(推奨)
const calculateArea = (height = 100, width = 50) => {
// 処理
};
// ES5以前(非推奨)
var calculateArea = function(height, width) {
height = height || 100;
width = width || 50;
// 処理
};
Web Workerの活用
重い処理については、Web Workerを使用してメインスレッドとは別のスレッドで実行することで、TBTの改善が可能です。
3. サードパーティスクリプトの最適化
必要性の見直し
現在使用しているサードパーティスクリプトを一つずつ見直し、本当に必要なものだけを残します。特に以下の点を確認してください:
- 実際に使用されているか
- 代替手段はないか
- 同じ機能を持つより軽量なツールはないか
読み込み方法の最適化
必要なサードパーティスクリプトについては、以下の方法で最適化できます:
Copy<!-- DNS prefetchで事前にDNS解決 -->
<link rel="dns-prefetch" href="https://www.google-analytics.com">
<!-- preconnectで事前に接続 -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<!-- 非同期読み込み -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA_MEASUREMENT_ID"></script>
4. HTML・CSSの最適化
HTML構造の簡素化
不要なHTMLタグを削除し、階層構造を浅くします。特に以下の点に注意:
- 不要なdiv要素の削除
- 適切な semantic HTML の使用
- table要素の過度な使用を避ける
CSSの最適化
Copy<!-- クリティカルCSSのインライン化 -->
<style>
/* ファーストビューに必要な最小限のCSS */
</style>
<!-- 非クリティカルCSSの遅延読み込み -->
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
5. 画像・メディアファイルの最適化
適切な画像形式の選択
- JPEG: 写真など色数の多い画像
- PNG: 透明度が必要な画像
- WebP: 対応ブラウザでのみ、高圧縮率
- SVG: アイコンやシンプルな図形
画像の遅延読み込み
Copy<img src="image.jpg" loading="lazy" alt="説明">
レスポンシブ画像の使用
Copy<img src="image-800.jpg"
srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
alt="説明">
6. ネットワークリクエストの最適化
ファイルの結合・圧縮
複数のCSSファイルやJavaScriptファイルを一つにまとめることで、HTTPリクエスト数を削減できます。
gzip圧縮の有効化
サーバー側でgzip圧縮を有効にすることで、転送データ量を大幅に削減できます。
CDN(Content Delivery Network)の活用
静的ファイルをCDNで配信することで、読み込み速度を向上させることができます。
LandingHub:TBT改善を簡単に実現
ここまで様々な改善方法をご紹介しましたが、「技術的な知識がないので実装が難しい」「時間がかかりすぎる」という方も多いのではないでしょうか。
そんな方におすすめなのが、私たちが開発・運営している「LandingHub」です。LandingHubは、タグを一つ設置するだけで、Webサイトの表示速度を劇的に改善できるサービスです。
LandingHubの特徴
1. 簡単導入 HTMLに専用タグを一つ追加するだけで、即座に効果を実感できます。専門知識は一切不要です。
2. 自動最適化 画像の自動圧縮、JavaScript の最適化、遅延読み込みなど、TBT改善に必要な処理を自動で行います。
3. 特許取得済み技術 独自の最適化技術により、従来の手法では実現できない大幅な改善効果を提供します。
4. 実績豊富 累計400社以上の導入実績があり、多くの企業様でCVR改善、売上向上を実現しています。
LandingHubの改善効果
実際にLandingHubを導入いただいた企業様では、以下のような改善効果を確認しています:
- TBTスコアの大幅改善: 平均で50-70%の改善
- 直帰率の低下: 平均で15-25%の改善
- CVR(コンバージョン率)の向上: 平均で20-40%の改善
これらの改善により、最終的に売上向上に直結する成果を上げています。
導入事例:ECサイト様の場合
あるECサイト様では、商品ページのTBTが800ミリ秒(不良レベル)だったのが、LandingHub導入後には150ミリ秒(良好レベル)まで改善されました。
その結果:
- 直帰率が35%→22%に改善
- 平均滞在時間が2分15秒→3分40秒に延長
- CVRが2.3%→3.8%に向上
この改善により、月間売上が約40%向上するという驚異的な成果を上げています。
PageSpeed InsightsでのTBT確認方法
TBTの改善に取り組む際は、定期的な測定と分析が重要です。最も一般的で手軽なツールがPageSpeed Insightsです。
PageSpeed Insightsの使い方
- PageSpeed Insightsにアクセス
- 分析したいURLを入力
- 「分析」ボタンをクリック
- 結果を確認
結果の読み方
PageSpeed Insightsの結果画面では、以下の項目を確認できます:
パフォーマンススコア 0-100点で評価され、90点以上が「良好」、50-89点が「要改善」、49点以下が「不良」とされます。
Core Web Vitals LCP、FID(またはINP)、CLSの3つの指標で、実際のユーザーデータに基づいた評価です。
その他の指標 TBTを含む、パフォーマンスに関する様々な指標が表示されます。
TBTの改善提案
PageSpeed Insightsでは、TBTの改善に関する具体的な提案も表示されます。例えば:
- 「メインスレッド処理の最小化」
- 「使用していないJavaScriptの削除」
- 「過大なDOMサイズの回避」
これらの提案を参考に、優先順位をつけて改善に取り組みましょう。
他のツールでのTBT測定
PageSpeed Insights以外にも、TBTを測定できるツールがあります。
Chrome DevToolsのLighthouse
Chrome ブラウザに内蔵されているLighthouseでも、TBTの測定が可能です。
- Chrome で対象サイトを開く
- F12キーで開発者ツールを開く
- 「Lighthouse」タブを選択
- 「Generate report」をクリック
GTmetrix
GTmetrixは、無料で使えるWebサイト分析ツールです。TBTの測定に加えて、詳細なパフォーマンス分析も可能です。
WebPageTest
WebPageTestは、より詳細な分析が可能な上級者向けツールです。世界各地のサーバーからテストを実行できます。
TBT改善の実践例とケーススタディ
ケーススタディ1:企業コーポレートサイト
改善前の状況
- TBT: 850ミリ秒(不良)
- 主な原因: 大容量のJavaScriptライブラリ、最適化されていない画像
実施した改善
- 不要なJavaScriptプラグインの削除
- 画像の最適化(WebP形式への変換)
- CSSの最適化とインライン化
- LandingHubの導入
改善後の結果
- TBT: 180ミリ秒(良好)
- 改善率: 約79%
ケーススタディ2:ランディングページ
改善前の状況
- TBT: 650ミリ秒(不良)
- 主な原因: 動画ファイルの自動再生、複雑なアニメーション
実施した改善
- 動画の遅延読み込み実装
- アニメーションの最適化
- JavaScriptの非同期読み込み
- フォント読み込みの最適化
改善後の結果
- TBT: 190ミリ秒(良好)
- CVR: 2.8%→4.2%に向上
ケーススタディ3:メディアサイト
改善前の状況
- TBT: 920ミリ秒(不良)
- 主な原因: 広告スクリプト、SNSプラグイン
実施した改善
- 広告スクリプトの最適化
- SNSプラグインの軽量化
- 画像の遅延読み込み
- AMPページの実装
改善後の結果
- TBT: 160ミリ秒(良好)
- 直帰率: 45%→28%に改善
TBT改善の優先順位と計画的アプローチ
TBTの改善は、一度にすべてを行うのではなく、計画的に進めることが重要です。
改善の優先順位
- 基本設定の見直し(viewportメタタグなど)
- 明らかに不要なリソースの削除
- JavaScriptの最適化
- 画像の最適化
- サードパーティスクリプトの最適化
- HTML・CSS構造の見直し
改善計画の立て方
Step 1: 現状把握
- PageSpeed Insightsでの定期測定
- 主な問題点の特定
- 改善目標値の設定
Step 2: 影響度の評価
- 各改善施策の効果予測
- 実装コストの見積もり
- リスクの評価
Step 3: 段階的実装
- 低リスク・高効果の施策から開始
- 各段階での効果測定
- 必要に応じた計画修正
Step 4: 継続的改善
- 定期的な測定と分析
- 新たな問題点の発見
- 継続的な最適化
よくある質問とトラブルシューティング
Q1: TBTを改善したのに、実際のユーザー体験が改善されない
A: TBTはラボデータ(模擬環境でのテスト)での測定値です。実際のユーザー環境では、ネットワーク速度やデバイス性能が異なるため、体感速度に差が生じることがあります。Real User Monitoring(RUM)ツールを使用して、実際のユーザーデータも確認しましょう。
Q2: 改善施策を実装したら、サイトの機能が動かなくなった
A: JavaScript の最適化やサードパーティスクリプトの変更は、機能に影響を与える可能性があります。本番環境に適用する前に、必ずテスト環境で動作確認を行いましょう。また、段階的な実装により、問題の発生箇所を特定しやすくなります。
Q3: TBTは改善されたが、他の指標が悪化した
A: Webサイトの最適化では、トレードオフが発生することがあります。例えば、JavaScript を削除してTBTを改善しても、必要な機能が動かなくなる可能性があります。全体的なバランスを考えて最適化を行いましょう。
Q4: モバイルのTBTだけが悪い
A: モバイル端末はCPU性能が低いため、同じコードでもデスクトップより実行時間が長くなります。モバイル向けには、より積極的な最適化が必要です。必要に応じて、モバイル専用の軽量版ページを作成することも検討しましょう。
TBT改善の長期的な戦略
継続的な監視体制の構築
定期的な測定スケジュール
- 週次: 主要ページのTBT確認
- 月次: 全サイトの包括的分析
- 四半期: 改善計画の見直し
アラート設定 TBTが一定値を超えた場合の自動通知システムを構築することで、問題の早期発見が可能になります。
組織全体でのパフォーマンス意識の向上
開発チームとの連携
- コードレビュー時のパフォーマンス確認
- 新機能開発時のTBT影響評価
- 定期的なパフォーマンス勉強会
マーケティングチームとの連携
- 新規キャンペーンページの最適化
- A/Bテスト実施時のパフォーマンス考慮
- 広告配信との連携最適化
技術的な進歩への対応
新技術の導入検討
- HTTP/3の対応
- Next.js、Nuxt.js等のフレームワーク活用
- エッジコンピューティングの活用
プラットフォームの進化への対応
- Core Web Vitals の指標変更への対応
- ブラウザの新機能活用
- モバイル端末の性能向上に合わせた最適化
まとめ:TBT改善で実現するWebサイトの成功
Total Blocking Time(TBT)の改善は、単なる技術的な指標の向上ではありません。ユーザー体験の向上、SEOランキングの改善、そして最終的にはビジネス成果の向上に直結する重要な取り組みです。
TBT改善がもたらす効果
- ユーザー体験の向上: 操作可能になるまでの時間短縮
- SEO効果: Core Web Vitals の改善によるランキング向上
- コンバージョン率の向上: 離脱率低下とエンゲージメント向上
- 売上・収益の向上: 総合的なWebサイト性能向上
今すぐ始められるアクション
- PageSpeed Insightsでの現状確認
- viewportメタタグの設置
- 不要なJavaScriptの削除
- 画像の最適化
- LandingHubの導入検討
TBTの改善は、技術的な知識がなくても始められる施策から、専門的な最適化まで幅広いアプローチが可能です。まずは簡単にできることから始めて、段階的に改善を進めていきましょう。
LandingHubで簡単・確実な改善を
もし「自分で改善するのは難しい」「確実な効果を得たい」とお考えでしたら、ぜひLandingHubの導入をご検討ください。
LandingHubの特徴
- タグ一つで簡単導入
- 自動最適化による確実な効果
- 特許取得済みの独自技術
- 400社以上の導入実績
お客様の声 「LandingHub導入後、TBTが70%改善し、CVRが40%向上しました。売上も大幅に伸びて、投資対効果は抜群です。」(ECサイト運営企業様)
Webサイトの表示速度改善、TBTの最適化により、あなたのビジネスを次のレベルへと押し上げてみませんか。