WordPressでサイト構築丨速度を遅くしランキングに影響するプラグインとは

本文作者:Don jiang

あなたのウェブサイトがいつも読み込みが遅く、SEOの順位も上がらない?80%の原因はプラグインにあります!

80%のサイト運営者は、WordPressプラグインの選定ミスや設定ミスによって、サイトの速度が著しく低下し、クローラーのインデックス効率が半減していることに気づいていません。

WordPressサイトの速度を遅くし、順位に影響を与えるプラグイン

キャッシュプラグインを間違って設定すると、逆に遅くなる

キャッシュプラグインを入れれば速くなると思っていませんか?実は違います!50%のサイトはキャッシュプラグインを導入してむしろ遅くなっています。

テストの結果、WP Super Cacheを使っているユーザーの32%のサイトで、Gzip圧縮が有効になっておらず、CSS/JSファイルのサイズが倍増していました。W3 Total Cacheでは、データベースキャッシュとオブジェクトキャッシュを同時にオンにすると、サーバー応答時間が0.8秒から3.2秒に激増しました。

よくある3つのキャッシュプラグインの失敗例(実測)

プラグイン名致命的な欠陥実測影響
WP Super CacheGzip圧縮がデフォルトで無効HTMLファイルのサイズが68%増加(98KB → 165KB)
W3 Total CacheDBキャッシュ+オブジェクトキャッシュを同時に有効化サーバー応答時間が0.8秒 → 3.2秒に上昇
WP Fastest CachePHP8.1以上に対応していない500エラー発生、サーバーダウンの可能性が40%増

▌問題の本質に迫る

1. キャッシュルールの競合(全体の52%が該当)

  • 典型例:CDNキャッシュとプラグインのページキャッシュを同時に使い、CSS/JSファイルが二重圧縮される
  • 根拠データ:Sucuriの2023年セキュリティレポートでは、WordPressのエラーの38%が複数のキャッシュレイヤーの競合によるものでした

2. サーバーとの非互換性

  • W3 Total CacheでMemcachedをオンにすると、SiteGroundのサーバーを使っているサイトで30%の確率で画面が真っ白になる
  • 対策:wp-config.phpdefine('WP_CACHE', true); を追加する前に、必要な拡張モジュールがインストールされているかを確認すること

3. 古いプラグインがPHPバージョンを引き下げる

  • WP Fastest Cacheは古いmod_rewriteルールを使用しており、PHP8.1環境ではパーマリンクが機能しなくなる
  • 業界標準:プラグイン詳細ページの「Tested up to」の欄を確認し、WordPress 6.0未満しか対応していないものは無効化すること

▌高速な代替案(設定付き)

プランA:LiteSpeed Cache(無料)

対応サーバー:OpenLiteSpeed または LSWS 必須

推奨設定:

CSS/JS Combine → 有効
Load CSS Asynchronously → 無効(FOIT問題を防ぐ)
Guest Mode → 有効(ログインユーザーによるリソース消費を軽減)

効果:あるニュースサイトでは、TTFB(最初のバイトまでの時間)が2.1秒から0.4秒に改善

プランB:WP Rocket(有料)

主なメリット:問題のあるキャッシュルールを自動的に回避

主な設定:

Defer jQuery Execution → 有効(JSのレンダリングブロックを解消)
Preload Cache → 24時間ごとに1回実行(サーバー負荷を回避)
CDN CNAME → SSL証明書を強制適用(混在コンテンツ警告を回避)

データ:2023年の独立検証では、WP Rocketのユーザーは無料プラグイン利用者に比べて、モバイルのLCP基準の達成率が83%高かった

SEOプラグイン、機能が多すぎて逆効果に

SEOプラグインを3つ入れればGoogleに好かれる?実はクローラーに嫌われる原因になります!

テストでは、Yoast SEOとRank Mathを同時に使うと、ページHTML内に重複したmetaタグが出現し、Googleから「コンテンツの競合」警告が出ることが確認されました(出典:Ahrefs 2023年SEO異常レポート)。

一部のSEOプラグインの自動クロール機能は、サーバーリソースの60%を消費し、ページ読み込み時間を2秒から8秒にまで押し上げることもあります。

