WordPress高速化 完全ガイド 体感が変わる現場の手順と地雷回避

WordPressの表示が遅い。地味にストレスです。

記事を開くたびにローディング。画像が出るまで真っ白。スクロールするとガクガク。読者は待ってくれません。あなたが頑張って書いた渾身の記事も、読み込まれる前に閉じられる。悲しいが現実。

速度は気合では上がりません。設計と手順で上がります。

この記事では、WordPressのサイトやブログを高速化するための考え方と、実務で効く手の打ち方をまとめます。プラグインの押し引き、テーマの癖、画像とフォント、キャッシュ、DB、サーバー。全部触れます。偏見も入れます。だって現場は理想論だけじゃ回らない。

なぜ放置をやめる必要があるのか: 遅いサイトが損するポイント

速度が遅いと、読者が離れます。これは分かりやすい。

でも痛いのはそこだけじゃない。遅いとGoogleの評価が下がる可能性があるし、広告の収益も落ちやすい。CVボタンが押される前に離脱される。検索順位以前に、読まれない。読まれないと改善点も見えない。負のループである。

それに、遅いサイトは運用コストも上がります。軽微な修正のたびに表示確認が遅い。管理画面も重い。地味に疲れる。疲れると雑になる。雑になるとプラグインを増やす。増やすと遅くなる。はい、またループ。

あなたのサイト、記事は読まれているのに途中で消えていませんか。スクロールが止まる瞬間、ありませんか。

高速化の全体像: どこが遅いかで対処が変わる

WordPressの遅さには種類があります。これがポイント。

トップは遅いけど記事は速い。記事は速いけど管理画面が重い。最初だけ遅いが2回目は速い。スマホだけ遅い。こういう差が出る。原因が違うからです。

遅さの主な原因をざっくり分類

• サーバーが弱い、設定が甘い
• テーマが重い、作りが粗い
• プラグインが多い、相性が悪い
• 画像が重い、表示方法が雑
• CSSやJSが多い、読み込み順が悪い
• フォントが重い、読み込みでガタつく
• DBが肥大化、クエリが無駄
• 外部サービスが遅い(広告、計測、埋め込み)

全部を一度に直そうとすると失敗します。まずは一番太いボトルネックを潰す。これが王道。スマートに見えて実は泥臭い。

測り方: いきなり改善より先に現状把握

速度改善は、数字の遊びではありません。体感の改善です。

ただし体感だけだと迷子になる。なので計測はします。ここは割り切り。

チェックする指標のイメージ

• LCP: 目立つコンテンツが表示されるまで
• CLS: レイアウトのガタつき
• INP: 触ったときの反応速度
• TTFB: サーバーが返すまでの待ち

このうち、WordPressで一番ぶれやすいのがTTFBとLCP。サーバーとキャッシュ、画像が絡むからです。CLSはテーマとフォントと広告で事故りやすい。INPは重いJSやスライダーで悪化しやすい。傾向を覚えるだけで、打ち手の選び方が変わります。

現場の測り方のコツ

• シークレットウィンドウで見る(キャッシュの影響を減らす)
• スマホ回線を想定してネットワークを絞る
• トップ、記事、カテゴリ、固定ページを最低1つずつ見る
• 遅いページを特定して優先順位を付ける

計測して「遅い」と分かった。そこからが本番です。

やり方1: キャッシュで殴る まずは体感を変える

WordPress高速化で一番効きやすいのはキャッシュです。派手さはない。だが強い。

仕組みとしては単純で、毎回PHPでページを生成するのをやめて、出来上がったHTMLを配信する。これでTTFBが改善しやすい。特にアクセスが増えたブログほど効きます。

キャッシュの種類

• ページキャッシュ: HTMLを保存して配る
• ブラウザキャッシュ: CSSや画像を端末に保存
• オブジェクトキャッシュ: DB結果などを保存
• CDNキャッシュ: 世界中の拠点に置いて近い所から配る

メリット

