2026年10月15日

WordPressの表示速度を上げる基本設定｜計測・PHP・キャッシュ・画像の順に見直す

SEO・パフォーマンス

WordPress の表示速度は、まず計測して遅い原因を見つけ、PHP のバージョン、ページキャッシュ、画像、プラグインの順に見直すと、少ない手間で改善しやすくなります。この記事では、PageSpeed Insights の結果の読み方から、サイト全体に効く基本設定、CSS・JavaScript の読み込み方、変更後の確認方法までを順に説明します。特別な知識が無くても進められる設定を先に、コードを使う設定を後に並べています。

最初に計測して、基準の数字を残す

設定を変える前に、今の速さを記録しておきます。変更のたびに数字を比べないと、どの設定が効いたのか、逆に遅くしたのかが分かりません。

PageSpeed Insights（https://pagespeed.web.dev/）にページの URL を入れると、2種類の結果が出ます（見出しの表記は変わることがあります）。

実際のユーザーの環境で測定されたデータ（フィールドデータ）: Chrome を使う実際の訪問者の体験を集計したものです。アクセスが少ないサイトでは表示されないことがあります。
パフォーマンスの問題を診断する（ラボデータ）: 決まった条件で1回読み込んだ結果です。改善点の一覧はこちらに出ます。

見るべき指標は Core Web Vitals の3つです。表示の中心となる要素が出るまでの時間（LCP）、操作への反応の速さ（INP）、表示中のレイアウトのずれ（CLS）で、Google はそれぞれ LCP 2.5秒以内、INP 200ミリ秒以内、CLS 0.1以下を「良好」の目安としています（2026年10月現在）。スコアの数字そのものより、どの指標が悪いかに注目すると、打つ手が絞れます。

トップページだけでなく、記事ページなどアクセスの多いページも測ってください。ページの種類によって遅い原因が違うことがよくあります。

設定1: PHP を新しいバージョンにする

PHP は WordPress を動かしているプログラムの言語で、新しいバージョンほど処理が速くなる傾向があります。サーバーの管理画面で PHP のバージョンを切り替えられることが多く、費用もかからず、サイト全体に効きます。

今のバージョンは、管理画面の「ツール」→「サイトヘルス」→「情報」の「サーバー」欄で確認できます。WordPress が推奨するバージョンは WordPress.org の要件のページに載っています。

切り替える前にバックアップを取り、できればステージング環境で試してください。古いプラグインやテーマが新しい PHP に対応しておらず、画面が真っ白になることがあります。問題が出たら、サーバーの管理画面で元のバージョンに戻せます。

設定2: ページキャッシュを有効にする

WordPress は、ページを表示するたびにデータベースから記事を読み出して HTML を組み立てます。ページキャッシュは、組み立て済みの HTML を保存しておき、次の訪問者にはそれを返す仕組みで、サーバーの応答時間を大きく減らせます。

方法は2通りです。

サーバー側のキャッシュ機能: レンタルサーバーによっては管理画面で有効にできます。まずここを確認します。
キャッシュプラグイン: WP Super Cache、W3 Total Cache などがあります。LiteSpeed という種類のサーバーでは LiteSpeed Cache が使えます。

注意点は、キャッシュの仕組みを重ねないことです。サーバー側とプラグインの両方、あるいはキャッシュプラグインを2つ同時に有効にすると、更新が反映されない、表示が崩れるといった問題の原因になります。また、ログイン中のユーザー、カートや決済のページ、フォームのページはキャッシュの対象から外すのが基本です。多くのプラグインは標準でログインユーザーを除外していますが、EC サイトでは設定を確認してください。

設定3: 画像を軽くする

記事ページで LCP が遅い場合、原因の多くはアイキャッチなどの大きな画像です。

アップロード前にサイズを小さくする: 表示幅が800ピクセル程度なのに、スマートフォンで撮った4000ピクセルの写真をそのまま使うのはむだです。WordPress は大きすぎる画像を自動で縮小しますが（標準では長辺2560ピクセル）、それでも記事に必要な大きさより大きいことがほとんどです。
WebP 形式を使う: WordPress は WebP の画像をアップロードできます。同じ見た目で JPEG より軽くなることが多い形式です。EWWW Image Optimizer などの画像最適化プラグインで、圧縮や WebP への変換を自動化することもできます。
遅延読み込みと優先読み込み: WordPress は画面の外にある画像に loading="lazy" を付けて、表示されるまで読み込みを遅らせます。一方で、最初に見える一番大きな画像まで遅延させると LCP が悪くなります。WordPress 6.3 以降は、その画像に fetchpriority="high" を自動で付けて優先させる仕組みがあります。テーマやプラグインが独自に遅延読み込みをしている場合は、この画像が除外されているかを確認してください。

