PageSpeed Insightsの「レンダリングをブロックしているリクエスト」とは？下の欄の項目は分析情報。直すかは上の欄で決める

PageSpeed Insightsに記事のURLを入れたら、点数の下に「レンダリングをブロックしているリクエスト」「ネットワークの依存関係ツリー」「LCP リクエストの検出」といった項目がいくつも並んだ。昔の解説記事で読んだ名前とは字が違うし、どれも赤や黄色の印が付いていて、全部直さないと検索で不利になるのか、そもそも何のことなのかが分からない。そこで手が止まっていないでしょうか。

この記事は、PageSpeed Insightsの下の欄に出る項目の名前が分からない個人ブロガーに向けて、項目が何なのか、古い名前と新しい名前がどう対応しているか、よく出る項目が何を指しているか、ブログで直すかをどう決めるかを書きます。直し方の細かい手順は書かず、指標ごとの記事にリンクで渡します。根拠にしたのは、Chromeの開発者向けサイト(Chrome for Developers)の「パフォーマンス分析情報」の一覧と分析情報ごとのページ、ブログ記事「Lighthouse 13 の新機能」、古いLighthouseの監査のページ、web.dev の1ページで、2026年10月14日に日本語版と英語版を取得して読み比べました。どのページの日本語版も、AIによる翻訳と注記されています。引用はどれも英語版と同じ意味かを見て、訳が崩れている文は英語版を私が訳しています。

私はこの記事のためにPageSpeed Insightsの実際の画面を開いて確かめてはいません。項目の名前は、上の文書に書かれている日本語の字で呼んでいます。あとで書くとおり、同じサイトの中でも訳の字が割れていることがあるので、画面に出る字は記事の字と少し違うかもしれません。英語の名前も添えるので、近い名前を探してください。また、今のPageSpeed Insightsがどの版のLighthouseを使っているかも、画面では確かめていません。上の欄と下の欄がそれぞれ何を測っているかはPageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わるに書きました。

結論:下の欄の項目は、速くするための手がかり。直すかは上の欄で決める

文書に書かれていることと、そこから私が決めている見方をまとめると、次の4つです。

• 下の欄の項目は、Lighthouseの「分析情報」。Lighthouse 13で古い監査がまとめ直されたので、古い解説記事とは名前が違います
• 新旧の名前は、公式の文書で対応が分かるものがある。ただ、使っていないJavaScriptやCSSのように、移ったとは書かれていないものもあります
• 項目は点数を決めるものでも、順位の数字でもない。点数は指標で決まり、項目は指標を良くするための手がかりです
• 直すかどうかは、上の欄の実際の訪問者のデータで決める。良好でない指標があれば、その指標に関係する項目だけを読みます

下の欄の項目は「分析情報」:Lighthouse 13で古い監査がまとめ直された

Chrome for Developers のパフォーマンス分析情報の一覧は、冒頭でこう書いています。

パフォーマンス分析情報は、ウェブサイトのパフォーマンスに関する実用的な分析情報を提供し、DevTools の [パフォーマンス] パネルと Lighthouse の両方で利用できます。
— Chrome for Developers「パフォーマンス分析情報」

英語版は "Performance Insights provide actionable insights on your website's performance and are available in both the DevTools Performance panel and Lighthouse." です。Chromeのデベロッパーツール(開発者向けの画面)と、PageSpeed Insightsの下の欄の中身でもあるLighthouseの両方で、同じ分析情報を使える、ということです。一覧には「レンダリングをブロックしているリクエスト」「ネットワークの依存関係ツリー」「LCP リクエストの検出」「LCP の内訳」「レイアウト シフトの原因」「画像配信を改善する」「サードパーティ」など、19の名前が並んでいます。

名前が変わったいきさつは、ブログ記事Lighthouse 13 の新機能(2025年10月10日公開)に書かれています。

Lighthouse 12 では、Lighthouse レポートのデフォルト ビューを切り替えてこれらの分析情報を表示するようにしました。Lighthouse 13 では、レポートと基盤となる JSON の両方から古い監査を削除します。
— Chrome for Developers ブログ「Lighthouse 13 の新機能」

英語版も同じ意味です。古い監査は、Lighthouse 12で表示の主役から外れ、Lighthouse 13で消えた、ということです。PageSpeed Insightsについては、同じ記事に「また、今後 1 週間以内に PageSpeed Insights でも利用できるようになります。」とあります。古い名前で書かれた解説記事は、この切り替えの前に書かれたものだと考えられます。古い記事の名前で画面を探しても見つからないとすれば、このためだと私は考えています(今のPageSpeed Insightsの版と画面は確かめていません)。