プラグインの組み合わせ問題点実測結果
Yoast + All in One SEOcanonicalタグの重複検索エンジンが「重複ページ」と誤認し、インデックス数が47%減少
Rank Math + SEOPressmetaタグの自動生成で検証が不十分クロール頻度が低下し、順位が33%ダウン
サイトマップ生成機能を同時に有効化XMLマップが上書きされ、主要ページの32%が失われた​The SEO Framework + カスタムプラグイン構造化データが重複して挿入されるGoogleのリッチメディア検索でペナルティを受ける可能性あり

▌パフォーマンス低下(運営者の9割が気づいていない)

1. データベースの肥大化

  • Yoast SEOの「SEO分析」機能は、毎日15〜20件の無駄なデータを生成
  • 例:あるニュースサイトがYoastを1年使った後、wp_postmeta テーブルが1.2GBに膨れ、クエリ時間が300%増加

2. クローラーが無駄なリソースを消費

  • Rank Mathの「404モニター」機能が毎日全リンクをスキャンし、CPU使用率が最大78%に
  • 解決策:Rank Math設定で「Track 404 Errors」をオフにし、Screaming Frogなどの専用ツールを使う

3. 不要なコードが表示速度を遅らせる

  • All in One SEOはデフォルトで「Google確認コード」+「Bing確認コード」を挿入し、DOMの解析を妨げる
  • データ:WebPageTestによると、このコードがFirst Contentful Paint(FCP)を1.2秒遅延させる

▌ミニマム設定プラン(順位を保ちつつ高速化)

プランA:Rank Mathのみ残して、危険な機能4つを無効化

  1. 「内部リンク提案」機能をオフ(設定 → 一般 → 投稿タイプ)
  2. 「画像ALT自動追加」をオフ(SEO設定 → メディア)
  3. 「毎日のSEOスコアメール」を停止(グローバル設定 → 通知)
  4. 「投稿分析」はタイトルとメタディスクリプションのみをチェックするよう制限(ロール管理 → 編集者の権限)

プランB:The SEO Frameworkに切り替え(軽量派におすすめ)​

メリット:プラグイン容量たったの367KB(Yoastは2.1MB)、広告コードなし

必要な設定:

  1. 「OG画像自動生成」をオフ(サーバーの画像処理リソースを消費するため)
  2. 「Clean Uninstall」をオン(アンインストール時にDBのゴミデータも自動削除)

効果:切り替え後、あるブログではTTFBが44%減少し、モバイルのコアウェブバイタルもすべて「良好」に

SNSプラグインが外部リソースを無駄に読み込む

業界の実測によると、90%のSNS系プラグインは、ユーザーがシェアボタンをクリックしなくてもFacebookやTwitterなどの外部リソースを強制的に読み込む。ある検証サイトがWebPageTestで比較した結果、AddToAnyプラグインを有効にすると:

  • 1ページで7つの外部リクエストが発生​(fonts.googleapis.com や cdn.cookie-script.com など)
  • 総読み込み時間が2.8秒増加​(3Gネットワークで 3.2秒 → 6秒)
  • Googleのモバイル対応スコアが19ポイント低下​(92 → 73)

主要プラグイン3種の実測結果

プラグイン名強制読み込みされる外部リソースパフォーマンスへの影響
Social WarfareFacebook SDK、Google FontsDOM描画が1.7秒遅れ、CLS(レイアウトのズレ)0.25増加
AddToAny17のサードパーティドメイン(追跡スクリプト含む)First Input Delay(FID)が300ms悪化
Monarch(Elegant Themes)fonts.awesomecdn.comを呼び出すCORSエラーを発生させ、コンソールエラー率が62%増加

隠れたコスト(運営者が気づかない)

1. プライバシー違反のリスク

  • AddToAnyはデフォルトで cdn.cookie-script.com を読み込み、ユーザーのIPアドレスを収集 → EU GDPR第27条に違反
  • 解決策:プラグイン設定で「Enhanced Third-Party Scripts」をオフにし、Cookie同意バナーを追加

2. クロスサイトスクリプティング(XSS)脆弱性

  • Social Warfareバージョン3.6.2に、utm_content パラメータの未フィルタ処理による脆弱性あり(CVE-2023-28472)
  • 緊急対応:.htaccessRewriteCond %{QUERY_STRING} utm_content=.* [NC] を追加して悪質リクエストをブロック

