SWELL最適化の完全ガイド｜おすすめプラグイン最小構成と、SWELL設定だけで速くする手順

はじめに（SWELLが重くなる典型パターン／この記事で救う宣言）

SWELLが重くなる原因は、ほぼパターン化されています。
「便利そう」に見えて入れたプラグインが、SWELLの標準機能と被っている。
その結果、速度も安定性も落ちます。

典型パターンはこの3つです。

• 重複：目次、吹き出し、画像遅延、装飾、最適化などを「別プラグインで上乗せ」
• 多重高速化：キャッシュ／CSS最適化／JS遅延を複数プラグインで二重三重に適用
• 画像・フォントの設計ミス：LCP（体感速度）が詰む

この記事は、ここから抜け出すための手順書です。
怖い削除作業は、停止→表示確認→削除の順で進めます。
SWELLの高速化は、弱い施策→強い施策で段階導入します。

この記事のゴール（到達点を箇条書き）

• 最小プラグイン構成が確定する
• SWELLと被る削除候補が明確になる
• SWELLの高速化設定を“事故らない順番”で導入できる
• PageSpeed Insights / Search Consoleで検証できる

結論：SWELL最適化は「プラグインを増やす」ではなく「重複を消してSWELL設定を入れる」

SWELL最適化の結論は、これです。

• SWELLは「足し算」ではなく「引き算」で速くする
• プラグインは用途別に「どれか1つ」
• 高速化は、まずSWELLの標準機能を使う

SWELL公式も、目次・画像遅延・吹き出し等はSWELL標準機能と被りやすく基本不要、さらにJetpack等の中に含まれる場合は該当機能をオフにする、と明示しています。

SWELLで入れるべきプラグイン最小セット（迷ったらこれだけ）

まず、迷いを消します。
「最小構成」を先に決める。ここがブレると一生安定しません。

最小プラグイン構成（用途別の表）

目的	必須度	原則（どれか1つ）	選定理由（軽さ／事故率）
SEO	必須	SEO系プラグインを1つ	2つ入れた瞬間にメタ情報やサイトマップが競合しやすい
バックアップ	必須	バックアップ系を1つ	これから「止める・消す」をやる。復元手段がないと詰む
セキュリティ	必須	セキュリティ系を1つ	“盛りすぎ”は重い。監視・WAF・ログが重複しやすい
お問い合わせフォーム	必須	フォーム系を1つ	信頼とCVの基盤。壊れると機会損失が大きい
サイトマップ	任意	SEOプラグイン or WP標準	WordPressコアにXMLサイトマップ機能がある（WP 5.5〜）

SEO（どれか1つ）—軽量重視の考え方

結論：SEOは「高機能」より「運用しきれる」が勝ちです。

理由：
SEOプラグインは、タイトル・ディスクリプション・OGP・構造化・サイトマップなど広範囲に触ります。
2つ入れると、競合しやすい領域です。

手順（迷わない決め方）

• すでに運用中のSEOプラグインがある → 原則そのまま（移行が一番事故る）
• これから入れる → 1つに決める（複数導入はしない）

注意点
サイトマップ機能をSEOプラグイン側で使うなら、別のサイトマップ系は基本不要です（重複生成を避ける）。

次の一手
SEOを決めたら「サイトマップ担当は誰か」を固定します（WP標準 or SEOプラグイン）。

バックアップ（どれか1つ）—導入前に必ずやる理由

結論：バックアップは保険ではなく「作業許可証」です。

理由：
最適化は、停止と削除が中心です。戻せない状態でやると判断が鈍ります。

手順（最低ライン）

• **ファイル＋データベース（DB）**を1セット取る
• 復元メニューの場所だけ確認する

注意点
自動バックアップの設定があっても、作業前に「今この瞬間」の手動バックアップを1本作る方が安全です。

次の一手
バックアップが取れたら、プラグイン棚卸しに進みます。

セキュリティ（どれか1つ）—盛りすぎると重い注意

結論：セキュリティは「2つ入れたら強い」ではなく「2つ入れたら重くて不安定」が起きます。

理由：
スキャン、ログ監視、WAF、ログイン保護が重複しやすいからです。

手順

• まずは1つに絞る
• そのプラグイン内で「不要な機能はOFF」にする

注意点
ログ記録やスキャン頻度が高い設定は、管理画面を重くしやすいです。

次の一手
「ログイン保護」「更新を止めない運用」を固めるだけで十分強くなります。

お問い合わせフォーム（どれか1つ）—信頼とCVの基盤

結論：フォームは「軽さ」より「届く・壊れない」が優先です。

手順

• フォームを1つに統一
• テスト送信（自分宛）を必ず実施
• 迷惑メールフォルダも確認

注意点
高速化（遅延・キャッシュ）で送信が壊れると致命的です。フォームページは除外候補に入れます。

サイトマップ（任意）—標準機能で足りる/足りない判断

結論：普通のブログなら、WP標準 or SEOプラグインで足ります。

