2026年6月2日

WordPressでPageSpeed Insightsの「レンダリングを妨げるリソース」を解消する手順

SEO・パフォーマンス

PageSpeed Insights で指摘される「レンダリングを妨げるリソース」は、ページの最初の描画より前に読み込みと処理が終わるのを待たされている CSS と JavaScript のことです。WordPress では、JavaScript は wp_enqueue_script() の strategy 引数で defer や async にし、CSS は不要な読み込みを減らしたうえで、最初の表示に必要な分を先に出すのが基本の対処です。この記事では、指摘の読み方、原因の特定、テーマ・プラグインのファイルへの具体的な直し方、直した後の確認方法までを説明します。

作業はテーマや読み込み設定を変えるため、事前にバックアップを取り、可能ならステージング環境で試してください。

指摘の意味を理解する

ブラウザは HTML を上から読み、head の中に通常の <link rel="stylesheet"> や属性なしの <script src> があると、それを取得して処理するまで画面の描画を始められません。この待ち時間が長いほど、白い画面の時間が延び、FCP（最初のコンテンツの描画）や LCP（最大のコンテンツの描画）の数値が悪くなります。

PageSpeed Insights の診断では、該当するファイルのURLと、なくせた場合に短縮できる時間の見込みが一覧になります。Lighthouse の新しい版では、従来の個別の監査項目が「インサイト」という形にまとめ直されており、表示名が「レンダリングをブロックしているリクエスト」のように変わっている場合があります（2026年10月現在）。名称は違っても、見るべき中身は同じです。

注意したいのは、見込みの時間は実験室での計測値であり、実際の利用者の体験とは一致しない点です。ページ上部に表示される実際のユーザーのデータ（フィールドデータ）と、下部の診断（ラボデータ）を分けて読みます。また、この指摘をゼロにすること自体が目的ではありません。CSS を1つも待たずに描画すると、スタイルのない画面が一瞬表示されたり、後から見た目が切り替わってレイアウトがずれたりします。

どこから来ているファイルかを特定する

一覧のURLを見れば、多くは出どころが分かります。

/wp-content/themes/テーマ名/ … テーマの CSS・JavaScript
/wp-content/plugins/プラグイン名/ … 各プラグイン
/wp-includes/ … WordPress 本体（jQuery、ブロックのスタイルなど）
fonts.googleapis.com などの外部ドメイン … Web フォントや外部サービス

次に、そのファイルを登録しているハンドル名（wp_enqueue_script() などで付けられた名前）を調べます。HTML の <link> には id="ハンドル名-css"、<script> には id="ハンドル名-js" が付くことが多いため、ページのソースを見ればハンドル名を確認できます。

あわせて、Chrome の開発者ツールの「Coverage」パネルで、各ファイルのうち実際に使われている割合を見ておくと、そもそもそのページで不要なファイルを見つけられます。

対処1：そのページで使わないファイルを読み込まない

最も効果が大きく、副作用も少ないのは、不要な読み込みを止めることです。例えば、お問い合わせフォームのプラグインが全ページで CSS と JavaScript を読み込んでいるなら、フォームのあるページ以外では外せます。

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( is_page( 'contact' ) ) {
        return;
    }
    wp_dequeue_style( 'example-form-style' );
    wp_dequeue_script( 'example-form-script' );
}, 100 );

ハンドル名はプラグインごとに違うため、先ほどの方法で調べた実際の名前に置き換えます。優先度を 100 にしているのは、プラグインが登録した後に外すためです。外した結果、フォームやスライダーが動かなくなっていないかを、該当ページと外したページの両方で確かめます。

クラシックテーマでは、ブロックのスタイルがまとめて1つの大きな CSS として読み込まれます。次のフィルターを有効にすると、ページで使われているブロックのスタイルだけを読み込むようになります。ブロックテーマでは初めからこの動きです。

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

この方式では、小さなブロック用のスタイルは外部ファイルではなく HTML 内に直接書き込まれるため、待たされるファイルの数も減ります。

対処2：JavaScript を defer・async にする

自作テーマや子テーマで読み込むスクリプトは、登録時に読み込み方を指定できます。WordPress 6.3 以降では、wp_enqueue_script() の5番目の引数に配列を渡します。

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_script(
        'my-theme-main',
        get_stylesheet_directory_uri() . '/js/main.js',
        array(),
        '1.0.0',
        array(
            'in_footer' => true,
            'strategy'  => 'defer',
        )
    );
} );

