WordPress高速化の実装手順｜Core Web Vitals合格でもトップページが6.67MBだった話

公開日
2026.09.10

「PageSpeed Insights が合格なら、そのサイトは速い」——うちはそう思っていました。実際に自社サイトのトップページを測るまでは。

2026年9月8日、cielo-design.com のトップページを実測したところ、Core Web Vitals は合格、しかし総転送量は 6.67MB という結果になりました。制作会社の自社サイトとして、これは褒められた数字ではありません。

この記事では、その6.67MBの中身を1本ずつ実測して犯人を特定し、実際に直すまでの全工程を、実測値とコード付きで公開します。読み終えると、「指標は合格なのに重いサイト」がなぜ生まれるのか、そして自分のサイトで同じことが起きていないかを確認する手順が分かります。

WordPress高速化の実装とは

WordPress高速化の実装とは、サーバー応答・画像・CSS/JavaScript・キャッシュの4領域に手を入れて、ページの表示速度と転送量を改善する作業のことです。2026年現在は Core Web Vitals（LCP・INP・CLS）の3指標が評価軸になっており、Google の検索ランキング要因のひとつとして扱われています。

ただし注意が必要なのは、Core Web Vitals の3指標は「ページの重さ」を直接測っていないという点です。転送量が何MBあっても、指標上は合格になり得ます。今回うちで起きたのが、まさにそれでした。

自社サイトを実測したら6.67MBだった

まず現状を測りました。計測は 2026年9月8日、モバイルのユーザーエージェントで、curl と macOS の sips を使ってアセットを1本ずつ取得しています。

サーバーもHTMLもCSSもJavaScriptも、数字だけ見れば優秀です。JavaScript が14本で79.7KB というのは、WordPress サイトとしてはかなり軽い部類だと思います。それでも総転送量が6.67MBになる。画像だけが単独で全部を台無しにしている構図でした。

それでも Core Web Vitals は「合格」だった

6.67MB という数字を見た後で PageSpeed Insights を確認したのですが、結果は拍子抜けするものでした。

モバイル・デスクトップとも Core Web Vitals 評価は「合格」。集計期間は2026年8月9日〜9月5日です。6.67MBのページが、指標上は何の問題もないことになっていました。

ちなみに INP が「データなし」なのは、単純にうちのトップページのアクセス数が CrUX の集計に足りていないからです。この点は正直に書いておきます。

なぜ6.67MBで合格するのか

ここが今回いちばん面白かったところです。画像を1本ずつ、loading 属性とHTML内の出現位置まで調べたら、理由がはっきりしました。

なお以下の表では、掲載しているクライアント名が推測できてしまうため、画像のファイル名は画像A〜Fに置き換えています。

種明かしはこうです。

• LCP要素は2KBのロゴ画像。ファーストビューにあり、これが1.1秒で描画されるので LCP は合格する
• 重い6枚は全部 loading=”lazy” で、しかもページの半分より下。スクロールするまで読み込まれないので、LCP にはまったく影響しない
• 各画像に width と height が入っているので、遅れて読み込まれてもレイアウトがずれず、CLS も 0.01 で合格

つまり、遅延読み込みと width/height 指定という「正しい実装」が、5.42MBの問題を指標から隠していたわけです。皮肉な話ですが、これは珍しいケースではないはずです。ファーストビューさえ軽ければ、折りたたみ下に何MB積んでも Core Web Vitals はグリーンになります。

指標に出ないだけで、スクロールしたユーザーは6.67MBを受け取ります。モバイル回線なら通信量として実際に負担がかかりますし、表示待ちも発生します。指標の合格と、ユーザー体験の良さは別物だと考えています。

CrUX と Lighthouse は別物です

ここで整理しておきたいのが、PageSpeed Insights に出てくる2種類のデータの違いです。上位記事でもここが混同されていることが多いのですが、実務上はかなり大事な区別です。

ここで押さえておきたいのは次の3点です。

