WordPressの表示速度改善はどこまでやるべきか。ヘッドレス化との使い分けを制作会社が解説

「コーポレートサイトの表示が遅い。WordPressのままチューニングすべきか、思い切ってヘッドレス化すべきか」。中小企業のWEB担当者や店舗経営者から、この相談が増えています。

結論から書きます。**大半のコーポレートサイトは、WordPressのまま「画像の最適化」と「キャッシュ設定」を正しくやれば十分に速くなります**。ヘッドレス化（フロントを静的HTMLに置き換える構成）が効くのは事実ですが、初期構築に相応の工数がかかるため、「速度改善だけ」を目的に選ぶ手段ではありません。順番としては次の通りです。

1. まず計測して、遅さの原因を特定する（推測で手を打たない）

2. 画像を軽くする（実測上、これが最大の原因であることが圧倒的に多い）

3. キャッシュと不要な読み込みを整理する

4. それでも要件を満たせないときに初めて、ヘッドレス化を検討する

本記事では、弊社（名古屋のWEB制作会社）が自社サイトとクライアントサイトの改善で実際に扱った数字を挙げながら、この順番で何をやるか、そしてヘッドレス化に踏み切るべき判断基準はどこかを解説します。

表示速度が遅い原因は、ほとんどの場合「画像」から疑う

表示速度の改善というと、キャッシュプラグインや高速なサーバーへの移転から入る方が多いのですが、実務で計測すると、**最初に見つかるボトルネックはたいてい画像です**。

実際にあった例を2つ挙げます。

**例1：11.5MBのヒーロー画像**。弊社が公開後の実測チェックを行ったあるコンサルティング会社のコーポレートサイトで、トップページのヒーロー画像（ファーストビューの大きな写真）が約11.5MBありました。ページ自体は正常に表示され、HTTPステータスもすべて200。つまり「動作確認」だけでは何も問題が見つからない状態です。しかし11.5MBの画像は、モバイル回線では表示に数秒〜十数秒かかる計算になります。一般に、Webページで使う画像は1枚あたり数百KB以内、ヒーロー画像でも500KB前後に抑えるのが目安です。桁が2つ違いました。

なぜこうなるかというと、撮影された写真データ（一眼レフやスマホの原寸）をそのままアップロードしてしまうケースが後を絶たないからです。制作時は高速なWi-Fiとキャッシュの効いたブラウザで確認するため、制作者本人は遅さに気づきにくい。**「公開直後にファイルサイズを実測でチェックする」工程をルール化しておかないと、この種の画像はどのサイトでも紛れ込みます**。

**例2：表示演出と画像サイズの見直しで体感速度を改善**。名古屋の革製品ECサイトでは、「ページが重くて開きにくい」という状態を改善するため、2つの調整を行いました。ひとつはオープニング演出（イントロローダー）の表示時間を5.8秒から3.2秒に短縮したこと。もうひとつはヒーロー画像の読み込みサイズを幅1800pxから1200pxに変更したことです。

このケースの学びは2点あります。第一に、**「読み込みの速さ」と「体感の速さ」は別物**だということ。演出のためのローダーが5.8秒表示されていれば、裏でどれだけ高速化してもユーザーには5.8秒待たせるサイトです。第二に、画像は「圧縮」だけでなく「表示サイズに合ったピクセル数で配信する」ことが重要だという点。スマホの画面幅で表示するのに1800px幅の画像は不要で、1200pxに落とすだけでデータ量は概ね半分近くまで減ります。

WordPressのまま速くする実務手順

上記を踏まえて、WordPressサイトの高速化は次の順番で進めます。

手順1：計測して原因を特定する

Googleの「PageSpeed Insights」にURLを入れるだけで、モバイル/PC別のスコアと改善項目が出ます。継続的に見るなら、Googleが提供するWordPress公式プラグイン「Site Kit」を入れると、PageSpeed InsightsとSearch Console、GA4を管理画面でまとめて確認できます。弊社もクライアントのWordPressにはSite Kitを標準で入れており、速度・検索・アクセスを1箇所で見られる体制にしています。なお、Site Kit導入時はGoogleアカウント連携の承認画面で権限のチェックを漏らすと「missing_required_scopes」というエラーで一部データが取れないことがあり、その場合は設定画面から再連携すれば解決します。

見るべき指標はまず**LCP（Largest Contentful Paint：ページの主要コンテンツが表示されるまでの時間）**です。2.5秒以内が目安で、これが遅い場合、原因の多くはファーストビューの画像です。

手順2：画像を軽くする

最も費用対効果が高い工程です。

**表示サイズに合わせてリサイズする**：横幅2000pxを超える画像が必要な場面はほぼありません。ヒーロー画像でも1200〜1600px程度で十分です
**WebP形式に変換する**：JPEG/PNGと比べて同じ見た目で2〜3割以上軽くなります。「EWWW Image Optimizer」等のプラグインで既存画像を一括変換できます
**遅延読み込み（lazy loading）を確認する**：WordPress本体が標準対応していますが、テーマによっては無効化されていることがあります
**公開後に実測する**：ブラウザの開発者ツール（Networkタブ）でページを読み込み、1MBを超える画像がないかを確認します。前述の11.5MB画像のような事故は、この一手間で確実に防げます

