「うちのサイト、ちょっと重いかも」と感じながらも、デザインや機能改善を優先してきたサイト担当者は少なくありません。しかし、その「ちょっと重い」が毎月どれだけの売上機会・問い合わせ・SEO評価を失わせているか、具体的な数字で把握しているでしょうか。

本記事では、Googleや国際的な調査機関が公表した統計データをもとに、WordPressサイトの表示速度がビジネス成果に与えるリアルな影響と、優先度の高い改善手法を解説します。

表示速度とビジネス成果の関係：数字が示す現実

直帰率への影響：「3秒の壁」は今も健在

Googleが公表したモバイル速度に関するデータによると、ページの読み込みが 1秒から3秒に延びるだけで直帰率は32%増加します。5秒かかると90%増、10秒かかると123%増という結果が出ています。

読み込み時間 → 直帰率増加率（対1秒比）
1秒  → 基準
3秒  → +32%
5秒  → +90%
6秒  → +106%
10秒 → +123%

出典：Google / SOASTA Research, 2017

また、Google（2016年）の調査ではモバイルページの読み込みが3秒を超えると、訪問の53%が離脱する可能性があると報告されています。スマートフォン経由のアクセスが過半数を占める現在、これは致命的な損失です。

コンバージョン率・売上への影響

デロイトが欧州・米国の小売サイトを対象に実施した調査「Milliseconds Make Millions」（2020年）によると、モバイルサイトの速度が0.1秒改善するだけで以下の変化が確認されています。

指標 改善率
コンバージョン率 約8.4%向上
平均注文金額 約9.2%向上
直帰率 低下
ページ閲覧数 約7%増加

「0.1秒」というのは、人間が知覚できない変化です。それでもこれだけのビジネス成果が変わります。

さらに、Googleの「PageSpeed Insights」などのツールを活用したケーススタディでは、LCP（最大コンテンツ描画時間）を改善したサイトがコンバージョン率を2〜15%改善した事例が複数報告されています。

著名企業の事例データ

Amazonの社内実験では、100ms単位のページ遅延が収益に直接的な悪影響を与えたことが2006年頃から報告されています。また Google でも、検索結果の表示を意図的に遅くした実験で検索数が大幅に落ちたことが知られており、速度低下がサービス利用そのものを減らしうることを示す事例として広く引用されています。

【企業別の速度改善効果（web.dev Case Studies より抜粋）】

Renault:
1秒のLCP改善 → コンバージョン +13%、直帰率 -14ポイント

Vodafone:
LCP 31%改善 → 売上 +8%

The Economic Times:
LCP最適化 → 直帰率 -43%

Netzwelt:
LCP + CLS改善 → ページビュー +18%

表示速度がSEOに与える影響：Core Web Vitalsとは

Googleがランキング指標として採用

2021年6月、GoogleはCore Web Vitalsを検索順位の正式なランキングシグナルとして採用しました（Page Experience Update）。これにより、サイトの使いやすさが検索順位に直結する時代が始まりました。

Core Web Vitalsは以下の3指標で構成されます。

Core Web Vitalsの3指標と目標値

LCP（Largest Contentful Paint：最大コンテンツ描画時間）

ページを開いてから、最も大きな画像やテキストブロックが表示されるまでの時間です。

良好   ：2.5秒以内   ← 目標値
改善必要：2.5〜4.0秒
不良   ：4.0秒超

WordPressでは多くの場合、ヒーロー画像や大きなバナー画像がLCP要素になります。画像の最適化と優先読み込みが改善の核心です。

INP（Interaction to Next Paint：インタラクションへの応答時間）

クリックやタップなどのユーザー操作に対して、ページがどれだけ素早く反応するかを示します。2024年3月に FID（First Input Delay）から INP に移行し、より厳密な評価基準となりました。

良好   ：200ms以内   ← 目標値
改善必要：200〜500ms
不良   ：500ms超

CLS（Cumulative Layout Shift：累積レイアウトシフト）

ページ読み込み中に要素が突然動く「ガタつき」の程度を示します。広告の後挿入や、サイズ指定のない画像が原因になることが多いです。

良好   ：0.1以下    ← 目標値
改善必要：0.1〜0.25
不良   ：0.25超

SEOへの具体的な影響

Core Web Vitalsはランキングの「決定的な要因」ではなく「複合シグナルのひとつ」ですが、コンテンツの質が同等のサイト同士では差別化要因になります。

より直接的な影響として、表示速度はGoogleのクロール効率にも影響します。表示が遅いサイトはGooglebotのクロール頻度が下がり、新しいコンテンツのインデックス登録が遅れる可能性があります。

また、前述の直帰率・滞在時間・ページ閲覧数といった行動指標の悪化は、間接的にSEO評価を引き下げる要因にもなります。

WordPressサイトが遅くなる主な原因

WordPressはプラグインや拡張機能が豊富な分、パフォーマンス上のリスクも多く存在します。以下が代表的な原因です。

原因1：最適化されていない画像

