LighthouseのRender-blocking requests：修正方法

render blockingなリクエストはスコアを低下させますか？

Lighthouseは、初回ペイントまでにページが読み込みを待機したすべてのスタイルシートとスクリプトを「Render-blocking requests」インサイト（Lighthouse 13以前の名称は「Eliminate render-blocking resources」。「リクエストがページの初回レンダリングをブロックしており、LCPが遅延する可能性があります」）に一覧表示します。このインサイト自体はスコアに直接カウントされません。しかし、CSSやスクリプトを待っている間、画面は白いままになります。そのため、特にスマートフォンでFCPとLCPが遅延します。CSSを削減・結合し、スクリプトをdeferしてください。

Render-blocking requestsインサイトは何をチェックしていますか？

Lighthouseの説明にはこう記載されています。「リクエストがページの初回レンダリングをブロックしており、LCPが遅延する可能性があります。deferまたはインライン化によって、これらのネットワークリクエストをクリティカルパスから外せます。」ただしインライン化は解決策になりません。詳細は後述します。表にはURL、Transfer Size、Durationの3列があります。Transfer Sizeは圧縮されて送信されたファイルサイズです。Durationは、別ドメインへの新規接続時間も含め、低速なスマートフォンでそのリクエストにどれだけ時間がかかるかをLighthouseが推計した値です。

Chromeはページの読み込み中、各リクエストがrender blockingかどうかを判定し、トレースに記録します。Lighthouseはそのトレースを読み取り、メインフレーム内でChromeがブロッキングと判定し、かつ初回ペイント前に完了したすべてのリクエストを一覧化します。実際には、<head>内のスタイルシートや同期スクリプト、そしてそれらが@importで読み込むファイルが該当します。body内のスタイルシートはChromeの優先度がHighest、スクリプトはHighの場合にのみ対象となります。最初の画像の後はどちらも優先度が下がり、対象から除外されます。しきい値はありません。該当するファイルが1つでもあると、インサイトは不合格になります。

ページの表示を遅くしている場合でも、一覧に表示されないファイルもあります。asyncスクリプト、スクリプトによってページに追加されるファイル（gtm.js、gtag.js）、インラインのスタイルやスクリプト、iframe内の全リソース、フォントなどです。

WooCommerce商品ページでのインサイト表示。Lighthouse 13.5.0、PageSpeed Insightsと同様のシミュレーションスロットリング。

何がファイルをrender blockingにするのですか？

render blockingとは、そのファイルが読み込まれるまでブラウザが何も描画しない状態を意味します。<head>内のすべてのスタイルシートが到着し、すべての同期スクリプトがダウンロードされて実行されなければなりません。

• スタイルシートの後にあるスクリプトは、そのスタイルシートの到着を待ちます。Chromeは手前にあるCSSが到着するまで同期スクリプトを実行せず、パーサーはスクリプトの完了を待機します。両方のファイルが並行してダウンロードされたとしても、まずCSSを待ち、その後にスクリプトを待つことになります。
• @importは開始が遅れます。ChromeのプリロードスキャナーはHTML内のリンクを一括で見つけますが、CSSファイル内の@importはそのCSSが届いてからしか検出できません。以下の商品ページでは、インポートされたテーマのスタイルシートの読み込み開始は1.28秒でした。HTMLから直接リンクした場合は0.59秒でした。
• 別ドメインは接続コストがかかります。fonts.googleapis.comやCDN上のスタイルシートは、最初の1バイトが届く前にDNS、TCP、TLSの処理が必要です。

render blockingなリクエストはFCPとLCPに影響しますか？

head内に9個のスタイルシートと2個のスクリプトを持つWooCommerceの商品ページを使い、Slow 4G接続のスマートフォン環境で計測しました。修正版では、CSSを削減して6.6 kBのスタイルシート1つに結合し、両方のスクリプトをdefer化しました。読み込み完了後の見た目は全く同じです。

FCP

元のページでは初回ペイントが2.12秒でしたが、修正版では1.39秒になりました。

スロットリング環境のスマートフォンで1.4秒時点の比較。修正前はまだ画面が白いままです。

LCP

