JavaScriptの遅延読み込み（defer/async）でTBTを大幅短縮する方法

JavaScriptの遅延読み込みは、ブラウザがページ内容を描画する際に妨げとなるJavaScriptファイルを適切なタイミングで読み込むことで、Total Blocking Time（TBT）を短縮する手法です。要点としては、重要でないスクリプトにdeferやasync属性を付与してメインスレッドのロック時間を減らし、ユーザーがページを素早く閲覧・操作できるようにし、Core Web Vitalsの改善につなげます。遅延読み込みを導入するには、まずどのスクリプトが重要かを見極め、依存関係のあるスクリプトにはdefer、独立した外部スクリプトにはasyncを主に採用し、変更後にはPageSpeed InsightsやLighthouse、Chrome DevToolsでTBT値を計測しましょう。

近年のウェブサイトのパフォーマンス問題は、画像よりもむしろJavaScriptの過剰利用によるものが多いです。例えばECサイトでは商品フィルターやチャット、広告ピクセル、解析タグ、コメントプラグイン、A/Bテストツール、テーマスクリプトが同時に読み込まれることでメインスレッドが長時間占有されます。特にモバイル端末では顕著で、ユーザーがページタイトルを見ても、メニューをタップしても反応が遅れることがあり、LighthouseレポートではTBT値が高く表示されます。

本記事ではdeferとasyncの仕組みや、どちらをいつ使うべきか、WordPressや独自開発サイトでの具体的な導入方法、計測時の注意点、リアルなTBT改善例まで詳しく解説します。Hostragonsのインフラを利用したサイト向けの提案は一般的なウェブ標準に準拠しており、適切なホスティング、CDN、SSL、キャッシュ設定がJavaScript最適化にどう影響するかも触れます。Hostragons ウェブホスティングパッケージ

TBTとは？なぜJavaScriptと密接なのか

TBT（Total Blocking Time）は、ページがユーザー操作に対応できるようになるまでにメインスレッドがブロックされている時間を示します。LighthouseのラボテストではFirst Contentful PaintからTime to Interactiveまでの間で、50ms以上の長いタスクが多いほどTBT値が上がります。例えば、JavaScriptのタスクが180msかかる場合、最初の50msを除いた130msがTBTへ加算されます。

この指標はユーザー体験に直結します。ページが表示された後、メニューやカート追加ボタン、検索窓をタップしてもブラウザがまだJavaScriptを実行中だと操作が遅れます。ユーザーは「固まった」「遅い」「壊れている」と感じ、2026年のSEO基準ではページ体験が直接ランキングに反映されないものの、素早く安定した操作ができるサイトはユーザー満足度やコンバージョン率で優位となります。

TBT値が高い場合によく見られる症状

• モバイルPageSpeed InsightsでTBT値が300ms超
• Lighthouseで「Reduce JavaScript execution time」や「Minimize main-thread work」の警告が出る
• ページ表示後にメニューやスライダー、フィルター、フォームの反応が遅い
• 広告やチャット、解析スクリプトがレポートで高コストと表示される
• 特に低価格Android端末でスクロール・タップの遅延が目立つ

TBT値を200ms未満に抑えることが、情報サイトでは良好な目安です。複雑なECやSaaSサイトではdefer・asyncだけでは足りず、コード分割や不要パッケージ削除、キャッシュ、サーバー応答速度改善、重要CSS調整も必要になります。それでも遅延JavaScript読み込みは、ほとんどのサイトで最初に取り組むべき即効性の高い対策です。

deferとasyncとは

HTMLのscriptタグを通常使うと、ブラウザはHTML解析を一時停止し、JavaScriptをダウンロード・実行した後にページ描画を再開します。これは重要なスクリプトには必要ですが、どのファイルにも無条件で使うと無駄な待ち時間を生みます。deferとasync属性はこの挙動を変更し、ダウンロードや実行タイミングをコントロールします。

deferの仕組み

defer付きスクリプトはHTML解析を継続しながらバックグラウンドでダウンロードされ、HTML文書の解析が完了した後に実行されます。複数のdeferスクリプトはHTMLの記述順に実行されるため、依存関係のあるJavaScriptには安全です。例えばライブラリ→テーマスクリプトの順に動作させる場合、deferが適しています。

例: <script defer src="/js/app.js"></script>。この場合、app.jsはページ描画を妨げずにダウンロードされ、DOMが準備できた後で順番通り実行されます。現代ブラウザではdeferが広くサポートされ、古典的なスクリプト最適化の定番手法です。

asyncの仕組み