WordPressのパフォーマンス問題の中で最もインパクトが大きいのが画像です。

よくある問題：
- JPEGやPNGのまま（WebP/AVIFに変換していない）
- 表示サイズより大きな画像をそのまま使用
- ヒーロー画像に loading="lazy" が設定されている
- srcset/sizes属性が設定されていない

改善効果：
- WebP変換だけで画像サイズが平均約30%削減（WordPress公式）
- AVIFはさらにJPEG比50%以上の削減例あり（web.dev）

原因2：過剰なプラグインとJavaScript

WordPressの利便性の源であるプラグインが、速度の最大の敵になることもあります。

問題が起きやすいパターン：
- 使っていないが削除していないプラグイン
- フロントエンドにJavaScript・CSSを読み込むプラグイン
- 全ページで動作するSNSシェアボタン、フォームプラグイン
- 複数のページビルダー（Elementor、Gutenberg等）の共存
- 計測タグ・マーケティングツールの乱立

INP（インタラクション応答性）への影響が特に大きいです。

原因3：キャッシュなし・サーバー設定の問題

WordPressはデフォルトでリクエストのたびにPHPを実行し、データベースに問い合わせます。キャッシュがなければ、アクセスが増えるほど表示が遅くなります。

TTFBが遅い場合の主な原因：
- ページキャッシュ未導入
- OPcacheの無効化
- 低性能・過密な共有サーバー
- autoload optionsの肥大化
- PHP バージョンが古い（8.0未満）
- データベースの不要データ蓄積（リビジョン、transients等）

autoload optionsの肥大化とは

プラグインの多くは設定値をWordPressのwp_optionsテーブルに保存します。この設定値のうちautoload=onになっているものは、サイトのすべてのページが読み込まれるたびに自動でメモリに展開されます。

WordPress Site Health の監視閾値は 800,000 bytes（約800KB）ですが、プラグインを増やし続けたサイトでは数MBに達することも。これが全ページの表示速度に影響を与えます。

原因4：レンダーブロッキングCSS・JS

<head> タグ内にある CSS・JavaScript ファイルは、読み込みが完了するまでページの描画を止めます（レンダーブロッキング）。

典型的な問題：
- 利用していないCSSが大量に読み込まれている
- JavaScriptが defer/async なしで読み込まれている
- 複数のCSSファイルが個別に読み込まれている
- 外部フォント（Google Fonts等）の同期読み込み

具体的な改善手法と期待できる効果

手法1：画像最適化（最優先）

実施すべき内容：
1. WebP/AVIF形式への変換（Imagify、Shortpixel等で自動化可）
2. ヒーロー画像に fetchpriority="high" を設定
3. ヒーロー画像には loading="lazy" を設定しない
4. スクロール下の画像には loading="lazy" を設定
5. srcset/sizes 属性で解像度別に最適な画像を配信
6. 表示サイズを超えた画像を使わない

WordPress 6.3 以降の改善：
- LCP候補画像への fetchpriority="high" 自動付与でLCPが5〜10%改善
- WordPress 5.8以降、WebP形式のアップロードをネイティブサポート

手法2：ページキャッシュの導入

ページキャッシュはWordPressの速度改善で最も費用対効果が高い施策です。PHPとデータベース処理をスキップして静的HTMLを直接配信するため、ブログやコーポレートサイトでは数十〜数百倍の性能差が出ることもあります。

主要なキャッシュプラグインの比較

プラグイン 特徴 対象
WP Rocket（有料） 設定が簡単、LCP/INP改善しやすい 初心者〜中級者
LiteSpeed Cache（無料） サーバー連携、画像最適化も一体 LiteSpeedサーバー利用者
W3 Total Cache（無料） 高機能、細かく調整可能 中級者〜上級者
WP Super Cache（無料） シンプルな静的HTML生成 ブログ・小規模サイト

注意：キャッシュ系プラグインは1つに絞るのが原則です。複数導入は競合や不具合の原因になります。

W3 Total Cache の公式テスト結果では、Full Site Delivery 機能適用後にサーバー応答時間が 3,413ms から 34ms（約99%改善）、LCPが 7.0秒から3.04秒（約56%改善）になった事例が紹介されています。

手法3：PHP・サーバー環境の最適化

必ず確認すべき項目：
□ PHPバージョン：8.1以上（8.2〜8.3推奨）
□ OPcache：有効になっているか
□ HTTP/2 or HTTP/3：対応しているか
□ Brotli or gzip圧縮：有効になっているか
□ CDN：CloudflareやKeyCDN等を導入しているか

OPcacheの効果：
PHPはデフォルトでスクリプトを毎回コンパイルして実行します。
OPcacheはコンパイル済みのバイトコードをメモリに保持することで、
この処理を省略します。WordPress公式は「many times」の改善と案内。

手法4：不要なJavaScript・CSSの削減