LCPは初回ペイントより前に発生することはありません。このページでのLCP要素は商品写真ですが、写真もCSSが届くまで表示されません。修正によってLCPは2.25秒から1.91秒へと短縮されました。LCPの内訳では、この待機時間は要素の描画遅延（element render delay）として現れます。Lighthouseはこの短縮を表示しません。LCP要素が画像の場合、LCPの削減見込みを常に0 msと推定するためです。LCPに効果がないと誤解しないでください。

どのくらいのサイトが影響を受けていますか？無視しても安全ですか？

ほぼすべてのサイトです。CrUXデータを持つ114,526サイトのホームページを調査したState of CWVによると、92.8%のサイトに少なくとも1つのrender blockingなリクエストが存在します。91.2%がブロッキングスタイルシート、62.5%がブロッキングスクリプトを抱えています。該当するリクエストが存在する場合、中央値は8件（110 kB）で、5サイトに1サイトは20件を超えています。（State of CWVはhead内のスタイルシートと同期スクリプトを集計しており、Lighthouseの一覧とおおむね一致します。）

これらのリクエストが多いサイトは、実際のfield dataでも悪化しています。リクエストがゼロのサイトでは84.0%がスマートフォンで良好なFCPを維持しているのに対し、20件を超えるサイトでは54.1%にとどまります。ただし、この低下の主な要因はサーバーです。同じ比較範囲でTTFBの中央値が538 msから1,114 msへと倍増しています。サーバー速度別に分けると次のようになります。

render blockingなリクエスト数およびサーバー応答時間別の、スマートフォンで良好なFCPを達成しているサイトの割合。State of CWV（2026年10月、スマートフォンのCrUX p75、良好なFCPは1.8秒以下）。

• 高速なサーバー（TTFB 600 ms未満）：件数に関係なく、94〜97%が良好なFCPを達成しています。それでも遅延は生じており、最初の1バイトから初回ペイントまでの時間は、ブロッキングリクエストが21件以上ある場合、ゼロ件の場合と比べて約150〜200 ms長くなります。
• 低速なサーバー（TTFB 900 ms以上）：ブロッキングリクエストが2件以下のサイトでは約半数（47〜53%）が良好なFCPを達成していますが、21件以上では30%まで落ち込みます。TTFBが900 ms以上ある場合、FCPの「良好」の基準である1.8秒まで残りは0.9秒未満しかありません。描画待機を増やすリクエストが1つ加わるだけでも、FCPが基準値を超えてしまいます。

WordPressサイトは特に多く、57%が16件以上のブロッキングリクエストを持っています（中央値は19件、163 kB）。サーバー速度が同じでも、高速なホストでは1〜5件のサイトと比べて良好なFCPの割合が3ポイント低下し、低速なホストでは約10ポイント低下します。

これは相関関係ですが、対応の優先順位がわかります。TTFBが遅いなら、まずサーバーを改善してください。高速なサーバー環境であれば、自前のCSSを改善して150〜200 msを削る価値があります。以下のケースでは警告を放置しても問題ありません。

• Lighthouseに検出されている自前のスタイルシートが1〜2件のみで、各サイズが約15 kB未満の場合。
• 検出されたファイルが同意管理ツール、A/Bテストのスニペット、または変更不可能なプラットフォーム側のファイルである場合（詳細は後述）。

field dataでrender blockingなリクエストを見つけるには？

Lighthouseはキャッシュのない初期状態でページを1回読み込みます。しかし実際の訪問者は最初のページ以降、キャッシュにCSSを保持しているため、field dataでの悪影響は主に訪問者が最初に開くページに現れます。CoreDashのモバイルデータで、次の2点を確認してください。

• FCPとTTFBの差。render blockingなファイルによる遅延は、最初の1バイトから初回ペイントまでの間に発生します。他のテンプレートと比べてこの差が大きいテンプレートは、より多くのブロッキングファイルを読み込んでいます。
• LCPの描画遅延（render delay）。LCPの中で描画遅延の割合が大きいテンプレートを探します。ブロッキングCSSはその待機時間の原因の1つです。そのページにブロッキングCSSが存在するかどうかは、DevTools（次のセクション）で確認できます。

CrUXでもオリジンまたは特定のURLについてp75の同じ指標を確認できますが、どのテンプレートが遅いかまではわかりません。