• 体感が一気に変わりやすい
• サーバー負荷が下がる
• アクセス増加にも耐えやすい

デメリット

• 更新が反映されない事故が起きる
• ログイン状態や会員サイトは設計が必要
• 設定が二重三重だと逆に複雑になる

キャッシュは万能ではないが、最初に打つ価値があります。特に静的に近いコーポレートサイトやブログは効きやすい。逆にECや会員機能が強いサイトは、除外設定が肝になります。

やり方2: 画像のダイエット ここを怠ると一生遅い

画像が重い。これ、WordPressあるあるです。

そして画像を軽くするだけでLCPが改善しやすい。見た目が同じでも速度は変わる。ここが面白い所。

画像でやることリスト

• 適切なサイズで出す(巨大画像を縮小表示しない)
• WebPやAVIFを使う
• サムネイル生成とsrcsetを活かす
• 遅延読み込みを使う(ただしFVは別)
• 圧縮し過ぎて汚くしない

よくある事故が、幅2000pxの画像をそのまま貼って、CSSでwidth: 100%にして終わり。見た目は正しい。中身が重い。スマホが泣く。読者も泣く。

ファーストビューの画像だけは扱いが違う

FVの画像を遅延読み込みにすると、最初が真っ白になりやすい。体感が悪い。なのでFVの画像は優先して読み込み、下の画像は遅延。これが基本形です。

メリット

• LCPが改善しやすい
• 転送量が減って通信が軽くなる
• サーバーの負荷も下がりやすい

デメリット

• 画像の運用ルールが必要になる
• 変換や配信の仕組みが増えると管理が面倒

画像は運用の問題でもあります。編集者が増えるほど事故る。だから最初にルールを作る。ここで差が出るのです。

やり方3: CSSとJSの整理 そのスライダー、本当に必要?

スライダーはロマンです。だが速度の敵になりやすい。

WordPressはテーマやプラグインが勝手にCSSやJSを読み込みがちです。必要なページだけにしたいのに、全ページで読み込まれる。しかもminifyされていない。しかも読み込み順が悪い。事故の香り。

フロントエンド側で効く改善

• 使っていないCSSやJSを削る
• ページ単位で読み込みを分ける
• deferやasyncを使い分ける
• 重いライブラリを軽い代替にする
• アニメーションを控えめにする

ここで質問です。トップのファーストビューで、JSが読み終わるまでボタンが反応しない状態になっていませんか。ユーザーは押す。反応しない。もう一回押す。イラッとする。離脱。こういう流れ、割と普通に起きます。

メリット

• INPが改善しやすい
• 体感が軽くなる
• バグが減ることがある(意外と大きい)

デメリット

• テーマやプラグインの仕様理解が必要
• 依存関係を壊すと表示崩れが起きる

削ると壊れる。壊れると怖い。分かります。なので手順は慎重に。

安全な進め方

• まず計測して重いファイルを特定
• 消して良いものを小さく1つ消す
• 影響範囲を確認してから次へ

やり方4: フォント最適化 文字のガタつきは地味に致命傷

Webフォント、格好いい。だが重い。

フォント読み込みが遅いと、文字が一瞬消える、あるいは後から切り替わってレイアウトが動く。これがCLS悪化の定番です。読みやすさにも直撃します。

フォントで効く打ち手

• フォントは必要最小限の種類にする
• 太字を増やし過ぎない
• font-displayの挙動を調整する
• サブセット化を検討する
• 日本語フォントは特に慎重に

メリット

• CLSが改善しやすい
• 体感が安定する
• 読みやすさが上がることが多い

デメリット

• デザインのこだわりと衝突しやすい
• 設定を間違えると見た目が変わる

フォントは速度とデザインの綱引きです。僕は速度寄りの性格。読めない格好良さより、読める快適さが好きだ。

やり方5: プラグイン整理 便利のツケを払う時間

WordPressはプラグインで何でも出来ます。出来る。出来てしまう。