根拠：
WordPressコアにXMLサイトマップ機能が導入されています（WP 5.5〜）。

足りる人

• 投稿・固定ページ中心
• SEOプラグインでサイトマップが出せている

足りない人

• News / Video / Imageサイトマップが必要
• 大規模で細かい除外設計が必要

削除候補（SWELLと被りやすいプラグイン）—ここが一番効く

ここが一番効きます。
理由は単純で、SWELLは標準機能が強いからです。

そして削除が怖い人のために、手順は固定します。

• 削除しない
• 停止→表示確認→削除
• これが事故率を最小化します

被りやすい削除候補（表）

カテゴリ	被りやすい例	なぜ削除候補？	競合しやすい症状
目次	目次生成プラグイン全般	SWELL標準機能と被りやすい（公式が例示）	目次が二重、CSS崩れ、CLS悪化
画像遅延（LazyLoad）	Lazy Load系	SWELL標準機能と被りやすい（公式が例示）	画像が出ない、LCP悪化、挙動不安定
吹き出し	Speech bubble系	SWELL標準機能と被りやすい（公式が例示）	デザイン崩れ、エディタが重い
高速化・最適化	キャッシュ／JS遅延／CSS最適化系	SWELL側に高速化機能があるため多重になりやすい	表示崩れ、計測タグが死ぬ、原因不明化
Jetpack等の多機能	速度/画像最適化機能を含むもの	内包機能が被る場合は該当機能をOFFと公式が明示	どこが効いてるか不明、競合

最短で成果を出すロードマップ（この順番でやれば事故らない）

Step1 バックアップを取る（必須）

• プラグインでバックアップを1本
• できればサーバー側バックアップも確認

この時点で「戻せる」ので、以降が怖くなくなります。

Step2 プラグイン棚卸しテンプレ（A必須/B必要/C被り/D用途不明）

プラグイン一覧を次に分類してください。

• A：必須（止めたら運営が止まる）
  例：SEO、フォーム、バックアップ、セキュリティ（最低限）
• B：必要（今は必要だが代替可能）
  例：リダイレクト、会員機能、EC、翻訳など
• C：被り（SWELL標準機能と重複しやすい）
  例：目次、吹き出し、画像遅延、高速化系
• D：用途不明（入れた記憶がない／停止中）
  例：試した残骸

Step3 まず停止→問題なければ削除（確認すべきページも列挙）

停止の順番

1. D（用途不明）
2. C（被り）
3. B（必要だが代替可能）
4. A（必須）は最後（基本触らない）

停止後に必ず見るページ（チェック）

• トップページ
• 記事ページ（人気記事1つ＋最近の記事1つ）
• 固定ページ（プロフィール／会社情報）
• カテゴリ・タグ一覧
• お問い合わせ（送信テスト含む）
• スマホ表示（1分でいい）
• 管理画面（投稿編集ができるか）

問題なければ削除。
問題が出たら戻して、次へ進む前に「原因候補」をメモします。

SWELL設定（高速化）が本丸—この順で入れる

SWELLは高速化機能をテーマ側に持っています。
設定場所は、基本的に**「SWELL設定」→「高速化」タブ**です。

ここからはルール通り、弱い施策→強い施策でいきます。

1）キャッシュ機能（最優先）—効果／反映されない時の対処

結論：まずキャッシュ。安全で効きます。

根拠：
SWELL公式が、キャッシュは「SWELL設定＞高速化」からオンオフでき、特別な事情がなければ全てオン推奨、と明記しています。

手順

1. 管理画面 → SWELL設定 → 高速化
2. キャッシュを段階的にON（最初は主要エリア）
3. 表示確認
4. 問題なければ範囲を広げる

注意点
会員制、動的表示、ABテスト等があるサイトは、全ONで不整合が出ることがあります。そういう箇所だけOFFに戻します。

次の一手
キャッシュONで安定したら「後読み込み」に進みます。

2）パーツの後読み込み（次に効く）—まずフッター・記事下から

結論：次は「見えない場所」から後読み込み。事故りにくいです。

根拠：
SWELL公式が、後読み込みは「SWELL設定＞高速化」で設定でき、フッターや記事下などを後から挿入できる、と説明しています。

手順（おすすめ順）

• フッター（フッター直前ウィジェット含む）
• 投稿ページの本文より下側（関連記事・CTAなど）
• 必要なら画像・動画

注意点（重要）
後読み込み対象に含まれるウィジェットは、ページ分岐処理が無効になるなど、挙動が変わるリスクがあります（公式の注意に従い、まずフッター／記事下からが安全です）。

次の一手
ここまでが「安全ゾーン」。次が上級のスクリプト遅延です。

3）スクリプト遅延（上級）—SNS→計測→広告の順で段階導入

結論：スクリプト遅延は効きます。
ただし壊れます。だから段階導入です。