• PSIの「パフォーマンススコア 0〜100」は Core Web Vitals そのものではありません。TBT や Speed Index など複数のラボ指標の加重合成なので、スコア100点でも CWV 不合格はあり得ますし、その逆もあります
• 改善の優先順位はフィールドデータ（CrUX）で決めるのが Google の推奨です
• アクセスの少ないURLはページ単位のCrUXデータが存在せず、オリジン単位（サイト全体）のデータにフォールバックして表示されます。うちのトップページもこれに該当していました。つまり「1.1秒」はトップページ単体の数字ですらありません

なお、「2026年3月のコアアップデートで CWV がページ単位からサイト単位の集計に変わった」「LCPのしきい値が2.0秒に厳格化された」という記述をいくつかの海外SEOブログで見かけましたが、web.dev や Search Console ヘルプなど Google の一次情報では裏付けが取れませんでした。現在も 2.5秒 / 200ms / 0.1 のままです。オリジン単位のフォールバックが「サイト単位になった」と誤解されたものだと考えています。

犯人の特定：バイト/ピクセルで見る

では6枚のJPEGはなぜ重かったのか。ここで意外だったのは、よくある「画像がデカすぎる」パターンではなかったことです。

• 実ファイルは 1280×960、HTMLの指定も width="1280" height="960" で寸法は一致。過大なリサイズはされていない
• したがって「表示サイズより大きい画像を配信している」問題でもない

原因は書き出し品質だけでした。判断に使ったのは「バイト/ピクセル（B/px）」という指標です。ファイルサイズをピクセル数で割った値で、Web用のJPEGなら概ね 0.10〜0.20 B/px に収まります。

全部が適正の3〜7倍でした。中身は制作実績として掲載しているクライアントサイトのスクリーンショットを、斜めにタイル状に並べたモックアップ画像です。細かい日本語テキストが大量に入るタイプなので、書き出し時に品質を上げたくなる気持ちは分かります。実際、圧縮しすぎると文字が滲みます。

もうひとつ、実装者として気になった点がありました。

• ページ内56枚の img のうち、srcset が付いているものが0本でした。WordPress は本来レスポンシブ画像用の srcset を自動生成しますが、テーマが wp_get_attachment_image() を使わず生の <img> タグで書いているため、コアの機能が1本も効いていません
• 同じ理由で fetchpriority も0本。WordPress 6.3 以降はLCP候補画像に自動で fetchpriority="high" を付けますが、これも効いていませんでした
• 56枚中 width/height の指定があるのは39枚。残り17枚はCLSのリスクが残ります
• 外部JavaScript 14本のうち13本に defer も async も付いておらず、レンダーブロッキングになっています

「WordPressは自動でsrcsetを吐いてくれる」と書いてある記事は多いのですが、テンプレートの書き方次第でその機能は完全に無効化されます。うちのテーマがまさにそれでした。

実装ステップ：6.67MBを半分にする手順

優先度の高い順に、実際に踏んだ手順です。

1. 現状を測る。PageSpeed Insights のスコアではなく、アセット1本ずつの転送量を出します。ブラウザのDevToolsのNetworkタブでも、curl でも構いません。「何が重いか」が分からないまま施策を打つと、効かない改善に時間を使うことになります
2. B/px で異常値を洗い出す。ファイルサイズ ÷（幅×高さ）を計算し、0.2 を大きく超えるものを候補にします。寸法が適正でも品質過多で重いケースはこれで見つかります
3. 品質を落として再書き出しし、必ず等倍で目視確認する。今回は品質75で再圧縮しました。テキストが多い画像なので、5倍に拡大して原本と並べ、文字のエッジが潰れていないか確認しています
4. 差し替える。ファイル名と寸法を変えなければ、そのまま上書きできます。WordPressのメディアライブラリ経由なら「Enable Media Replace」などのプラグイン、サーバーに入れるならFTP/SSHで wp-content/uploads/ を直接置き換えます
5. テンプレートを直す。生の <img> を wp_get_attachment_image() に置き換えると、srcset と fetchpriority がコア側で自動生成されるようになります
6. レンダーブロッキングを解消する。wp_enqueue_script() の第5引数を true にしてフッター出力にするか、wp_script_add_data() で defer を付けます
7. 28日待って CrUX を再確認する。フィールドデータは28日ローリングなので、直した翌日に Search Console を見ても変わりません

