Lighthouseの「クリティカルなリクエストチェーンの回避」を修正する
「クリティカルなリクエストチェーンの回避」の概要
クリティカルなリクエストとは、ブラウザが高い優先度で取得するネットワークリクエストです。
ページやスクリプトが複数のリソースを高い優先度で次々とダウンロードさせる状態を、クリティカルなリクエストチェーンと呼びます。
ブラウザは、これらのクリティカルなリソースがすべてダウンロードされるまで、ページのレンダリングと描画を（完全には）開始しません。そのため、どのクリティカルなリソースもページの初回レンダリングをブロックする可能性があります。クリティカルなリクエストチェーンが大きくなるほど、First Contentful PaintとLargest Contentful Paintの遅延が大きくなります。
最終更新: 2026年3月 Arjen Karel
ダウンロード優先度の決定方法
クリティカルなリクエストは、初期ページロード時に高い優先度でダウンロードされるリソースです。この優先度はどのように決定されるのでしょうか。
ダウンロード優先度はブラウザ自身が決定します。ブラウザは一定のルールに従って各アセットの優先度を決定します。最終的にどの要素が最も高い優先度を得るかは、ページの構造に依存します。ページの初回レンダリングに必要だとブラウザが判断した要素に、最も高い優先度が与えられます。
ブラウザは最初、どの要素が最も重要かを経験則に基づいて推測します。一般的に、ダウンロード優先度は次のようになります。HTMLが常に最も優先度が高く、次にスタイルシート、同期JavaScript、フォント、AJAXリクエスト、ページ上部の画像、ページ下部の画像、最後に非同期JavaScriptの順です。
fetchpriority属性を使用すると、これらの優先度を上書きできます。fetchpriority="high"を設定すると、ブラウザが通常推測するよりもそのリソースが重要であることを伝えます。fetchpriority="low"を設定すると、その逆になります。この属性は現在93%のブラウザでサポートされています。完全なガイドについては、リソースの優先度設定とCore Web Vitalsを参照してください。
ページ上でどのリソースに高い優先度が与えられているかを確認できます。Ctrl+Shift+JでDevToolsを開きます。Networkタブに移動し、列名を右クリックして「Priority」を選択します。
クリティカルなリクエストチェーンはページロード時間にどう影響するか
ページをロードする際、ブラウザは「ディスプレイブロック」モードで開始します。このモードでは、最も重要なリソースが高い優先度でダウンロードされます。これらがクリティカルなリソースです。
ブラウザは、すべてのクリティカルなリソースがダウンロードされるまでページのレンダリングを（完全には）開始しません。そのため、どのクリティカルなリソースもページの初回レンダリングをブロックする可能性があります。
ページのクリティカルなリソースが少ないほど、最初のコンテンツを画面に表示するためのブラウザの作業が減り、CPUや他のリソースの競合も少なくなります。
2025 Web Almanacによると、render blockingリソース監査に合格するモバイルページはわずか15%です。つまり、ウェブの85%は依然としてクリティカルチェーンの問題を抱えています。これが、モバイルオリジンのわずか55%しかFirst Contentful Paintで「良好」スコアを獲得できない主な理由の1つです。CoreDashが監視するサイト全体で見ると、クリティカルチェーンのリクエストが3つ未満のオリジンのFCP中央値は1.2秒ですが、8つ以上のチェーンリクエストを持つオリジンでは2.4秒です。
注意: Lighthouse 13（2025年10月）以降、この監査は「Network Dependency Tree」インサイトに変更されました。概念は同じです。Lighthouseは高い優先度のネットワークリクエストのチェーンを分析し、深すぎる場合に警告します。
Lighthouseの「クリティカルなリクエストチェーンの回避」を修正する方法
クリティカルなリクエストの影響を減らすには、3つの方法があります。
- クリティカルなリソースの数を減らす。 リソースを削除または遅延させ、クリティカルなリソースを非クリティカルなリソースに変換します。
- クリティカルなバイト数を減らす。 クリティカルパス上のリソースサイズを減らすと、ダウンロードが速くなります。GzipやBrotli圧縮、JavaScriptのツリーシェイキング、画像最適化、フォントのサブセット化などがすべて有効です。
- クリティカルパスのダウンロード順序を改善する。 プリロードなどのリソースヒントを使用してリソースの検出プロセスをスキップし、クリティカルなリソースができるだけ早くダウンロードされるようにします。HTTP 103 Early Hintsを使用すると、HTMLが到着する前からリソースのプリロードを開始できます。
どの選択肢が最適かは、リソースのファイルタイプによって異なります。
1. HTML
HTML自体は常に最も高い優先度でダウンロードされます。ページは常にクリティカルなリクエストチェーンの一部です。そのため、最適化する際にまず検討すべきはページ自体です。
コンテンツの遅延ロード: Google自身を含む多くの大規模サイトが、この手法を使用してクリティカルなリクエストチェーンを減らしています。例えば検索結果ページでは、すぐには必要ないコンテンツの一部をAJAXリクエスト経由で後からロードします。
ミニファイ: サイズは小さいほど高速です。HTMLミニファイを利用して、ページからコメント、スペース、空白行を削除します。
圧縮: BrotliやGzipでHTMLを圧縮します。Brotliは通常、Gzipよりも15〜20%高い圧縮率を達成します。
2. スタイルシート
ページのhead内にあるスタイルシートは常にクリティカルです。スタイルがないと、ブラウザはページがどのように見えるか分かりません。そのため、スタイルシートはクリティカルなリクエストチェーンの標準的な構成要素です。
Critical CSS: CSSチェーンを断ち切る最も効果的な方法は、クリティカルなCSSを<head>内の<style>タグに直接インライン化することです。これにより、render blockingなネットワークリクエストが完全に排除されます。クリティカルなCSSは、NodeJSツールやCritical CSS Generatorを使用して生成できます。クリティカルなCSSをインラインで配置し、残りのCSSを低い優先度でロードします。
<link rel="preload"
href="css.css"
type="text/css"
as="style"
onload="this.onload=null;this.rel='stylesheet';"/>
この状態だと、ページ上で奇妙な現象が起こります。最初にスタイルなしでページが表示され、CSSの読み込み後にスタイルが適用されます。すべてのコンテンツが、スタイルなしからスタイルありの状態へと点滅します。だからこそクリティカルなCSSが必要です。ページの表示部分に必要なCSSルールをインライン化することで、ページは即座に正しく表示され、残りのCSSはrender blockingせずにロードされます。
CSSの @import チェーンの回避: CSSファイルが他のCSSファイルをロードするために@importを使用している場合、ブラウザがファイルBが必要だと気づく前にファイルAをダウンロードしなければならないチェーンが形成されます。@importステートメントは個別の<link>タグに置き換えるか、ビルド時にファイルを結合してください。これは、不必要に深いクリティカルチェーンの最も一般的な原因の1つです。
メディアクエリ: デバイスが必要とするスタイルのみをロードします。訪問者がモバイルの場合、デスクトップ用や印刷用のスタイルをダウンロードする必要はありません。media属性を使用して、一致しないデバイスに対してスタイルシートがブロックしないようにします。
<link href="all.css" rel="stylesheet" media="all"> <link href="print.css" rel="stylesheet" media="print"> <link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">
ブラウザは、media属性が現在のデバイスに一致するスタイルシートのみを高い優先度でダウンロードします。一致しないスタイルシートは低い優先度でダウンロードされ、レンダリングをブロックしません。
ミニファイ: 未使用のCSSを削除します。多くのサイトでBootstrapなどのCSSライブラリが使用されています。これらのライブラリは多くの場合、機能が過剰であり、すべてのスタイル宣言が使用されるわけではありません。CSSプリプロセッサ（Sassなど）を使用してこれらのライブラリを編集し、未使用のスタイルグループを削除します。プリプロセッサはまた、すべてのスペースや改行を削除することでCSSをミニファイします。「remove unused CSS」の修正方法も参照してください。
圧縮: BrotliやGzip圧縮を使用してスタイルシートを圧縮します。
3. JavaScript
ページのhead内にあるJavaScriptファイルは、デフォルトで高い優先度でダウンロードされ、ダウンロードおよび実行中にページのレンダリングをブロックします。そのため、JavaScriptはクリティカルなリクエストチェーンの標準的な構成要素です。
DeferとAsync: asyncまたはdefer属性を通じてJavaScriptファイルを非同期でロードすることで、優先度を調整します。asyncスクリプトは並行して低い優先度でダウンロードされます。deferスクリプトも並行してダウンロードされますが、実行はHTMLの解析が完了するまで遅延されます。完全な比較については、asyncとdeferの比較、およびCore Web Vitalsへの影響を参照してください。
// ロードと実行をブロックします <script src="normalscript.js"></script> // asyncはロード中はブロックしませんが、実行中はブロックします <script async src="asyncscript.js"></script> // deferはロード中も実行中もブロックしません <script defer src="deferscript.js"></script>
JavaScriptを遅延させるその他の手法については、JavaScriptを遅延またはスケジュールする16の方法を参照してください。遅延できない未使用のJavaScriptがある場合は、未使用のJavaScriptを削減する方法を参照してください。
コード分割とプリロード: ページがJavaScriptの非同期ロードを許可しない場合は、JavaScriptを複数のファイルに分割します。ページロード時にクリティカルな部分を小さなファイルに配置してプリロードします。非クリティカルなJavaScriptは別のファイルに配置し、deferまたはasyncでロードさせます。
ミニファイ: JavaScriptミニファイアを使用してバイト数を縮小します。webpack、Rollup、Viteなどの最新のバンドラーは、内部でterserを使用してJavaScriptを分析し、可能な限り小さくします。
圧縮: GzipやBrotli経由でJavaScriptを圧縮して、バイト数を削減します。
4. Webフォント
Webフォントは通常、クリティカルなリクエストチェーンの最後のファイルになります。これはWebフォントが検出に依存しているためです。ブラウザは必要だと判明したときにのみフォントをロードします。そのためには、ブラウザはまずHTMLを解析し、スタイルシートでどのフォントが使用されているかを確認する必要があります。
プリロード: フォントを使用することがわかっている場合、そのフォントをプリロードする方が高速です。フォントができるだけ早くダウンロードされるため、クリティカルなリクエストチェーンへの影響を最小限に抑えられます。ページのhead内の可能な限り早い位置にこのコードを追加して、フォントをプリロードします。
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
フォント戦略: フォントのロードを高速化する方法は他にもたくさんあります。Google Fontsをセルフホストする方法やWebフォントのロード中にテキストが非表示にならないようにする方法を参照してください。
- 常にセルフホストのWebフォントを使用し、Google Fontsのようなリモートホストのフォントは使用しない。
- フォントのサブセット化によりフォントサイズを縮小する。
- FontFace APIを通じて非クリティカルなフォントをロードする。
font-display: swapを使用して、フォントが初期レンダリングをブロックするのを避ける。- フォント合成を通じてブラウザに独自のフォントバリアントを生成させる。
5. 画像
ページロード中に表示可能なviewport内に現れる画像にも高い優先度が与えられることがあり、クリティカルパスに干渉する可能性があります。画像が常にウェブサイトの表示領域に表示されることが確実な場合は、その画像をプリロードしてください。fetchpriority="high"を追加して、それがページで最も重要な画像であることをブラウザに伝えます。
<link rel="preload" as="image" href="important-image.webp">
すぐには表示されないすべての画像については、lazy loadしてください。loading="lazy"を使用して、画像が表示される直前までロードを遅延させます。
<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">
6. AJAXリクエスト
AJAXリクエストには常に高い優先度が割り当てられます。そのため、AJAXリクエストはページのレンダリングが完了するまで延期してください。ページが「load」イベントを送信するまで待機します。
window.addEventListener('load', (event)=>{
console.log('AJAXリクエストに適したタイミングです');
});
AJAXリクエストを延期できない場合は、リソースをプリロードして、ブラウザがより早く利用できるようにすることができます。
7. Iframe
Iframeは通常、高い優先度でダウンロードされます。iframeは実際にはページ内のページであるため、ページのロード時間を大幅に遅延させる原因になります。iframeが必要とするリソースも高い優先度でダウンロードされ、独自のクリティカルなリクエストチェーンを形成する可能性があります。そのため、iframeの使用はCore Web Vitalsに重大な影響を与える可能性があります。
loading="lazy"属性を使用すると、iframeのロードを遅延させることができます。ロード中にiframeがすぐに表示されない場合、これは多くの場合大きな違いをもたらします。タイミングをさらに細かく制御するには、JavaScriptを通じてiframeを挿入し、クリティカルなリクエストチェーンに含まれないようにします。この手法の例については、PageSpeedを落とさずにGoogle Mapsを埋め込む方法と完璧なCore Web VitalsでYouTubeを埋め込む方法を参照してください。
改善の検証
クリティカルチェーンの最適化後は、Real User Monitoringで改善を検証してください。FCPとLCPの両方が改善するはずです。Lighthouseのようなラボツールは即座にフィードバックを提供しますが、Core Web Vitalsにとって重要なのは実際のユーザーからのfield dataです。