根拠：
SWELL公式が「スクリプトの遅延読み込み」設定項目（オンオフ、対象キーワード、除外ページ、遅延時間など）と、キーワードは「,区切り」で入力する、と具体的に説明しています。

段階導入の順番

1. SNS埋め込み（X/Instagram等）
2. 次に計測（必要最小限）
3. 最後に広告（最も壊れやすい）

除外ページの考え方（最初から除外候補）

• お問い合わせ（送信が壊れると致命的）
• LP（CV計測が必要）
• 決済・会員・ログイン周り

注意点
「全部遅延」はやりません。
サイトの目的は“スコア”ではなく“収益と安定運用”です。

カスタマイザー側で体感を上げる（ページ遷移系）

結論：体感は上がります。
ただし、ファーストビューは速くなりません。

根拠：
SWELL公式が、ページ遷移高速化（pjax）はカスタマイザーの「高度な設定＞高速化機能」内で設定でき、あくまで遷移が速くなるだけで、ファーストビューは速くならず（むしろ読み込むスクリプトが増える）と注意しています。

軽い方式から試す指針

• まずは「使わない」または「Prefetch」
• pjaxは競合の可能性が上がるので、問題が出たら即OFFに戻す

画像とフォントが遅い人の典型—ここを外すとLCPで詰む

画像で詰む（LCP悪化）典型

• ファーストビューに大きい画像が多い
• 画像サイズが過剰（横幅が必要以上）
• YouTube埋め込みが多い

押さえるべき事実：
WordPressは5.5から画像を標準でlazy-loadします（HTMLのloading属性を使用）。
つまり、LazyLoad系プラグインを足すと、二重適用や競合になりやすいです。

対策

• ファーストビュー画像を適正サイズにする
• 大画像の連続を減らす（分割・圧縮）
• 画像は「メディア追加」から入れる（width/heightが入りやすくCLS対策にもなる）

フォントで詰む典型

• フォント種類・太さが多い
• Webフォントが無駄に読まれている

フォントは「見た目」ですが、LCP/CLSに効きます。
削れるなら削ります。

計測と検証（収益につなげる見方）

ここからが「成果が出る人」の動きです。
速くしたなら、数字で証明します。

LCP/INP/CLSを噛み砕く

• LCP：画面内で一番大きい要素（画像/テキスト/動画）が表示されるまでの時間
• INP：クリックやタップなどに対して、ページがどれだけ素直に反応するか（サイト全体の応答性）
• CLS：勝手にレイアウトがズレる量（予期しないガタつき）

PageSpeed → 施策1つ → 再計測 → Search Consoleで実ユーザー確認

結論：一気に直さない。必ず1施策ずつ。

根拠：
PageSpeed Insightsは、**lab data（実験室）とfield data（実ユーザー）**を提供し、用途が違うと明確に説明しています。
Search ConsoleのCore Web Vitalsレポートは、CrUX（実ユーザーデータ＝field data）を使うと説明されています。

手順（テンプレ）

1. PSIでURLを計測（Beforeを保存）
2. 施策を1つだけ実施（例：SWELLキャッシュON）
3. 表示確認
4. PSIで再計測（Afterを保存）
5. Search ConsoleのCWVで、後日「実ユーザー側」も確認

よくある失敗と回避策（事故パターンを潰す）

失敗1：高速化プラグイン多重

• キャッシュ＋最適化＋遅延が二重三重
• 原因が追えなくなる

回避策
SWELLのキャッシュ／後読み込み／スクリプト遅延を先に使う。

失敗2：画像一括変換事故

• 表示崩れ
• 元に戻せない

回避策
必ずバックアップ後に、小さく試す。

失敗3：計測/広告遅延でデータが死ぬ

• GAや広告の計測が飛ぶ
• 改善の判断材料がなくなる

回避策
遅延はSNS→計測→広告の順。フォーム・LPは除外から。

失敗4：一気に変更して原因不明

回避策
施策は1つずつ。Before/After保存。これだけで原因不明が消えます。

まとめ（捨てるほど速くなる／次のアクション提示）

SWELL最適化は、才能ではなく手順です。

• まず重複を捨てる（停止→確認→削除）
• 次にSWELLの高速化設定を弱い順で入れる
• 最後に数字で検証する

これで、サイトは軽くなります。運用も強くなります。

最終チェックリスト（この順でやればOK）

• バックアップ（ファイル＋DB）を作った
• プラグインをA/B/C/Dに分類した
• D→Cの順で「停止→表示確認」を回した
• 問題ないものを削除した
• SWELL設定＞高速化：キャッシュをONにした
• SWELL設定＞高速化：後読み込みをフッター・記事下から入れた
• SWELL設定＞高速化：スクリプト遅延はSNSから段階導入した
• カスタマイザー：ページ遷移高速化は慎重に試した（遷移だけ速い）
• PSIでBefore/Afterを保存した（lab/fieldの違いを理解）
• Search ConsoleのCWVで実ユーザーの改善も追う準備ができた