サンプルショップ（acme-pagespeed.com）でのCoreDashのモバイルp75データ。商品ページとカテゴリーページが遅いことがわかります。

DevToolsでブロックしているファイルを見つけるには？

Chromeでページを開き、Performanceパネルに移動します。ネットワークをSlow 4G、CPUを4x slowdownに設定し、ページの再読み込みを記録します。Insightsサイドバーに「Render-blocking requests」が表示されます。これをクリックすると、Networkトラック内でブロックしている各リクエストが強調表示されます。

各バーはリクエストの開始から最後の1バイトが到着するまでを表します。FCPマーカーの直前に最後に終了しているリクエストを探してください。描画はそのリクエストを待機していました。別のCSSリクエストが終了した後にのみ開始されているCSSリクエストは、@importによるものです。ブロックしているリソースがない場合、サイドバーには「No render-blocking requests for this navigation」と表示されます。

render blockingなリクエストを解消するには？

Lighthouseの表にあるURLを見れば、各ファイルの読み込み元がわかります。修正すべき場所はそこで判断します。

自前のCSSとスクリプト

自前のテンプレートでは、以下のhead構成を目指します。無駄を削減した小さなスタイルシート1つと、すべてdeferを指定したスクリプトです。これにより、初回ペイントが待機するファイルはその1つだけになります。

<link rel="stylesheet" href="/css/main.min.css">
<script src="/js/jquery.min.js" defer></script>
<script src="/js/gallery.min.js" defer></script>

具体的な手順は、後述のCSSの削減と結合から解説します。

WordPress

/wp-content/plugins/以下のファイルはプラグイン、/wp-content/themes/はテーマ、/wp-includes/はWordPress本体のものです。

コードを書かない場合は、最適化プラグインを使い、次の設定を行います。

• スクリプトの遅延読み込み（defer）を有効にする：WP Rocketの「Load JavaScript deferred」、Perfmattersの「Defer JavaScript」、LiteSpeed Cacheの「Load JS Deferred」を設定します。deferされたスクリプトは初回ペイントをブロックしなくなります。ただしjQueryには注意が必要です（後述）。
• 「Load CSS Asynchronously」とcritical CSSはオフのままにする：このインサイトの下にある「クリティカルなアセットをインライン化する」プラグインについての古いWordPress向けTipsに何が書かれていても、オフにしておきます。critical CSSは機能しますが、残りのCSSは初回ペイント後に届くため、ページのスタイルが2度適用され、レイアウトシフト（CLS）が頻発します。さらにインライン化に伴うコストについては、後述のCSSの削減と結合を参照してください。
• 「Remove Unused CSS」はオフのままにする：（LiteSpeed Cacheの「Generate UCSS」）。URLごとに個別のCSSを生成し（WP RocketはHTML内にインラインで挿入）、読み込み時のページで見つかったルールのみを保持します。そのため、後からスクリプトによって変化する要素（開いたメニューやスライダーなど）のスタイルが崩れるリスクがあります。WP Rocketには、これが原因で起きる表示崩れに関する専用のガイドまで存在します。得られる効果に対してトラブルが多すぎます。スタイルシートの削減と結合は自身で行ってください。手間はかかりますが、それに見合う確実な効果が得られます。

多くのプラグインは、フォームのないページでのContact Form 7や、ショップ外のページでのWooCommerceのように、何も機能しないページを含めたすべてのページでCSSを読み込みます。WordPressが出力するすべてのスタイルシートにはcontact-form-7-cssのようなidが付与されています。この「-css」より前の部分がハンドル名であり、不要なページで読み込みを解除するために使用します。

add_action( 'wp_enqueue_scripts', function () {
  if ( ! is_page( 'contact' ) ) {
    wp_dequeue_style( 'contact-form-7' );
  }
}, 20 );

WooCommerceには3つのスタイルシート用の独自フィルターであるwoocommerce_enqueue_stylesがあります。自前のスクリプトに対しては、WordPress 6.3以降であればdefer属性を追加できます。

wp_enqueue_script( 'acme-gallery', get_stylesheet_directory_uri() . '/js/gallery.min.js', array( 'jquery' ), '2.3.0', array( 'strategy' => 'defer' ) );