ステップ5の具体的なコードは次のとおりです。

<?php
// 修正前：srcset も fetchpriority も生成されない
// <img src="<?php echo $url; ?>" width="1280" height="960" alt="">

// 修正後：コアがsrcset・sizes・loading・fetchpriorityを自動付与
echo wp_get_attachment_image( $attachment_id, 'large', false, array(
    'alt'   => $alt_text,
    'class' => 'works-thumb',
) );

ステップ6のJavaScript側はこうです。

<?php
add_action( 'wp_enqueue_scripts', function () {
    // 第5引数 true でフッター出力にする
    wp_enqueue_script( 'cielo-main', get_theme_file_uri( '/assets/js/main.js' ), array(), '1.0.0', true );

    // さらに defer を付ける（WordPress 6.3以降）
    wp_script_add_data( 'cielo-main', 'strategy', 'defer' );
} );

WordPress Core が既にやっている高速化

実装を進めるうえで前提になるのが、「どこまでをコアが自動でやってくれるのか」です。ここを知らないと、プラグインで二重に同じことをやって、かえって遅くなります。2026年9月時点での状況を整理しました。

特に 6.9 のフロントエンド性能パッケージは効果が大きく、詳細はWordPress 7.1 Mary Lou のリリース解説でも触れています。

ここで強調したいのは、2023年〜2024年に書かれた高速化記事の指示が、現在では不要どころか有害になっている場合があるということです。「preloadを手で入れよう」「遅延読み込みプラグインを入れよう」といった記述は、コアの自動処理と衝突します。fetchpriority="high" と loading="lazy" を同時に指定すると WordPress が警告を出すのも、この衝突を防ぐためです。

やってはいけない5つ

1. LCP画像に loading=”lazy” を付ける。ファーストビューの画像を遅延させると、LCP は確実に悪化します。「全部lazyにすれば速くなる」は誤りです
2. コアと二重になるプラグイン設定を入れる。遅延読み込み、fetchpriority、投機的読み込みはコアが既にやっています。プラグイン側で重ねてONにする前に、コアの挙動を確認してください
3. PageSpeed Insights のスコアを追いかける。スコアはラボ指標の合成値です。90点を目指すより、CrUX の p75 を合格させるほうが本来のゴールに近いです
4. 直した翌日に Search Console を見て「変わらない」と判断する。CrUX は28日ローリングです。反映には時間がかかります
5. 画像最適化プラグインを入れて INP が直ると期待する。INP はJavaScriptの実行時間が主因なので、画像の遅延読み込みではほぼ改善しません。指標ごとに原因が違います

実際に直した結果

6枚を品質75で再書き出しした結果が次のとおりです。寸法は1280×960のまま、ファイル名も変えていません。

差し替え後、本番環境で同じ手順で測り直しました。

ページ総転送量は 6.67MB から 3.28MB へ、3.39MB（51%）減りました。リサイズもWebP化もせず、再書き出しとファイルの上書きだけです。作業時間は30分ほどでした。

目視確認もしています。テキストがいちばん多く、最も重かった画像Aを5倍に拡大して原本と並べましたが、社名やナビゲーションの文字のエッジに差は見られませんでした。品質75は、この種のスクリーンショット画像でも十分に実用範囲だと考えています。

なお Core Web Vitals の数値そのものは、元から合格していたので大きくは動きません。今回の改善が効くのは、指標には表れない「スクロールしたユーザーの通信量と待ち時間」のほうです。指標を直すための改善ではなく、指標が見ていない領域の改善という位置づけになります。