項目は点数を上げるための手がかりで、点数そのものでも順位の数字でもない

項目がたくさん並ぶと減点の一覧に見えますが、同じ記事はこう書いています。

重要: このバージョンの Lighthouse では、パフォーマンス スコアに変更はありません。パフォーマンス スコアは監査ではなく指標に基づいています。スコアなしの監査のみが変更されています。
— Chrome for Developers ブログ「Lighthouse 13 の新機能」

英語版は "There are no changes to the performance scoring in this version of Lighthouse, which is based on the metrics rather than the audits. Only the non-scored audits are changing." です。点数は、LCPなどの指標の値から決まります。名前が変わったのは点数に入らない項目のほうで、名前が変わっても点数の決まり方は変わっていません。点数が指標の加重平均で決まることと、改善案や診断の項目が点数に直接は入らないことは、PageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わるに書きました。

項目には、合格・不合格のようなものもあります。分析情報のページの英語版には "How to pass this insight"(この分析情報に合格する方法。私の訳)という見出しがあり、どういうときに不合格になるかが書かれています(日本語版はこの見出しを「この分析情報を渡す方法」と訳していて、意味がずれています)。ただ、中には合否の無いものもあります。サードパーティのページは「この分析情報は常に合格しますが、サードパーティのリクエストが検出された場合は、情報提供を目的として表示されます。」、LCP の内訳のページは「この分析情報は、情報提供を目的として常に表示されます（LCP が測定された場合）。」と書いています。一覧に出ていることが、そのまま問題があるという意味ではない項目もある、ということです。

順位との関係について、私が読んだ文書(この記事で挙げたページ)には、分析情報の項目を検索順位に使うとは書かれていませんでした。Lighthouseの点数も順位の点数ではない、という結論はSEOスコアとは？Lighthouseもプラグインも順位の点数ではない。直す記事は自分の順位と表示回数で選ぶと同じで、この記事もそこを越えません。

古い名前と新しい名前の対応

新旧の対応は、2つの文書で確かめました。1つは「Lighthouse 13 の新機能」の置き換えの表で、ここには監査のID(Lighthouseの中での英字の名前)が並んでいます。もう1つは、古い監査のページの冒頭に足された警告文で、どの分析情報に移ったかが日本語の名前で書かれています。古いページは「以前のバージョンの Lighthouse からリンクできるように、古いドキュメントは当面の間残されます。」とあるとおり、まだ開けます。下の表は、この2つで対応が合ったものだけです。古い名前は古いページの日本語版の題名、新しい名前は分析情報の一覧の日本語版の字です。

表を作りながら気づいたのは、同じサイトの日本語の訳が割れていることです。レンダリング ブロック リソースを排除するの警告文は「警告: Lighthouse 13 以降、この監査は「レンダリングをブロックするリクエスト」の分析情報に移動しました。」で、一覧の「レンダリングをブロックしているリクエスト」とは字が違います。ほかにも、一覧の「ネットワークの依存関係ツリー」は警告文では「ネットワーク依存関係ツリー」、「フォント表示」は「フォントの表示」です。英語版はどれも同じ名前(Render-blocking requests など)なので、同じものを指しています。画面の字が記事の字と少し違っていても、同じ項目だと考えてください。

古い名前のほうも同じです。「レンダリングを妨げるリソースの除外」という字は、このページの日本語版では、ソースコードへのリンクの文字(英語版は "Source code for Eliminate render-blocking resources audit")として出てきます。ページの題名は「レンダリング ブロック リソースを排除する」なので、昔の画面の字がどちらだったかは、この文書からは分かりません。また、古いページは、英語版で同じ "Opportunities section" を、このページでは「[改善できる項目]」、使っていないCSSのページでは「[改善案]」と訳しています。

削除された「オフスクリーン画像の遅延読み込みを行う」(画面の外にある画像をあとから読み込むよう勧める監査)について、Lighthouse 13 の新機能は理由をこう書いています。

オフスクリーン画像はブラウザによってすでに優先度が下げられているため、遅延読み込みは帯域幅の削減には役立ちますが、Lighthouse の測定結果に影響を与える可能性は低いでしょう。
— Chrome for Developers ブログ「Lighthouse 13 の新機能」