手順3：キャッシュと読み込みの整理

**サーバー側キャッシュ**：エックスサーバーなど国内の主要レンタルサーバーには、サーバー側の高速化機能（キャッシュや静的化）が標準で用意されています。プラグインを足す前に、まず契約中のサーバーの機能を有効化するのが安全です
**不要プラグインの削除**：使っていないプラグインはCSSやJavaScriptを読み込み続けていることがあります。停止ではなく削除まで行います
**演出の見直し**：前述のイントロローダーのように、演出が体感速度を落としていないかを見直します。演出を残す場合も、表示時間を必要最小限に詰めます

ここまでで、一般的なコーポレートサイトならLCP 2.5秒以内は十分に狙えます。**この段階で速度に不満がなくなったなら、ヘッドレス化は不要です**。

ヘッドレス化を検討すべきケースと、その判断基準

ヘッドレス化とは、WordPressを記事管理の裏方に徹させ、表側をAstroなどで静的HTML（SSG）として書き出す構成です。あらかじめ全ページが完成品のHTMLとして生成されるため、PHPの処理もデータベースへの問い合わせも発生せず、表示速度は原理的に最速クラスになります。

ただし、弊社が自社サイト（graciauto.jp）の再構築で見積もった実数では、**初回のヘッドレス構築は9〜12.5人日**かかります。テンプレート化して2件目以降は2〜4人日まで圧縮できますが、それでも「キャッシュ設定と画像最適化なら数時間」という改善と比べれば、桁が違う投資です。

だからこそ、判断基準を明確にしておく必要があります。弊社の線引きは次の通りです。

**WordPressのまま高速化で足りるケース**

遅さの原因が画像・キャッシュ・プラグインにある（＝計測で特定できている）
サイトの役割が「会社案内＋ブログ」で、現状の運用に大きな不満がない
予算・工数を最小に抑えたい

**ヘッドレス化を検討すべきケース**

高速化を尽くしてもLCPが目標に届かない、あるいは速度をサービスの売りにしたい
サイトリニューアルの時期が近く、どうせ作り直すタイミングである
WordPress本体の保守負担（アップデート・セキュリティ・表示崩れ）を減らしたい
同じ構成で複数サイトを展開する計画があり、テンプレート化の投資が回収できる

ポイントは、**ヘッドレス化は「速度改善の施策」というより「サイトの作り方そのものの変更」**だということです。速度はその結果ついてくるメリットのひとつであって、速度のためだけに選ぶと投資対効果が合いません。逆に、リニューアルのタイミングが重なるなら、最初からヘッドレス（SSG）で設計するのは合理的な選択です。

ヘッドレス化するなら、必ずSSG（静的生成）で設計する

ヘッドレス化を選ぶ場合に、ひとつだけ絶対に外せない設計上の注意があります。それは**レンダリング方式をSSG（静的サイト生成）にする**ことです。

ヘッドレス構成には、ブラウザ上でJavaScriptがページを組み立てるCSR（クライアントサイドレンダリング）という方式もあります。ReactなどのSPAで組むとこの方式になりがちですが、CSRで作ると、生のHTMLに本文が存在しないため、**検索エンジンにコンテンツが正しく評価されないリスクがあります**。これは理屈だけの話ではなく、弊社が自社サイトのHTMLソースとインデックス状況を実際に検証して確認した現象です。記事ページの生HTMLに本文が1文字もなく、canonicalタグがトップページを指し、sitemapに記事URLが載っていない——表示は普通にできているのに、検索エンジンから見ればコンテンツが空のサイトになっていました。

「表示速度を上げるためにヘッドレス化したら、検索流入が消えた」では本末転倒です。SSGなら、ビルド時に本文・canonical・OGP・構造化データがすべてHTMLに焼き込まれるため、この問題は設計段階で消えます。速度とSEOを両立させたいなら、方式はSSG一択と考えてください。

まとめ：順番を守れば、費用をかけずに解決できることが多い

WordPressの表示速度改善は、次の順番で進めれば大きく外しません。

1. **計測**：PageSpeed Insights（継続的に見るならSite Kit）で原因を特定する

2. **画像**：リサイズ・WebP化・遅延読み込み。公開後にファイルサイズを実測する工程をルール化する

3. **キャッシュ・整理**：サーバー標準の高速化機能を有効化し、不要プラグインと過剰な演出を削る

4. **それでも足りなければヘッドレス化**：ただし方式は必ずSSG。リニューアルや複数サイト展開のタイミングと重ねて投資回収を設計する

弊社の実務経験では、1〜3で解決するサイトが大半です。11.5MBの画像が1枚あるだけで、どんな高速なサーバーもヘッドレス構成も台無しになります。まずは計測から始めてください。

自社サイトの速度診断や、リニューアルに合わせたヘッドレス化のご相談は、名古屋のWEB制作会社graciautoまでお気軽にどうぞ。