自社サイトの作り込みについてはリニューアルの連載記事でも書いていますが、作った後に測り直すところまでやらないと、こういう見落としは残り続けるのだと反省しています。テーマ側のオリジナル画像は全部WebPで丁寧に作ってあったのに、管理画面から入稿した実績画像だけが素通しだった、というのが今回の実態でした。

よくある質問

Q. Core Web Vitals が合格なら、それ以上やる必要はありませんか？

A. 指標としては十分です。ただし今回のケースのように、指標が合格でも転送量が6MBを超えていることはあります。モバイル回線のユーザーの通信量や、スクロール時の表示待ちは指標に出ません。合格を確認したうえで、転送量も一度見ておくことをおすすめします。

Q. PageSpeed Insights のスコアは何点を目指せばいいですか？

A. スコアは目標にしないほうがいいと考えています。スコアはTBTやSpeed Indexなどラボ指標の加重合成で、ランキング評価には使われません。目指すべきは CrUX のフィールドデータで LCP 2.5秒以下・INP 200ms以下・CLS 0.1以下を p75 で満たすことです。

Q. 画像は WebP や AVIF に変換すべきですか？

A. 効果は大きいので、可能なら変換したほうがいいです。ただし今回のように、JPEGのまま品質を適正化するだけで63%削減できるケースもあります。変換の仕組みを入れる前に、まず現状のB/pxを測ってみてください。順序としては「適正な品質で書き出す」が先で、「次世代フォーマットに変換する」が後です。

Q. fetchpriority は自分で書くべきですか？

A. WordPress 6.3以降はコアがLCP候補画像を自動判定して付与するので、基本的には不要です。ただし今回のうちのテーマのように、生の <img> タグで書いていると自動付与が効きません。まず wp_get_attachment_image() を使うようにテンプレートを直すのが先です。

Q. 遅延読み込みプラグインはまだ必要ですか？

A. WordPress 5.5以降、画像の loading="lazy" はコアが自動で付けます。専用プラグインを重ねる必要は基本的にありません。むしろ二重に処理して、LCP画像まで遅延させてしまう事故のほうが怖いです。

Q. 改善の効果はいつSearch Consoleに反映されますか？

A. CrUX は過去28日間のローリング集計なので、反映には最大で1か月程度かかります。直した直後に数字が変わらなくても、それは正常です。ラボデータ（Lighthouse）のほうは即座に変わるので、施策が効いたかどうかの確認にはそちらを使ってください。

Q. PageSpeed Insights に「このURLの実ユーザーデータが不十分」と出ます。

A. そのURLのアクセス数がCrUXの集計基準に達していないため、オリジン単位（サイト全体）のデータにフォールバックして表示されています。表示されている数値はそのページ固有の値ではないので、解釈に注意が必要です。アクセスが増えればページ単位のデータが出るようになります。

Q. INP だけが「データなし」になるのはなぜですか？

A. INP はユーザーの操作（クリックやタップ）がないと計測されません。アクセス数が少ないサイトや、操作要素の少ないページでは、データが集まらず「データなし」になります。うちのトップページもこの状態でした。

Q. srcset が生成されているかは、どうやって確認しますか？

A. ブラウザでページを開いてソースを表示し、<img タグに srcset 属性があるかを見るのが早いです。1枚もなければ、テーマが wp_get_attachment_image() を使っていない可能性が高いです。うちは56枚中0本でした。

Q. 画像の品質はどこまで落としていいですか？

A. 一律の正解はないので、必ず等倍または拡大して目視確認してください。うちの場合は、テキストが多いスクリーンショット画像でも品質75で劣化が確認できませんでした。写真中心ならもう少し落とせますし、細い線や小さな文字が主体の図解ならもう少し上げる必要があります。B/pxで0.10〜0.20に収まっているかを目安にしつつ、最後は目で決めるのが確実です。

この記事を書いた人

フロントエンドエンジニア

日下 正樹 Kusaka

見た目だけでなく、使いやすさと保守性を意識した実装を心がけています。

スタッフ紹介はこちら →