設定4: プラグインとテーマを見直す

プラグインの数そのものより、重い処理をするプラグインがあるかどうかが問題です。ページビルダー、スライダー、SNS の埋め込み、アクセス解析や広告のタグは、読み込むファイルが多くなりがちです。

使っていないプラグインは無効化して削除します。どれが重いか分からないときは、Query Monitor というプラグインで、ページごとのデータベースへの問い合わせの数や時間、読み込まれているファイルを確認できます。確認が終わったら、Query Monitor も無効にしておきます。

テーマも速度に影響します。高機能なテーマは便利な反面、使わない機能の CSS や JavaScript まで読み込むことがあります。テーマの設定画面に、不要な機能を切る項目がないか確認してください。

設定5: CSS と JavaScript の読み込み方を整える

PageSpeed Insights で「レンダリングを妨げるリソースの除外」という項目が出ることがあります。これは、ページの表示を始める前に読み込みと実行が終わるのを待たなければならない CSS や JavaScript がある、という指摘です。新しい版の Lighthouse では、似た内容が「インサイト」としてまとめて表示されることもあります。

JavaScript は、defer（HTML の解析を止めずに読み込み、解析後に順番どおり実行する）や async（読み込みが終わり次第実行する）を付けると、表示を妨げにくくなります。自作のテーマや子テーマで読み込んでいるスクリプトなら、WordPress 6.3 以降は wp_enqueue_script() の5番目の引数で指定できます。子テーマの functions.php に書く例です。

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

他のスクリプトに依存しているもの（jQuery を前提にしたものなど）に async を付けると、実行の順番が崩れて動かなくなることがあります。迷ったら defer を選び、変更後にメニューやフォームなど JavaScript を使う部分が動くか確認してください。

CSS は、最初の画面の表示に必要な部分（クリティカル CSS）だけを先に読み込み、残りを後から読む方法がありますが、手作業では手間がかかります。キャッシュプラグインや最適化プラグインの機能で行うのが現実的です。CSS や JavaScript の結合・圧縮の機能は表示崩れを起こしやすいので、1つずつ有効にして確認します。

設定6: データベースを整理する

記事を編集するたびに保存されるリビジョン（編集履歴）や、不要になったプラグインが残した設定が溜まると、データベースが大きくなります。リビジョンの保存数は wp-config.php で制限できます。

define( 'WP_POST_REVISIONS', 10 );

すでに溜まったリビジョンや一時データの削除には、WP-Optimize などのプラグインが使えます。データベースを書き換える操作なので、実行前にバックアップを取ってください。サイトヘルスの画面で、自動読み込みされる設定データが大きいという指摘が出る場合は、削除済みのプラグインが残したデータが原因のことがあります。

変更後の確認

設定は1つずつ変え、そのたびに次の点を確認します。

PageSpeed Insights で、最初に記録した数字と比べる（ラボデータは測るたびに多少ぶれるので、2〜3回測って傾向を見る）
ログアウトした状態で、トップページ・記事ページ・固定ページの表示が崩れていないか
お問い合わせフォームの送信、検索、メニューの開閉など、動きのある部分が使えるか
記事を更新したとき、キャッシュが消えて新しい内容が表示されるか

フィールドデータは過去28日間の集計なので、改善が反映されるまで数週間かかります。すぐに数字が変わらなくても、ラボデータで改善していれば、そのまま様子を見てください。

まとめ

変更前に PageSpeed Insights で計測し、LCP・INP・CLS のどれが悪いかを確認する
PHP のバージョンアップとページキャッシュは、手間の割にサイト全体に効く
キャッシュの仕組みは重ねず、ログインユーザーやカート・フォームのページは除外する
画像はアップロード前に小さくし、最初に見える大きな画像は遅延読み込みしない
JavaScript は defer を基本にし、変更後は動きのある部分を確認する
設定は1つずつ変え、そのつど計測して効果と不具合を確かめる