遅延読み込みそのものが要らなくなった、という意味ではなく、Lighthouseの数字にはほとんど効かないので項目から外した、という読み方になります。逆に、最初に見える画像に遅延読み込みを付けるとLCPが遅れることは、次の章の「LCP リクエストの検出」に出てきます。

表に入れなかったもの:IDだけ分かるもの、文書どうしが食い違うもの

置き換えの表には、ほかにも対応が書かれています。たとえば、LCPの画像の優先度と遅延読み込みの監査(prioritize-lcp-image・lcp-lazy-loaded)は lcp-discovery-insight に、LCPの要素の監査(largest-contentful-paint-element)は lcp-phases-insight に、レイアウト シフトの監査(layout-shifts)は cls-culprits-insight に、キャッシュの監査(uses-long-cache-ttl)は use-cache-insight に置き換わった、とあります。ただ、これらは古いページが今は開けなかったり(404)、警告文が無かったりして、日本語の名前どうしでは照合できませんでした。IDの字面から、lcp-discovery-insight は一覧の「LCP リクエストの検出」、lcp-phases-insight は「LCP の内訳」のことだと私は読んでいますが、それを結ぶ字は読んだページにありません。

サードパーティのコードの影響を軽減する(third-party-summary)は、置き換えの表では third-parties-insight に移ったとあるのに、古いページの警告文は日本語版も英語版も「効率的なキャッシュの有効期間を使用する」の分析情報に移ったと書いていて、2つの文書が食い違っています。どちらが正しいかは文書からは決められないので、表には入れていません。

そして、使っていないJavaScriptとCSSの監査です。Chrome for Developers の日本語版の題名は使用していない JavaScript を削除すると未使用の CSS を削除しますです。この2つ(unused-javascript・unused-css-rules)は、Lighthouse 13 の新機能の置き換えの表にも、削除の表にも入っていませんでした。ページの冒頭にも移動の警告がありません。つまり、分析情報に移ったとは書かれていません。今のPageSpeed Insightsの画面にこの名前の項目が出るかどうかは、画面を開いていないので確かめていません。古いページによると、JavaScriptは「Lighthouse は、使用されていないコードが 20 キビバイトを超えるすべての JavaScript ファイルを報告します。」、CSSは2 KiB以上減らせるスタイルシートを挙げる、という基準でした。

よく出る項目が指しているもの

ここからは、ブログでよく話題になる項目を、分析情報のページに書かれている範囲で読みます。分析情報のページや古い監査のページには、使っている仕組みごとの「スタック固有のガイダンス」が付いているものがありますが、この記事では特定のサービスや拡張の名前は挙げません。

レンダリングをブロックしているリクエスト:最初の描画を止めているCSSとスクリプト

一覧の説明は「ページの最初のレンダリングをブロックし、LCP を遅らせているリソースを特定します。」です。分析情報のページは「この分析情報では、ページの First Paint を妨げたリクエストがハイライト表示されます。」と書いています(英語版は "This insight highlights requests that prevented the first paint of the page.")。ページを開いたとき、ブラウザが画面に最初の何かを描く前に読み終えなければならないCSSやスクリプトの一覧、ということです。古いページは、ページの先頭(<head>)にあって defer も async も付いていない <script> と、disabled も端末に合わせた media も付いていない <link rel="stylesheet"> を対象に挙げていました。ブログでは、テーマが読み込むCSS、ページの先頭に貼ったタグ、外から読み込むWebフォントの指定などがこれに当たりうる、と私は考えています。

同じページは、対処の1つとしてCSSのインライン化(必要なCSSをHTMLの中に直接書く方法)を挙げたうえで、こう注意しています。

ほとんどのサイトでは、この手法を実装しなくても、推奨されるパフォーマンス目標をすべて達成できるはずです。
— Chrome for Developers「レンダリングをブロックしているリクエスト」

英語版は "Most sites should be able to achieve all of our recommended performance targets without implementing this technique." です。この項目を消すために難しい作業をする必要は、たいていのブログには無い、と私は読んでいます。先頭のCSSやスクリプトがLCPの描画の遅延として効いているかの確かめ方はLCPの改善とは？サーチコンソールでLCPの問題が出たら、PageSpeed InsightsでLCPの要素と4つの内訳を確かめるに書きました。