そのスクリプトに依存する別のスクリプトがブロッキングのままであったり、後ろにインラインスクリプトが追加されていたりすると、WordPressは警告なしにそのdefer指定を解除してしまいます。ページソース内のscriptタグを必ず確認してください。

jQueryのdefer化は、インラインのjQuery(...)呼び出しも適切に処理できるツールでのみ行ってください。WordPressはjQueryをdeferなしで登録するため、何かがjQueryに依存した瞬間にheadをブロックします。手動でdeferを追加すると、それより前に実行されるインラインのjQuery(...)呼び出しがすべてエラーになります。WP Rocketの「Load JavaScript deferred」はjQueryをdefer化しつつ、そうしたインライン呼び出しをラップして保護します。Perfmattersの「Defer JavaScript」は、「Include jQuery」を有効にするまでjQueryを対象外にします。有効にした場合は、ページ内（メニュー、ギャラリー、カートなど）をクリックして正常に動作するか確認してください。

style.cssの先頭に@import url("../storefront/style.css")が記述されている子テーマは、@importの連鎖を作ってしまいます。その行を削除し、wp_enqueue_styleを使って親テーマのスタイルシートを読み込んでください。

Shopify

アプリはアプリ埋め込み（オンラインストア ＞ テーマのカスタマイズ ＞ アプリ埋め込み）を通じてファイルを追加します。埋め込みスクリプトは通常asyncで読み込まれますが（Liquidが独自のscriptタグを出力する場合を除く）、スタイルシートは描画をブロックします。使用していない埋め込みは無効化し、アプリをアンインストールした後はtheme.liquidやスニペット内に残骸コードが残っていないか検索してください。

テーマはtheme.liquid内のstylesheet_tagフィルターを使ってCSSを読み込みますが、これはブロッキングリンクを出力します。基本となる1つのスタイルシートであれば問題ありません。script_tagフィルターはdeferなしのスクリプトを出力するため、このタグは直接記述してください。

<!-- 初回ペイントをブロックする -->
{{ 'gallery.js' | asset_url | script_tag }}

<!-- ブロックしない -->
<script src="{{ 'gallery.js' | asset_url }}" defer></script>

Shopifyはすでにhead内にある最大10個のrender blockingなファイルに対して103 Early Hintsを送信しているため、それらのファイルは早期にリクエストが始まります。改善できる余地は、そのファイルの数とサイズを減らすことです。なお、チェックアウト高速化用のスタイルシートは一覧に残り続けます（詳細は後述）。

Next.js

App Routerでは、CSSのimportがすべてhead上部のスタイルシートリンクになり、それが読み込まれるまでReactは描画を行いません。Next.jsはそれらをいくつかのチャンクにまとめるため、解決策はCSSの総量を減らすことです。一部のルートでのみ使用するCSSは、グローバルCSSからCSS Modulesへ移行してください。ルートレイアウトでimportされたグローバルCSSはすべてのルートに送信されますが、CSS Moduleはそれをimportしたルートにのみ送信されます。詳細はNext.jsがCSSファイルを生成する仕組みを参照してください。

Next.js本体のスクリプトはasyncまたはdeferで読み込まれます。Next.jsサイトでブロッキングスクリプトが発生している場合、それはレイアウトに手動で追加されたものです。next/scriptを使って読み込んでください。デフォルトでは、Next.jsがページのハイドレーションを開始した後にのみ読み込まれます。

import Script from 'next/script'

<Script src="https://example.com/widget.js" strategy="afterInteractive" />

Google Fontsと外部ドメイン

Google Fontsのリンクはfonts.googleapis.comにあるブロッキングスタイルシートであり、フォントファイル自体は別ドメインであるfonts.gstatic.comから取得されます。Lighthouseでこのわずか0.5 kBのファイルに最も長いDurationが表示されるのは、新規接続のコストが加算されるためです。フォントをセルフホストし、自前のスタイルシート内に@font-faceルールを記述すれば、このリクエストと2つのドメインへの接続処理を完全に排除できます。Next.jsでは、next/fontがすでにこの処理を行っています。

同意管理ツール、A/Bテスト、そのままにしておくべきファイル