async付きスクリプトもHTML解析を継続しながらダウンロードされますが、ダウンロード完了時点ですぐに実行されます。この間、HTML解析は一瞬停止することがあります。asyncは順番保証がなく、先にダウンロードされたものが先に実行されます。独立した解析タグ、広告、ピクセル、外部ウィジェットやSNSスクリプトに適しています。

例: <script async src="/js/analytics.js"></script>。このファイルは他のローカルスクリプトを待つ必要がありません。もしanalytics.jsが後で定義される変数やjQueryなどに依存していればasyncはエラーの原因になります。asyncは高速ですが、分類を慎重に行う必要があります。

deferとasyncの比較表

実践ルール：順番通り動作が必要ならdefer。完全に独立ならasync。迷ったらまずstaging環境でdeferを試し、コンソールエラーや重要操作を確認しましょう。ステージング環境とバックアップガイド

遅延JavaScript読み込みの実践ステップ

全てのscriptタグにdeferやasyncを付けると、一時的にスコアが上がるように見えても、本番サイトでは決済や検索、メニュー、フォーム認証、カートなど重要機能が壊れる場合があります。健全な導入には計測・分類・小規模変更・テスト・監視のサイクルが必要です。

1. 現状パフォーマンスを計測

まず基準値を記録します。PageSpeed Insightsでスマホ・PCスコアを保存し、LighthouseでTBT・First Contentful Paint・Largest Contentful Paint・Speed Indexなどをメモ。Chrome DevToolsのPerformanceタブでメインスレッドを観察し、長い黄色ブロック（JavaScript解析や実行のコスト）を確認します。

例：初期値としてモバイルTBT 780ms、JavaScript実行時間2.8秒、main-thread work 4.5秒。最適化後にTBTが280msに下がれば約64%改善です。こうした具体的な記録は、チームで効果を共有するのに有効です。

2. スクリプトの棚卸し

ページのソースコードやNetworkタブで全JavaScriptファイルを一覧化し、各ファイルの由来・サイズ・必要タイミング・依存関係を把握します。次のように分類すると効率的です：

• 重要スクリプト：初期表示や基本ナビゲーションに必要なコード
• 依存型ローカルスクリプト：テーマ、スライダー、ギャラリー、アプリモジュール
• 独立した外部スクリプト：解析、広告、ピクセル、チャット、SNS
• 不要・古いスクリプト：未使用プラグイン由来のファイル
• 条件付きロード：お問い合わせページのみフォーム認証等

最良の最適化はdeferを付けることではなく、不要スクリプトを削除すること。90KB圧縮ファイルでもモバイルでは解析・実行込み300ms以上のコストになります。まず不要を削除し、残りを遅延させるのが正攻法です。

3. deferを適用するファイル選定

通常、テーマスクリプト、メニュー、スライダー、商品ギャラリー、アプリバンドルはdeferに適しています。ただしdocument.writeなど旧式でブロックしやすいコードや、DOM準備前に動作が必須な場合は注意。

WordPressテーマではjquery-migrateやメインファイル、プラグインスクリプトに複雑な依存があることも。jQueryコアをasyncにすると多くのプラグインが動作順を待つため、リスクが高いです。jQuery依存ファイルはdeferを慎重に適用、プラグイン側で最適化されたロード設定を使うのが安全です。WordPress速度最適化ガイド

4. asyncを適用するファイル選定

Google Analytics、広告タグ、Facebook Pixel、LinkedIn Insight Tag、外部チャットウィジェット、SNS共有コードはasyncの候補です。しかし全ての外部スクリプトが同じではありません。チャットツールはページロード時にユーザーセッションを作る場合があり、広告システムはコンテナ順を待つ場合も。ドキュメントで仕様を確認しましょう。

独立解析コードをasyncにしてもユーザー体験へ悪影響は少ないですが、データ欠損リスクを減らすためリアルタイムレポートのトリガー管理を行いましょう。タグマネージャー利用時は全タグを1コンテナにまとめず、トリガー条件を調整。例：コメントフォームの無いページではコメント追跡スクリプト、商品ページ以外では商品エンゲージメントスクリプトを読み込まないようにします。

5. 条件付き・イベントベース読み込み

deferやasyncは良いスタートですが、さらに進んでユーザーの行動に応じてJavaScriptを読み込めばTBTへの効果は大きくなります。例えばチャットボックスはページ表示直後でなく、ユーザーが5秒滞在したりヘルプボタンを押した時に読み込む。地図埋め込みコードはユーザーがお問い合わせセクションにスクロールした時だけ読み込む。動画プレイヤーは再生ボタンを押した時にスクリプトを呼ぶ。