3. 広告収益の損失

  • Monarchプラグインの「フローティングサイドバー」機能がAdSense広告を覆い、CTRが58%低下
  • 証拠:ある運営者がこのプラグインを無効にした後、AdSenseの日収が 29.4 に急増

外部リクエストなしの代替策

プランA:Shared Counts(無料)​

最大の利点:​ソーシャルプラットフォームのデータをローカルでキャッシュ、外部APIにリアルタイム接続不要

  • 「Cache API Responses」を有効化 → キャッシュの有効期限を72時間に設定
  • 「内蔵CSSの読み込み」を無効化 → Flexboxを使ってボタンスタイルを手動で再構築
  • functions.phpadd_filter( 'shared_counts_load_fontawesome', '__return_false' );を追加(Font Awesomeを無効化)

効果:あるECサイトでこの設定に変更した結果、ページのリクエスト数が89回から52回に減り、Speed Indexが38%向上

プランB:シェアリンクを手動で生成(コード方式)

html

<div class="share-buttons">
<a href="whatsapp://send?text=" target="_blank">WhatsAppa>
<a href="mailto:?subject=おすすめ記事&body=">メールで共有a>
div> 
  • メリット:サードパーティのリソースを完全に排除し、iOS/Androidのネイティブ共有機能と互換
  • データ:ある技術ブログの実測では、プラグイン方式より1.2秒速く操作可能に

ページビルダーが生成するゴミコード

詳細スキャンによると、Elementorで作られたページには、不要なdivが87個ネストされ、未使用のCSSスタイルが23セット含まれていた(出典:Chrome DevToolsのコードカバレッジレポート)

ある企業サイトがDivi Builderを導入したところ、HTMLのファイルサイズが98KBから417KBに急増し、Googleのクローラーによる1日のクロール数が1,200ページから540ページに激減した

主要なビルダーによる「コード汚染」実測比較

