Lighthouseの「eliminate render-blocking resources」警告を修正する
render blockingリソースを排除し、Core Web Vitalsを改善してください。
「Eliminate render-blocking resources」の概要
ブラウザが<head>内でrender-blockingなCSSやJavaScriptに遭遇すると、すべての処理を停止します。これらのリソースのダウンロードと実行が完了するまで、画面には何も描画されません。これがLighthouseの「Eliminate render-blocking resources」警告の意味です。つまり、<head>内の何かが最初の描画を遅らせているということです。
これらのrender-blockingリソースを削除または遅延させて、このLighthouse警告を解決してください。2025 Web Almanacによると、この監査に合格しているモバイルページはわずか15%です。つまり、ウェブの85%に不要なレンダリングの遅延が発生しています。
Lighthouseの「Eliminate render-blocking resources」警告とは何ですか？
最終更新: 2026年3月、Arjen Karel
LighthouseでEliminate render-blocking resources警告が出る原因は何でしょうか？Lighthouseは、以下のいずれかに該当するページに警告を出します。
- 遅延されていないhead内のscriptタグ。
ページのhead内のスクリプトは、deferまたはasync属性がない場合、デフォルトでrender-blockingになります。 - デバイスのメディアに一致するリンクされたスタイルシート。
<link rel="stylesheet">は、無効化されておらず、ブラウザのメディアに一致する場合、ページのレンダリングをブロックします。たとえば、<link rel="stylesheet" media="print">は画面デバイスでのレンダリングをブロックしません。
render-blockingリソースが多すぎると、First Contentful Paint (FCP)とLargest Contentful Paint (LCP)に直接影響する可能性が高くなります。Vodafoneはrender-blockingなJavaScriptを減らし、LCPを31%改善しました。これは売上の8%増加につながりました。
Web Performance Calendarによると、67.7%のウェブサイトが少なくとも1つのrender-blockingなサードパーティリソースを読み込んでいます。Google Fontsだけでも、580万以上のサイトでrender-blockingなリクエストの原因となっています。
「render-blockingリソース」の原因は何ですか？
render-blockingリソースは常に、ページのhead内にあるスタイルシートとJavaScriptです。つまり、CMS、ウェブ開発者、またはプラグインによってのみ追加されます。render-blockingリソースの発生源を特定する際は、以下の場所を確認してください。
- テンプレート。 ウェブサイトのテンプレートは、最初に確認すべき場所です。<head>コードが配置されている場所を見つけ、ハードコードされたスタイルとスクリプトを探してください。
- CMS。 CMS自体が正常に動作するために、いくつかのスクリプト（jQueryなど）を必要とする場合があります。
- プラグイン。 プラグインは、ページにスタイルやスクリプトを注入することでよく知られています。プラグインが1つのページでしか使用されていない場合でも、すべてのページでリソースを読み込むことがよくあります。
2024 Web AlmanacのJavaScriptの章（スクリプトレベルのデータを含む最新版）によると、87%のページが少なくとも1つのスクリプトでasyncを使用している一方で、個々のscriptタグで実際に使用されているのはわずか49%です。そして、deferを使用しているスクリプトはわずか13%です。ウェブ上のほとんどのスクリプトは依然としてどちらの属性もなしで読み込まれており、つまり、レンダリングをブロックしています。
「Eliminate render-blocking resources」の修正方法
render-blockingリソースを修正するには、それらがレンダリングをブロックしないようにする必要があります。最善の修正方法は、リソースを完全に削除することです。<head>に残っている古くて未使用のスクリプトやスタイルシートは、思っている以上に一般的です。削除できない場合は、遅延させてください。
JavaScriptの遅延
scriptタグにdeferまたはasync属性を追加することで、JavaScriptを遅延させることができます。
<!-- deferred: 並行してダウンロードされ、HTMLのパース後に順次実行されます -->
<script src="script.js"></script>
<!-- async: 並行してダウンロードされ、準備ができ次第すぐに実行されます（順不同） -->
<script src="script.js"></script> 実行順序が保たれるため、ほとんどのスクリプトにはdeferが安全な選択です。アナリティクスのような完全に独立したスクリプトにはasyncを使用してください。ESモジュール（<script type="module">）を使用する場合、自動的にdeferの動作になります。モジュールスクリプトがレンダリングをブロックすることはありません。
JavaScriptのタイミングを制御するすべての方法に関する完全なガイドについては、JavaScriptを遅延させる16の方法を参照してください。asyncとdeferがCore Web Vitalsに与える影響の違いを解説した専門記事もあります。
スタイルシートの遅延
スタイルシートの遅延は、スクリプトの遅延よりも厄介です。スタイルシートを遅延させると、ページは最初にそのスタイルなしでレンダリングされ、読み込みが完了した時点でブラウザがスタイルを適用します。これにより、ちらつきやレイアウトシフトが発生します。そのため、遅延させたスタイルシートとインラインのクリティカルCSSを組み合わせる必要があります。
ステップ1: クリティカルCSSをインライン化する。 クリティカルCSSは、ページの可視部分をレンダリングするために必要な最小限のスタイルセットです。これを<head>内の<style>タグに直接インライン化します。これにより、外部ファイルを待たずに、スクロールせずに見える範囲のコンテンツを描画するために必要なすべてをブラウザに提供できます。クリティカルCSSを手作業で抽出するのは面倒です。自動化するには、Critical CSS Generatorを使用してください。
<style>/* ここにクリティカルCSS */</style> ステップ2: 残りを低優先度で読み込む。 クリティカルではないスタイルシートには、fetchpriority="low"を追加して、このリソースがクリティカルなコンテンツと競合しないようにブラウザに指示します。
<link rel="stylesheet"
href="styles.css"
fetchpriority="low"> 古い記事では、読み込み時にmedia="all"に切り替えるmedia="print"のハックを推奨していることがあります。これは推奨しません。本来の目的ではない機能にmedia属性を悪用しており、壊れやすいonloadハンドラーに依存しているため、ハンドラーが失敗するとスタイルがまったく適用されません。fetchpriority="low"を使用するのが、正しくセマンティックなアプローチです。小細工なしで、意図をブラウザに正確に伝えることができます。
現在のページでまったく必要のないスタイルシート（特定のページタイプでのみ使用されるスタイルなど）については、そのページから未使用のCSSを削除するのが最もクリーンな解決策です。
render-blockingリソースの影響を減らす
render-blockingリソースを排除できないこともあります。テンプレートにアクセスできなかったり、CMSが特定のスクリプトを必要としたりする場合があるからです。影響を減らす方法がいくつかあります。
- スタイルとスクリプトを最小化して圧縮する。
小さなリソースは、大きなリソースに比べて読み込みパフォーマンスへの影響が少なくなります。サーバーでgzipまたはbrotli圧縮が有効になっていることを確認してください。 - クリティカルなリクエストのチェーンを避ける。
render-blockingなスタイルシートが@import経由で別のスタイルシートを読み込む場合、リクエストチェーンが作成されます。2番目のファイルは、1番目のファイルが完全に読み込まれてパースされるまでダウンロードを開始できません。代わりに別々の<link>タグを使用して、両方が並行してダウンロードされるようにしてください。 - ページごとにリソースの読み込みを解除する。
あるページからリソースを削除できないからといって、すべてのページでそれが必要だとは限りません。WordPressのプラグインは、一部のページでしかアクティブでない場合でも、すべてのページにスクリプトとスタイルを追加する傾向があります。 - 重要なものを優先する。
リソースの優先順位付けを使用して、クリティカルなリソースが最初に読み込まれ、クリティカルではないリソースが帯域幅を取り合わないようにしてください。
CoreDashのモニタリングデータによると、すべてのrender-blockingリソースを排除したサイトは、FCPが平均で420ms改善しました。