ネットワークの依存関係ツリー:読み込みの数珠つなぎ

一覧の説明は「ページの初期レンダリングをブロックしている主要な依存関係チェーンを特定します。」です。HTMLがCSSを呼び、そのCSSがさらにフォントを呼ぶ、というように、前のファイルを読み終えないと次のファイルの読み込みが始まらない数珠つなぎを、木の形で見せる項目です(この言い換えは私のものです)。分析情報のページは「この分析情報は、重要なリクエストがページの早い段階で検出されない場合にのみ失敗します。」と書いています。木が出ているだけで不合格とは限りません。

LCP リクエストの検出:LCPの画像が早く見つかり、優先されているか

一覧の説明は「LCP 画像リクエストに予想以上に時間がかかっている理由を特定します。」です。fetchpriority という語で検索されているのは、おそらくこの項目です。分析情報のページは、LCPが画像のときに合格する条件として、「画像要素またはそのプリロード ディレクティブで fetchpriority=high を使用します。」、画像がHTMLから直接見つけられること、「画像の loading=lazy は避けてください。」の3つを挙げています。最初に大きく見える1枚の画像を、早く見つけて優先して読み込み、あとから読み込む設定にしない、ということです。ブログで言えばアイキャッチや1枚目の写真がこれに当たりやすく、その遅延読み込みを確かめる手順はブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるに書きました。

LCP の内訳と画像配信を改善する

「LCP の内訳」は、一覧の説明では「LCP を改善するための最適化の機会を特定するのに役立つ LCP のサブパートが表示されます。」です。上で引いたとおり、LCPが測れたときは常に出る、情報のための項目です。4つの部分の意味と、どこが長いと何を疑うかは、上のLCPの記事に書きました。

「画像配信を改善する」は、古い画像の監査(形式・圧縮・サイズなど)をまとめた項目です。分析情報のページは冒頭で「画像のダウンロード時間を短縮すると、ページ読み込みの体感時間と LCP を改善できます。」と書き、続けて「注: 推定バイト削減量が 4 KiB 未満の画像はフラグが設定されません。」としています。減らせる量が小さい画像は挙がりません。挙がった画像をどこまで軽くするかは、上の画像圧縮の記事に書いた考え方と同じです。

ドキュメント リクエストのレイテンシ:最初のHTMLが届くまで

古いサーバーの応答時間とテキスト圧縮の監査は、ここに入りました。分析情報のページが確かめる条件として挙げているのは、「ナビゲーション リクエストが 1 回以上リダイレクトされました。」「サーバーがリクエストに応答するまでに 600 ミリ秒以上かかりました。」「レスポンスは圧縮されていませんでした。」の3つです。記事のURLを変えたあとの転送を何段も重ねていないかは書き手にも確かめられますが、サーバーの速さと圧縮は、ブログサービスやレンタルサーバーの側の話になることが多い、と私は考えています。

サードパーティ:広告やアクセス解析のタグ

一覧の説明は「ページに読み込まれたサードパーティ リソースを一覧表示します。」です。サードパーティは、ここでは自分のブログ以外の会社のサーバーのことです。ブログで何が当たるかは、古いページのサードパーティのコードの影響を軽減するに分かりやすい文があります。

広告ネットワーク、ソーシャル メディア ボタン、A/B テスト、分析サービスをページに追加するには、通常、HTML にサードパーティのスクリプトを追加する必要があります。
— Chrome for Developers「サードパーティのコードの影響を軽減する」

英語版は "To add an advertising network, social media button, A/B test, or analytics service to your page, you usually need to add a third-party script to your HTML." です。広告、SNSのボタンや埋め込み、アクセス解析のタグがこの一覧に並ぶ、ということです。上で引いたとおり、この分析情報は常に合格で、情報のために出ます。広告は収益にかかわるので、項目に出たからといって一律に外すことは勧めません。外部のスクリプトが操作の反応(INP)に効いているかの確かめ方はINPの改善とは？サーチコンソールで「改善が必要」と出たら、PageSpeed InsightsとChromeで遅い操作を探すに書きました。

直すかどうかは、上の欄の実際の訪問者のデータとSearch Consoleの数字で決める

項目を全部消そうとすると、終わりがありません。私は、どの項目を読むかを、上の欄から決めています。web.dev のラボデータとフィールドデータの違いの解説は「一般に、特定のページについてフィールドデータとラボデータの両方がある場合は、フィールドデータを使用して優先順位を付ける必要があります。」と書いています。上の欄が実際の訪問者のデータ(フィールドデータ)、下の欄がLighthouseの試験(ラボデータ)です。