defer は HTML の解析を止めずに取得し、解析が終わってから記述順に実行します。DOM を操作する一般的なスクリプトはこちらが向いています。async は取得でき次第すぐに実行するため順序が保証されず、アクセス解析のように他と関係しない処理に向いています。

この方法の利点は、依存関係を WordPress が考慮してくれることです。defer を指定したスクリプトに、遅延できないスクリプトが依存している場合などは、壊れないように通常の読み込みに戻されます。指定したのに属性が付かないときは、この自動調整が働いていないかを疑います。

プラグインが登録したスクリプトに後から指定を加える場合は、wp_script_add_data() で strategy を設定する方法があります。古い記事でよく見る script_loader_tag フィルターで文字列を置き換える方法は、依存関係を考慮しないため、新しく書くなら避けたほうが安全です。

add_action( 'wp_enqueue_scripts', function () {
    wp_script_add_data( 'example-slider', 'strategy', 'defer' );
}, 100 );

jQuery は多くのテーマやプラグインのインラインスクリプトが前提にしているため、jQuery 本体を遅らせると「jQuery is not defined」のエラーで機能が止まることがあります。jQuery を使うスクリプトが多いサイトでは、無理に遅らせず、jQuery に頼る処理そのものを減らすほうが現実的です。

対処3：CSS の読み込みを整理する

CSS は描画に必要なので、JavaScript のように単純に遅らせることはできません。考え方は「最初の画面に必要な CSS は早く、それ以外は後で」です。

クリティカル CSS：ファーストビュー（スクロールせずに見える範囲）の表示に必要な最小限の CSS を head に直接書き、残りを遅れて読み込む方法です。手作業での抽出は手間がかかるため、最適化プラグインの機能を使うのが一般的です
Web フォント：外部の Google Fonts を読み込むと、CSS とフォントの取得が別ドメインへの接続を伴います。フォントファイルを自分のサーバーに置き、font-display: swap を指定すると待ち時間を減らせます。ブロックテーマでは、WordPress 6.5 で加わったフォントライブラリからフォントをサーバーに取り込めます
プラグインの CSS：対処1と同じく、使わないページでは外します

CSS を遅れて読み込む設定は、ページ上部のスタイルが後から当たってレイアウトがずれる原因になりやすい項目です。CLS（レイアウトのずれ）の数値が悪化していないかを、変更の前後で、記事・固定ページ・トップページなど種類の違うページで確かめます。

プラグインで対処する場合

コードを書かずに対処するなら、最適化系のプラグインを使います。例えば Autoptimize や LiteSpeed Cache は JavaScript の遅延やクリティカル CSS の生成に対応し、Asset CleanUp のようにページごとに不要なファイルを外すことに特化したプラグインもあります。有料の WP Rocket や Perfmatters にも同様の機能があります。対応している機能の範囲や、無料版と有料版の区別は版によって変わるため、導入前に説明を確認してください。

複数の最適化プラグインで同じ処理を有効にすると、二重処理で表示が崩れたり、原因の切り分けができなくなったりします。最適化を担うプラグインは1つに絞り、設定は1項目ずつ有効にして、そのたびに表示と動作を確認します。

直した後の確認

ページのキャッシュとプラグインのキャッシュを削除してから、PageSpeed Insights で再計測する。結果には揺れがあるため、数回計測して傾向を見る
ページのソースで、狙ったスクリプトに defer や async が付いているか、外したファイルが消えているかを確かめる
ログアウトした状態で、メニューの開閉、フォームの送信、スライダー、カート機能など、JavaScript に頼る部分を一通り動かす
ブラウザのコンソールにエラーが出ていないかを見る

フィールドデータは過去28日間の集計のため、改善が反映されるまでには時間がかかります。数値が良くなっても検索順位が上がるとは限らないので、表示速度は利用者の体験を良くするための取り組みとして続けていくのが妥当です。

まとめ

「レンダリングを妨げるリソース」は、最初の描画前に待たされている CSS と JavaScript。Lighthouse の版によって表示名や分類が変わる
まずURLとハンドル名から出どころを特定し、そのページで不要なファイルを外す
JavaScript は wp_enqueue_script() の strategy（WordPress 6.3 以降）で defer・async を指定し、依存関係の調整は WordPress に任せる
CSS はクリティカル CSS、フォントの自前配信、ブロックのスタイルの分割読み込みで整理し、CLS の悪化に注意する
変更後はキャッシュを消して再計測し、JavaScript に頼る機能が動くかを確かめる