実施内容：
1. 使っていないプラグインを完全削除（無効化だけでなく削除）
2. 各プラグインがどのページでJSを読み込んでいるか確認
3. 必要なページ以外ではJSを読み込まないよう設定
4. 使用していないCSSの排除（WP Rocketの「未使用CSS削除」等）
5. JavaScriptのdeferまたは非同期読み込み

INP改善に直結します。長いメインスレッド処理を持つJSは
ユーザー操作への応答性を著しく下げます。

手法5：データベースの最適化

定期的に実施すべき作業：
□ 投稿リビジョンの上限設定（デフォルトは無制限）
□ 期限切れtransientsの削除
□ ゴミ箱・スパムコメントの削除
□ wp_options のautoload項目の確認と不要なものをautoload=off化
□ WooCommerce利用時：セッションデータの定期クリーンアップ

// wp-config.php でリビジョン数を制限する例
define( 'WP_POST_REVISIONS', 5 );  // 最新5件のみ保持
define( 'AUTOSAVE_INTERVAL', 300 ); // 自動保存間隔を5分に

手法6：オブジェクトキャッシュ（Redis）の導入

通常のページキャッシュでカバーできないログインユーザー向けページや、WooCommerceのカート・マイページには、RedisやMemcachedを使ったオブジェクトキャッシュが有効です。

効果が高いサイト：
- WooCommerce（商品数・注文数が多いほど効果大）
- 会員制サイト
- 検索・絞り込み機能があるサイト
- ログインユーザーが多いメディア

Redis導入後のデータベース問い合わせは、
同一マシン構成の場合ミリ秒単位から マイクロ秒単位 に短縮されることも
（Kinsta 公式ドキュメントより）。

改善の優先順位チェックリスト

速度改善を進める際の優先順位を整理します。

最優先（即日〜1週間）

高優先（1〜2週間）

中優先（1〜2ヶ月）

定期実施（月次）

WordPress特有の速度問題：バージョンアップも重要

WordPressのコア自体も継続的にパフォーマンス改善が行われています。古いWordPressバージョンを使い続けることは、セキュリティリスクだけでなく、速度面でも損失が生じます。

WordPressバージョン別のパフォーマンス改善実績：

WordPress 6.3（2023年）
- LCP候補画像に fetchpriority="high" 自動付与
- LCP 5〜10% 改善

WordPress 6.4（2023年）
- 6.3.2比でサーバー応答時間 約4% 改善
- LCP 約4〜9% 改善

WordPress 6.8（2025年）
- Speculative Loading 追加（リンク遷移前にページをプリロード）
- INP改善のためのInteractivity API非同期処理強化

WordPress 6.9（2025年予定）
- 6.8比でサンプルページの平均LCP：クラシックテーマ -4%、ブロックテーマ -25%

最新バージョンへのアップデートだけで、追加コストなしにLCPや応答速度が改善されるケースが少なくありません。

現実的な目標値と計測方法

サイト種別ごとの現実的な目標

サイト種別 LCP目標 INP目標 CLS目標
コーポレートサイト 1.8〜2.5秒 100〜200ms 0.02〜0.08
ブログ・メディア 1.8〜2.5秒 100〜200ms 0.02〜0.08
ECサイト（WooCommerce） 2.0〜2.8秒 <200ms <0.1

TTFB（Time to First Byte：サーバー応答時間）は 0.8秒以内を目安にすると、LCP改善の全体設計がしやすくなります。

計測に使うべきツール

PageSpeed Insights（無料・推奨）

  • GoogleのCrUX（実ユーザーデータ）とLighthouse（ラボ計測）を両方確認できる
  • CrUXは「実際のユーザーがどう体験しているか」を示すため、ラボ計測より信頼性が高い
  • URL: https://pagespeed.web.dev/

Google Search Console

  • Core Web Vitals レポートで「不良」「改善が必要」なページを一覧確認できる
  • 実ユーザーデータに基づき、改善対象ページを優先度付けできる

CrUX Dashboard（Looker Studio）

  • 過去の推移をグラフで確認できる
  • 施策前後の変化検証に有効

まとめ

WordPressサイトの表示速度は、「使いやすさ」の問題ではなく、ビジネス成果に直結するKPIです。

  • 読み込み時間が3秒になるだけで直帰率は32%増加
  • 0.1秒の改善でコンバージョン率が約8%、平均注文金額が約9%改善
  • Core Web VitalsはGoogleのランキングシグナルであり、不良のままだとSEO上も不利

ただし、「全部一度に直そう」とすると工数が膨大になります。まずは PageSpeed Insightsで現状を計測し、LCPの問題が画像にあるのかサーバーにあるのかを特定することから始めるのが最短経路です。

今すぐできる最初の一歩

赤信号（今日中に確認）

黄信号（今週中に対応）

青信号（今月中に対応）

速度改善は一度やれば終わりではなく、プラグイン追加や記事掲載のたびに影響が出ます。月1回のPageSpeed Insightsチェックを習慣にすることで、劣化に早期に気づき、対処できる状態を保てます。

参考情報（公開レポート・ガイドライン）