この手法は情報サイトや企業サイトで特に効果的です。すべてのページで全てのウィジェットが必要なわけではありません。初期ロードで200KBのJavaScriptを削減すれば、低スペック端末でTBTを数百ms短縮できます。

6. テスト・段階的リリース

変更は直接本番に入れず、テスト環境で試しましょう。トップページ、カテゴリ、商品・サービス、問い合わせ、ログイン、決済など重要ページで手動テスト。ブラウザコンソールのエラー確認（特に「Cannot read property」「is not defined」などの順序・依存問題）が必須です。

本番移行は小規模グループで段階的に。まず外部スクリプト、次いでテーマスクリプトへ。変更ごとにLighthouseレポートを同じネットワーク・端末環境で再計測。単一計測に頼らず、3回平均値を取ると精度が高まります。

WordPressサイトでのdefer/async実装アドバイス

WordPressではJavaScriptはテーマやプラグインからwp_enqueue_script関数で読み込まれます。2026年現在の最新WordPressではスクリプト戦略を細かく設定できますが、旧テーマやページビルダー、互換性の低い最適化プラグインは競合を起こすことも。

パフォーマンスプラグインを利用する場合、全JavaScriptを一括遅延するのではなく除外リストを作りましょう。決済、会員ログイン、管理バー、セキュリティ認証、キャプチャ系スクリプトは慎重に。WooCommerce利用サイトではカートパーツ、決済ゲートウェイ、バリエーション選択スクリプトを必ずテスト。WooCommerceホスティングソリューション

WordPressでの実践順序：まず不要プラグインを削除。次に必要ページだけで読み込みたいプラグインファイルを条件付きで。テーマ・プラグインのスクリプトはdeferを試し、最後に独立外部コードでasyncや遅延ロード方式を使う。これで大きなトラブルのリスクを減らせます。

独自開発・フレームワークプロジェクトでの留意点

React, Vue, Angular, Next.js, Nuxtなど現代的な開発環境では、JavaScript最適化はHTMLタグへのdefer付与だけではありません。パッケージ容量、コード分割（code splitting）、ツリーシェイク、動的インポート、ハイドレーションコストがTBTへ影響します。巨大バンドルファイル（例700KB）はdeferしても実行段階でメインスレッドが長時間ロックされます。

独自開発ではルートごとのコード分割が必須。トップページで管理パネルやグラフライブラリ、エディタコードを読み込まないように。重いコンポーネントは動的インポートで必要時のみ呼び出し。不要依存はパッケージ解析ツールで特定。巨大な日付・グラフ・アニメーションライブラリより軽量代替を検討。

サーバーサイドレンダリングや静的生成でも油断は禁物。HTMLだけ早くてもハイドレーションで多数コンポーネントが一斉にアクティブ化されるとTBTが上昇。インタラクティブでない内容は不要なクライアントJavaScriptを避けるのが2026年のパフォーマンス新常識です。

ホスティング・サーバー応答・JavaScriptパフォーマンスの関係

TBTはブラウザ側JavaScript実行時間に直結しますが、ホスティングインフラも間接的に影響します。TTFB遅延、圧縮不足、HTTP/2/3非対応、キャッシュ不備、遠隔拠点由来の遅延はJavaScriptファイルの到着を遅らせ、ページライフサイクルを長引かせ、ユーザー体験を損ないます。

良質なホスティングはBrotliやGzip圧縮、強力なキャッシュ、最新PHP、高速ストレージ、CDN連携で最適化を支援。SSL証明書の正しい設定も現代ブラウザ機能、HTTP/2、安全な外部連携に重要。Hostragons SSL証明書 Hostragons ドメイン検索

例：同じJavaScriptが圧縮なし320KB→Brotliで95KBに。TBTは実行コストなので直接比例しませんが、ダウンロード時間が短縮されリソース優先度が向上し、全体のロード体験が改善されます。defer・async・キャッシュ・適切なホスティングを総合的に考えるべきです。

計測・検証チェックリスト

最適化の成否はPageSpeedスコアだけでは分かりません。下記チェックリストで実際の効果を評価しましょう：

• モバイルTBT値の最適化前後比較
• JavaScript実行時間レポートで高コストファイルの減少
• Chrome DevTools Performanceの長期タスク減少
• コンソールにJavaScriptエラーが無いか
• メニュー、検索、フィルター、フォーム、カート、決済が正常動作
• 外部解析・広告タグが正しくトリガーされているか
• 実際のユーザーデータでINPや操作遅延が改善されているか
• キャッシュクリア後に再テストしているか

ここで重要なのはラボ（Lighthouse）と実ユーザー（フィールド）データの区別。TBTはラボ指標、実際の体験ではInteraction to Next Paint（INP）がより重要になっています。TBTの改善は多くの場合INPの向上につながりますが、メインスレッドのブロックを減らすことが根本解決となります。