• 自動ブロック機能を備えた同意管理ツール（Cookiebot、OneTrustのOtAutoBlock、Usercentricsの自動ブロッカーなど）：他のすべてのスクリプトを制御するためにそれらより前に実行される必要があり、設計上あえて同期処理になっています。別の選択肢として手動モードがあり、Cookieスクリプトを各自でマークアップしますが、その労力に見合うかどうかはまず法的な判断が必要です。ツールのドメインに対してpreconnectを設定しておけば、少なくとも接続を早期に開始できます。
• A/Bテストのスニペット（Optimizely、AB Tasty、Convertなど）：テストパターンが表示される前に元の画面が一瞬表示されるのを防ぐため、意図的に同期処理されています。テストを実施していないときは削除してください。
• Shopifyのcontent_for_header：すべてのテーマに必須であり、編集できません。この記事の執筆にあたり調査した5つのストアすべてで、チェックアウト高速化用のブロッキングスタイルシート（accelerated-checkout-backwards-compat.css）が追加されていました。これはそのままにしておいてください。

CSSの削減と結合

render blockingなCSSは数個のスタイルシートにとどめ、圧縮後のサイズをそれぞれ約15 kB未満に抑えてください。15 kBは、新規接続の最初のラウンドトリップで転送できるおおよそのデータ量です。

DevToolsのNetworkパネルにおける、Slow 4G環境での6つのrender blockingなスタイルシート。緑色は最初の1バイトが届くまでの待機時間で、どのファイルも同じです。青色はダウンロード時間で、ファイルサイズに比例して長くなります。

• テーマやプラグインが追加する小さなファイルを結合する。すべてのスタイルシートは、サイズにかかわらず最初の1バイトが届くまでに丸1ラウンドトリップ（Slow 4G環境で約0.6秒）待機します。0.3 kBのファイルのためにその待機時間をまるまる消費するのは無駄です。
• 巨大なファイルを削減または分割する。同じ待機時間の後、14 kBのファイルは0.4秒後に取得が完了しました。一方、60 kBのファイルはダウンロードにさらに1秒かかり、完了するまで画面は白いままでした。
• ページで使用されていないルールを削除する。DevToolsのCoverageタブを使うと、ページで一度も使われていないCSSの割合がファイルごとにわかります。一般的なサイトの中央値では、89%が未使用です（State of CWV、ホームページに対するChromeのCoverage計測）。
• すべてのCSSを1つの巨大なファイルにまとめない。削減を行わずに全CSSを68 kBのファイル1つにまとめたところ、9つのファイルに分かれていたときよりも初回ペイントが遅くなりました。巨大なファイルがdeferされたスクリプトやヒーロー画像と帯域を奪い合ってしまったためです。9つの個別ファイルだったときは、render blockingなリクエストに帯域の大部分が優先的に割り当てられていました。
• CSSをインライン化しない。インラインCSSはHTML内に埋め込まれます。HTMLはブラウザが最初に必要とするファイルであり、他のすべてはHTMLの到着を待っています。つまりインライン化は、誰もが待っている最重要ファイルを肥大化させ、遅くするだけです。さらに重要なのは、ブラウザは通常HTMLをキャッシュできない点です。別個のスタイルシートなら2ページ目以降キャッシュされますが、インラインCSSはページを開くたびに再ダウンロードされます。TTFBが900 ms未満かつブロッキングリクエストが1〜5件のサイトでは、インラインCSSのないサイトの95.9%が良好なFCPを達成しているのに対し、300 kB以上をインライン化しているサイトでは90.8%にとどまります（State of CWV）。
• 「残りの」CSSを後から読み込むように分割しない。従来のmedia="print"を使った手法は、ファーストビューに決して現れないCSSにしか通用しません。すべてのページやすべての画面サイズにおいてそれを正確に把握するのは困難です。判断を誤れば、スタイルが適用されていない崩れた状態で最初に描画されてしまいます。

すべての@importを置き換える

インポートされている各ファイルにHTML内で直接linkタグを指定するか、親スタイルシートに結合してください。検証用の商品ページでは、スクリプトをdefer化した状態で@importを排除したところ、初回ペイントが137 ms前倒しになりました。スクリプトがブロックしたままの状態では33 msの短縮にとどまりました。jQueryがインポートされたスタイルシートとほぼ同時に届いたため、いずれにせよ描画がjQueryの完了を待っていたからです。