そして気付くとプラグインが30個。管理画面が重い。フロントも重い。更新通知が怖い。恐怖のゲーム開始。

プラグインが遅くする典型例

• 全ページに計測タグやJSを注入
• 管理画面で重いクエリを走らせる
• ショートコードが多重に呼ばれる
• 外部APIを毎回叩く

メリット

• 根本的な軽量化につながる
• セキュリティ面も整理しやすい
• 運用が楽になる

デメリット

• 代替実装が必要になる場合がある
• 担当者の心理的負担が大きい

プラグイン整理は、やる前が一番しんどい。やった後は楽。筋トレに似ています。

整理のコツ

• 目的が被っているプラグインを統合する
• 使っていない機能はオフにする
• 更新が止まっているものは見直す
• 計測系、装飾系、埋め込み系は特に疑う

やり方6: DBと記事運用の掃除 テーブルは黙って増える

WordPressはDBが太りやすい。静かに太ります。

リビジョンが積み上がる。削除した投稿のゴミが残る。オプションテーブルが膨れる。プラグインを入れて消しても跡が残ることがある。知らぬ間に遅くなる。ホラーです。

DB側で起きやすい問題

• リビジョン過多
• autoloadが肥大化
• 不要テーブルや不要レコード
• 検索が重い(全文検索の負荷)

メリット

• 管理画面が軽くなることがある
• バックアップが速くなる
• 長期運用の安定性が上がる

デメリット

• 操作を誤ると復旧が大変
• 作業前のバックアップが必須

DBの掃除は慎重に。バックアップはケチらない。ここは僕のこだわりです。痛い目を見た人ほど頷くやつ。

やり方7: サーバーとPHP ここをケチると限界が早い

高速化で一番分かりやすい裏技。サーバーを強くする。これです。

身も蓋もない。でも現場では効く。テーマをいくら最適化しても、サーバーが弱いとTTFBが伸びます。キャッシュが無い状態の初回表示が遅い。管理画面も重い。更新が怖くなる。悪循環。

サーバー側で効きやすい要素

• PHPのバージョンと設定
• HTTP/2やHTTP/3の対応
• OPcacheの有無
• 高速なストレージ
• 適切なメモリ

メリット

• TTFBが改善しやすい
• アクセス増加に強くなる
• 管理画面の快適さが上がる

デメリット

• 月額コストが上がることがある
• 移転や設定変更の手間が発生する

速度とコストはトレードオフになりやすい。だが、時間もコストです。エンジニアの時給は高い。僕はそこをいつも計算します。

やり方8: CDNと画像配信 速さは距離にも左右される

アクセスが全国、世界に散っているならCDNが効きます。

CDNは、ユーザーに近い場所から静的ファイルを配る仕組み。CSS、JS、画像。これらが速くなると体感が変わりやすい。特に画像の比率が高いブログは効くことが多いです。

メリット

• 画像や静的ファイルの配信が速くなりやすい
• サーバー負荷を減らせる
• アクセス集中に強くなる

デメリット

• キャッシュの更新に癖がある
• 設定を誤ると反映遅延が起きる
• 費用が発生する場合がある

CDNは魔法ではない。だが上手く使うと、まるで別サイトのように軽くなることがあります。気持ちいいやつ。

やり方9: 外部埋め込みと計測タグ ここが一番の裏ボス

WordPress本体や画像を頑張って軽くした。なのに遅い。こういう時に疑うのが外部要素です。

YouTube埋め込み、SNS埋め込み、広告タグ、ヒートマップ、チャットウィジェット。これらは便利です。だが読み込みが遅いと、こちらの努力を平気で打ち消す。しかも日によって速度が変わる。厄介。

対処の考え方

• 本当に必要なものだけ残す
• 表示位置を下げる(ファーストビューから外す)
• クリックで読み込む方式にする
• 計測タグは整理して最小化する

メリット

• 体感が急に軽くなることがある
• CLSやINPが改善しやすい

デメリット