よくある失敗例と回避策

全スクリプトをasyncにする

これが最も多いミス。asyncは順序保証が無く、依存ファイルでランダムエラーが発生します。ページによっては正常でも、低速回線や異なるブラウザで崩れることも。依存関係がある場合はdeferが安全です。

jQueryや依存プラグインの誤った遅延

WordPressでは多くのプラグインがjQueryの順序に依存。jQueryコアをasyncにするとプラグイン側がjQuery未ロード時に動作しエラー。解決策は依存ネットワークを把握し、重要ファイルを除外リストへ。

外部スクリプトの管理不足

サイト運営者はテーマファイル最適化に集中し、広告・チャット・解析コードを見落としがち。Lighthouseで重いタスクの多くは外部由来。未使用タグ削除、条件付きトリガー、ユーザー操作による遅延ロードが重要です。

計測せずにプラグイン導入

パフォーマンスプラグインは有用ですが、計測なしの導入は新たなJavaScript・CSS負荷を招くことも。まず問題箇所を特定し、ツールがTBTを本当に下げているかレポートで検証しましょう。

キャッシュ・ミニファイ競合を無視

ミニファイ・結合・defer・asyncを同時適用するとファイル順序が変わり、本番環境で予期せぬエラーが発生します。特にCDN・サーバーキャッシュ・アプリキャッシュ併用時は、変更後全レイヤーのキャッシュをクリアしましょう。

現実的な最適化シナリオ

中規模企業サイトのトップページで18件のJavaScriptリクエストがあると仮定。5件はテーマ・メニュー、4件はスライダー・アニメーション、3件はフォーム・地図、6件は解析・ピクセル・チャット。初期LighthouseモバイルTBT値920ms。

まず不要アニメーションプラグイン2件を削除し、140KB圧縮JavaScriptを減らすとTBTは760ms。次にテーマ・スライダーをdefer化、順序依存をテストしTBTは480ms。地図スクリプトは問い合わせセクション到達時だけ読み込み、チャットは7秒後に起動、解析・ピクセルはasync化。最終TBTは210ms。

この例から分かるように、単一の設定よりも多層的なアプローチが肝心。defer・asyncは強力ですが、不要コード削除・条件付きロード・適切キャッシュ・良質インフラと組み合わせて最大効果となります。

まとめ：TBT改善に向けたバランスの取れたJavaScript戦略

JavaScriptの遅延読み込みは、TBT短縮の最も実践的・効果的な手法です。deferは順序・DOM後実行が適したファイルに安全、asyncは独立外部スクリプトの柔軟なロードに最適。成功の鍵は、まず計測・分類・不要ファイル削除・段階的テスト・実ユーザー体験の監視です。

Hostragonsの高速・安全・スケーラブルなインフラは、JavaScript最適化・キャッシュ・SSL設定と組み合わせてより安定したウェブパフォーマンスを実現します。TBT改善を目指すなら、まず現状レポートを把握し、計測可能な小さなステップで進めましょう。適切なホスティングとパフォーマンス基盤はHostragonsの各種ソリューションでご検討ください。Hostragons ウェブホスティングパッケージ

よくある質問

deferとasyncを同時に使える？

通常のscriptタグでdeferとasyncを同時に指定すると、現代ブラウザではasyncが優先され、順序保証がなくなります。実際には同じファイルで併用は非推奨。依存ファイルはdefer、独立ファイルはasyncが安全です。

遅延JavaScript読み込みでSEO順位が直接上がる？

直接の順位保証はありませんが、ページ体験・操作速度・Core Web Vitalsの改善によりSEO成功を後押しします。より速い反応のページはユーザー満足・コンバージョン・クロール品質の向上につながります。

全JavaScriptにdeferを付けて安全？

いいえ。一部スクリプトは初期動作や特定順序が必要な場合も。各ファイルの目的・依存・実行タイミングを確認し、変更はテスト環境で検証しましょう。

TBT改善にdefer・asyncだけで十分？

小規模・中規模サイトでは大きな効果が期待できますが、重いフレームワークや多数の外部コード・巨大バンドルを持つ場合は追加対策が必要。コード分割、不要JavaScript削除、条件付きロード、キャッシュ、強力なホスティングも併用しましょう。

WordPressでasyncにしてはいけないスクリプトは？

jQuery依存プラグイン、決済・カートスクリプト、フォーム認証、セキュリティ認証、重要テーマ機能は無闇にasyncにしないこと。順序が崩れるとユーザー操作が妨げられます。まずdeferを試し、必要なら除外リストを作りましょう。