スクリプトをdefer化する

初回ペイントに不要なhead内の全スクリプトにdefer属性を追加します。モジュールスクリプトはすでにdefer化されています。async属性もインサイトの一覧からスクリプトを除外してくれますが、初回ペイント前に実行されてmain threadを占有してしまう可能性があるため、基本的にはdeferを選択するのが賢明です。今日、スクリプトはこのインサイトの中では影響が小さい要素です。どちらにせよCSSの完了のほうが遅かったため、2つのスクリプトをdefer化しても得られた短縮は24 msでした。詳細はasyncとdeferの比較、head配置とfooter配置のJavaScript、JavaScriptを遅延読み込み（defer）する14の方法を参照してください。

103 Early Hintsでメインのスタイルシートを先行取得する

103 Early Hintsを使うと、サーバーがHTMLを生成している最中に、取得すべきファイルをブラウザに通知できます。メインのスタイルシートに対してヒントを送信します。

HTTP/2 103
link: </css/main.min.css>; rel=preload; as=style

サーバー側でページの生成に時間がかかっている場合に効果を発揮します。その時間を使ってスタイルシートがダウンロードされるため、得られる効果は最大でもサーバーの処理時間分です。そのため、CDNキャッシュから配信されるページではほとんど恩恵がありません。Cloudflareには専用のトグル（Speed ＞ Settings ＞ Content Optimization）があり、オリジンサーバーが送信するLinkヘッダーをもとにヒントを生成します。Apache 2.4.58以降ではH2EarlyHintディレクティブが使えます。

導入後は必ずLCPを確認してください。CSSが早く届くと、そこで指定されているフォントの読み込みも前倒しになります。検証用の商品ページでは、156 kBのFont Awesomeフォントが商品写真の帯域を奪ってしまい、結果としてLCPが遅くなりました。なお、ヒントを送信したファイルであっても、Lighthouseの一覧には0.0 KiBとして残り続けます。詳細は103 Early Hints、およびリンクしているスタイルシートを単にpreloadしても効果がない理由を参照してください。

スタイルシートへのfetchpriority="low"の指定は避ける

よく見かけるTipsとして、ファーストビューに不要なCSSにfetchpriority="low"を指定するというものがあります。これはアンチパターンです。head内において、Chromeはそのスタイルシートの優先度をHighestからHighへと1段階下げるだけであり、初回ペイント前には依然としてその完了を待ちます。Lighthouseはシミュレーション内で優先度に基づいてブロッキングを判定するため、そのファイルが存在しないかのように扱い、Durationをゼロにしてシミュレーション上のFCPを速く見せかけてしまいます。

実際に4つのスタイルシートにこれを指定してみました。シミュレーションスロットリングを適用したLighthouseでは、FCPが2.03秒から1.60秒へと短縮され、スコアは96から97に上がりました。しかし実機のChromeでは、初回ペイントは2,122 msから2,114 msへとわずか8 ms動いただけでした。訪問者が待たされる時間は以前と全く変わりません。

LighthouseがFCPとして報告した時点でも、Chromeの画面はまだ真っ白なままです。

改善結果を確認するには？

改めてモバイル環境でLighthouseを実行します。今回の改善により、スコアは96から100へ、シミュレーション上のFCPは2.0秒から1.1秒へ向上しました。インサイトの表示も、12件のファイルによる「赤」から、6.6 kBのスタイルシート1件のみの「オレンジ」に変わりました。

Lighthouse 13.5.0、モバイル、シミュレーションスロットリング。

3回実行して中央値を採用してください。同一ページであっても、実行ごとにシミュレーションFCPに1.5秒のばらつきが出ることがありました。

CoreDashでは、修正直後の次回訪問以降のFCPとLCP描画遅延がすぐに反映されます。一方、CrUXやSearch Consoleは過去28日間の集計値であるため、修正から2週間経っても表示内容の半分は修正前のデータのままです。

モバイル環境でFCPやLCPが「要改善（赤）」のままなのは、ブロッキングCSSが原因かどうか確認したいですか？Core Web Vitalsパワーアワーでは、実際のfield dataとページのトレースを一緒に分析し、削減・結合・deferすべきファイルを明確にしてお伝えします。