1. 上の欄で、Core Web Vitals の評価が合格かを見る。合格なら、下の欄の項目は急がない
2. 不合格なら、LCP・INP・CLS のどれが良好でないかを見て、その指標に関係する項目だけを読む。LCPなら「LCP の内訳」「LCP リクエストの検出」「レンダリングをブロックしているリクエスト」「画像配信を改善する」、INPなら「INP の内訳」、CLSなら「レイアウト シフトの原因」(どれも一覧の説明か分析情報のページに、その指標の名前が出てくるものです)
3. 上の欄が出ない記事は、実際の訪問者のデータが足りない。項目を直しても、効いたかを上の欄で確かめられない
4. どの記事に手を入れるかは、Search Consoleの表示回数と掲載順位で決める。速度より先に、検索結果に出ている記事の中身とタイトルを見直す

この順番は私の決め方で、Googleの文書にこの順で書かれているわけではありません。3つ目について、アクセスの少ない記事では実際の訪問者のデータが溜まらず、直しても直った証拠が出にくいことはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。速度が順位にどこまで効くかの結論も、その記事のとおりです。

よくある質問

下の欄の項目は、全部消さないといけませんか

消さなくてかまいません、と私は考えています。項目は点数を決めるものではなく、合否の無い情報のための項目もあります。上の欄の実際の訪問者のデータで良好でない指標があるときに、その指標に関係する項目から読めば十分です。

昔の解説記事に出てくる項目が、画面に見つかりません

Lighthouse 13で古い監査がレポートから消え、分析情報にまとめ直されたためだと考えられます。この記事の対応表で、移った先の名前を探してください。表に無いもの(使っていないJavaScriptやCSSなど)は、移ったとは書かれていないので、今の画面にあるかを画面で確かめる必要があります。

項目を直せば、検索順位は上がりますか

私が読んだ文書には、分析情報の項目を順位に使うとは書かれていませんでした。項目を直して速くなれば、上の欄の Core Web Vitals が良くなることはありえます。ただ、Googleがページ エクスペリエンスの説明で、レポートで良い結果が出ても上位表示は保証されないと書いていることは、上の速度とSEOの記事で引いたとおりです。順位の面での優先順位も、その記事の結論のままです。

モバイルとパソコンで、出る項目が違います

下の欄は、モバイルとパソコンで測る条件が違う試験なので、出る項目が違うことはありえます。見るなら、自分のブログに多い端末のほうを、上の欄と合わせて見てください。

まとめ

• PageSpeed Insightsの下の欄の項目は、Lighthouseの「パフォーマンス分析情報」。Chromeのデベロッパーツールでも使える
• Lighthouse 12で分析情報が既定の表示になり、Lighthouse 13で古い監査が消えた。古い解説記事と名前が違うのはこのため
• 「レンダリング ブロック リソースを排除する」は「レンダリングをブロックしているリクエスト」へ、画像の3つの監査は「画像配信を改善する」へ、など。使っていないJavaScriptとCSSは、移ったとは書かれていない
• 日本語の訳は同じサイトの中でも割れている。画面の字が少し違っても、英語の名前が同じなら同じ項目
• 点数は指標で決まり、項目は点数そのものではない。読んだ文書には、項目を順位に使うとは書かれていない
• 直すかは、上の欄で良好でない指標があるかを先に見て、その指標に関係する項目だけ読む。記事に手を入れる順番はSearch Consoleの数字で決める

上の欄が合格か、データが出ていないなら、項目の印を追いかけるより、すでに検索結果に出ている記事のうち、どれの中身やタイトルを直すかを決めるほうに時間を回せます。

項目の一覧を前にして、どの記事から手を付けるかで迷うこともあると思います。私は、検索結果にすでに出ていて、中身やタイトルを直す候補になっている記事を先に決めています。ここからは自分のツールの宣伝になることを、先に断っておきます。

Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分がそろうとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページ分の数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。このツールは、表示速度もLighthouseの項目も点数もCore Web Vitalsも測りません。PageSpeed Insightsの代わりにはならないので、どの項目が出ているかは、この記事のとおりPageSpeed Insightsで見てください。判定に出た記事をPageSpeed Insightsにかけるのも手作業です。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。