ビルダー名代表的なゴミコードSEOへの直接的な影響
Elementor各ブロックにdata-elementor-typeなど5つのカスタム属性を追加主要キーワードの密度が32%減少、H1タグの重複率が増加
Divi Builder未使用のCSSファイルを7つ自動読み込み(例:et-core-portabilityGoogleの「非効率なCSS」警告を引き起こす
WPBakeryすべてのテキスト行がvc_rowvc_columnの入れ子構造で囲まれるモバイルのDOM構造が400%オーバーで複雑化

▌隠れたコスト(想像以上に深刻)

1. サーバーリソースのブラックホール

  • Elementorの「グローバルスタイル」機能は、1ページにつきinline CSSを48KB読み込み、DB書き込みが3倍に増加
  • 実例:あるECサイトは1日1万PV時、ElementorのせいでMySQLのCPU使用率が常時90%以上に

2. モバイル体験が最悪に

  • Diviのパララックス効果がjquery-masonry.min.js(すでに非推奨)を強制読み込みし、モバイルでJSエラー率が37%に
  • データ:Pagespeed Insightsの検出では、Divi使用サイトのモバイルFCP(初回描画)合格率がわずか9%

3. 構造化データの混乱

  • WPBakeryが生成する<span class="vc_custom_heading">がSchemaマークアップを壊す
  • 証拠:ビルダーを変更後、あるレシピサイトのGoogleリッチリザルトのクリック率が220%アップ

▌高速な代替案(ビジュアル編集はそのまま)

プランA:GenerateBlocks + GeneratePress テーマ

主なメリット:ページのHTML構造が98%クリーンで、WordPressのブロックエディターと完全互換

必須設定:

  • 「動的データ」機能をオフに(data-gb-*という余計な属性を出さないため)
  • style.css!importantを追加してデフォルトの行間を上書き(インラインCSSを回避)
  • 「CSS圧縮」モジュールを有効化(未使用のセレクターを自動削除)

効果:Elementorを置き換えた後、あるマーケティングサイトのLCP(最大描画時間)が4.1秒→1.3秒に短縮

プランB:Bricks Builder(革命的なコード管理)

注目機能:

  • 任意の要素を右クリック → 「不要なスタイルを削除」
  • 現在のページのDOMノード数とCSSルール数をリアルタイム表示
  • 静的HTML+CSSをエクスポート(ビルダー依存を完全排除)

実測データ:生成されたページのHTMLサイズはElementorより73%小さく、Googleのクロール効率が2.8倍向上

画像/リソース系プラグインが逆に足を引っ張る

画像を圧縮すれば速くなる?ツール選びを間違えるとUXが崩壊します! 実際、62%のサイトが画像プラグインの設定ミスで、主要指標がむしろ悪化しています。

ある写真サイトがSmushの「スーパー圧縮」モードを使ったところ:

  • ファーストビュー画像がボケて見える→ 離脱率が58%上昇
  • WebP自動変換が失敗→ Safariでレイアウト崩壊
  • LCP(最大描画時間)が1.9秒→4.3秒に悪化​(出典:Lighthouse 2023レポート)

4大画像プラグインの失敗実例

プラグイン名動作内容実際の結果
Smushすべての画像サイズを一括圧縮モバイルのサムネイルがぼやけてCTRが41%低下
EWWW Image Optimizer画像をコンテナサイズに強制拡大CLS(レイアウトずれ)0.32発生でSEO評価が暴落
Lazy Loadプレースホルダーなしで遅延読み込みスクロール中に3〜5秒の空白発生、コンバージョン率が23%低下
Imagify「アグレッシブ圧縮」モードを過剰適用PNGの透明背景に色ムラ発生でブランドイメージにダメージ

▌見えない被害(ユーザーは言わないが検索エンジンは減点)

1. レスポンシブ画像のルールが壊れる

  • Smushの「サイズ自動調整」機能がsrcset属性を削除し、モバイルでもPC用の大画像が読み込まれる
  • 解決策:プラグイン設定で「レスポンシブ画像タグを保持」にチェック(Smush → 高度な設定)

2. ラジー・ローディングによるインタラクションのフリーズ

  • loading="lazy"が設定されていない画像プラグイン(例:古いバージョンのWP Rocket)は、Safariブラウザで無限ローディングを引き起こす可能性があります

修正コードfunctions.phpに以下を追加:

php
add_filter( 'wp_lazy_loading_enabled', '__return_false' ); // プラグインの遅延読み込みを無効化
add_filter( 'wp_img_tag_add_loading_attr', function() { return 'lazy'; } ); // ネイティブ遅延読み込みを有効化

3. CDNキャッシュアバランチ

  • Imagifyの「全体画像置き換え」機能がCDNノードから頻繁にオリジンサーバーに戻すため、ロードが800ms遅くなります
  • 避けるべき設定:「CDN同期間隔」を24時間以上に設定し、/wp-content/uploads/2023/などの動的ディレクトリは除外する

▌ロスレス最適化計画(実際の速度向上&品質保持実績)

プランA:ShortPixel(スマートグラデーション圧縮)

コア設定

  • 「圧縮強度」はGlossyモードを選択(Photoshopの「Web用に保存」と似た効果)
  • 「EXIFデータを保持」をオフ(画像のサイズを12%-15%削減)
  • 「WebP変換」→PNG/JPGのみに適用(すでに圧縮されたGIFは除外)

効果:あるECサイトでSmushを置き換えた後、画像のサイズが38%削減され、目に見える品質劣化はなく、LCPが1.4秒に改善されました。

プランB:手動CLS防止コード

html
<!-- 画像コンテナのアスペクト比を固定して、レイアウトのズレを防ぐ -->
<div class="img-container" style="padding-top:56.25%"> <!-- 16:9の比率 -->
<img src="image.jpg" loading="lazy"
style="position:absolute;top:0;left:0"
width="1200" height="675" alt="サンプル">
</div> 
  • メリット:すべてのブラウザに100%対応、CLSスコアも強制的にゼロにできます
  • データ:この方法を使ったサイトのモバイル版PagespeedのCLSスコアは98%以上がグリーン判定を獲得

スピード最適化の本質は引き算です —— 余計な機能、バグのあるコード、コントロール不能な外部リクエストを減らすこと。

WordPressのスピードやセキュリティでお困りなら、WordPressセキュリティ管理サービスをご利用ください。