• マーケ施策との調整が必要
• 数字が取れなくなる不安と戦う時間が出る

数字を取りたい。分かる。けれどサイトが読まれないなら数字以前です。ここ、現場の葛藤ポイント。

高速化の進め方: 失敗しにくい優先順位

やることが多いと、動けなくなります。なので順番を作ります。

優先順位1: キャッシュと画像

ここで体感が変わりやすい。まず勝ちを作る。テンションが上がる。次に進める。

優先順位2: CSS/JSと外部タグ

次にINPやCLSを潰す。ユーザーの苛立ちを減らす。地味に効きます。

優先順位3: プラグイン整理とDB

長期運用の安定化。ここは後回しにされがちだが、積み上がると痛い。

優先順位4: サーバーとCDN

最後に基盤を固める。ここで上限が上がります。伸びしろが残っているなら投資しがいがあります。

実務あるある地雷集: やりがちな失敗と回避

地雷1: 高速化プラグインを複数入れる

キャッシュ系、最適化系を重ねると設定が衝突しやすい。どれが効いているかも分からなくなる。まずは一つ。必要なら慎重に足す。

地雷2: まとめてminifyして崩れる

CSSやJSの結合や圧縮は、壊れる時は派手に壊れます。いきなり本番でやらない。検証環境でやる。小さく試す。

地雷3: 遅延読み込みを何でもかんでも適用

FVの画像や、最初に必要なCSSまで遅延させると、体感が悪くなる。遅延は万能ではない。使いどころがある。

地雷4: 画像を圧縮し過ぎて汚くなる

軽さは正義。だが画質が崩れると別の問題が出る。特に商品画像や人物写真は丁寧に。読者の信頼にも関わります。

メリットまとめ: 速いWordPressが生む良い循環

速くなると、運用が楽になります。これが大きい。

• 読者が離脱しにくくなる
• 回遊が増えやすい
• 広告やCVが改善しやすい
• 管理画面のストレスが減る
• 修正の確認が速くなる

速さは、体験の土台です。豪華なデザインよりも先に効く。僕はそう思っています。

デメリットまとめ: 高速化は万能薬ではない

速度改善には副作用もあります。正直に書きます。

• 設定が増えて運用が複雑になる
• キャッシュ絡みの反映遅延が起きる
• プラグインやテーマ更新で再調整が必要
• 関係者(制作、運用、広告)との調整が増える

ただ、複雑さはコントロールできます。ルールと手順を作る。そこに尽きる。

読者に有益な追加情報: 高速化と一緒に見直すと得する周辺知識

1) 画像運用ルールをドキュメント化

アップロード前の推奨サイズ、推奨形式、圧縮方法。これを決めるだけで事故が減る。編集者が増えるほど効きます。

2) テーマ選定の目利きポイント

• 不要な機能が多すぎないか
• Gutenberg対応が自然か
• 読み込みファイルが少ないか
• 更新が継続しているか

見た目が派手でも軽いテーマはあります。逆もあります。デモは速いのに実運用は遅い。これもある。怖い話。

3) 計測タグを棚卸しする習慣

入れっぱなしのタグ、増えていませんか。マーケ施策が終わっても残っていることが多い。棚卸しは定期的にやると吉。

4) 表示速度とアクセシビリティは相性が良い

軽いページは、操作もしやすくなりがちです。不要なアニメーションを減らす。レイアウトのガタつきを止める。フォーカス移動を素直にする。速度だけの話に見えて、体験全体が整う。そこが好きです。

5) 直近の改善タスクを小さく切る

次に何をしますか。画像のルール作りですか。トップのFVの読み込みですか。計測タグの整理ですか。

大きく抱えると止まります。小さく切る。1つ直す。確認する。次へ。これで回る。地味だが強い。

WordPressの高速化は、派手な必殺技より、地道な積み重ねが効きます。やれば体感は変わる。変わると運用が楽になる。楽になると記事が増える。増えると成果が出る。そういう流れが好きだ。