WordPressサイトが重い。プラグインを入れてみたけれど、体感は変わらない。この状態でよくあるのが、効果の小さい対策から手をつけているケースです。
表示速度の問題は、原因の切り分けさえできれば解決手順は決まっています。この記事では、効果の大きい順に整理します。結論を先に言うと、多くのサイトは画像とプラグインだけで大半が解決します。
この記事の結論
- 画像の最適化(効果:特大/手間:小)— まずここ。これだけで劇的に変わることが多い
- 不要なプラグインの削除(効果:大/手間:小)
- キャッシュの導入(効果:大/手間:中)
- サーバーの見直し(効果:大/手間:大)
- テーマの見直し(効果:中〜大/手間:特大)
上から順に試してください。5から始めると、労力の割に報われません。
まず、どこが遅いのかを特定する
「なんとなく重い」まま対策しても当たりません。最初に測ってください。
PageSpeed Insightsで測る
Googleの無料ツールです。URLを入れるだけで、モバイルとPCそれぞれの評価と、改善すべき項目が具体的に表示されます。ここで指摘された項目に、上から取り組むのが最短ルートです。
注意点として、スコアの数字そのものを目標にしないでください。90点を目指して過剰な設定を入れると、表示が崩れたり機能が壊れたりします。見るべきは「診断結果」の中身です。
ブラウザの開発者ツールで内訳を見る
F12キーで開発者ツールを開き、ネットワークタブでページを再読み込みすると、何にどれだけ時間がかかっているかが一覧できます。ファイルサイズの大きい順に並べ替えれば、犯人はすぐ分かります。たいていは画像です。
サーバーの応答時間か、それ以降かを切り分ける
開発者ツールで最初のHTMLが返ってくるまでの時間(TTFB)を見ます。
- TTFBが遅い(0.6秒以上)…サーバー側かWordPress側の問題。プラグイン、データベース、サーバー性能を疑う
- TTFBは速いのに表示が遅い…画像・CSS・JavaScriptの問題。フロント側の最適化で直る
この切り分けを飛ばすと、サーバーが原因なのに画像を圧縮し続ける、といった無駄が起きます。
1. 画像の最適化(ここだけで大半が解決する)
個人サイトが重い原因は、ほとんどの場合これです。スマホやカメラで撮った写真をそのままアップロードすると、1枚で数MBあります。表示に必要なのは通常1,200px程度なので、10分の1以下にできます。
やること
- アップロード前にリサイズする…横幅1,200〜1,600pxで十分です
- 圧縮する…見た目をほぼ変えずに容量だけ落とせます
- WebP形式にする…同じ画質でJPEGより2〜3割小さくなります
- 遅延読み込み(lazy load)を有効にする…WordPressは標準で対応しています
- 幅と高さを指定する…読み込み中のレイアウト崩れを防げます
画像の圧縮に使えるツール
当サイトの姉妹サイト 圧縮の匠 は、画像をブラウザの中だけで圧縮します。ファイルがサーバーに送信されないため、公開前の素材でも安心して使えます。JPG・PNG・WebP・AVIF に対応し、最大20ファイルまで一括処理できます。
プラグインで自動圧縮する方法もありますが、アップロード前に小さくしておくほうが、サーバーの容量もバックアップの時間も節約できます。
すでにアップロード済みの画像はどうするか
メディアライブラリを容量順に並べ替えて、大きいものだけ差し替えるのが現実的です。全部やろうとすると終わりません。トップページとアクセスの多い記事に使われている画像を優先してください。
2. プラグインを減らす
プラグインは1つ増えるごとに、読み込むCSSとJavaScriptが増えます。しかもそのプラグインを使っていないページでも読み込まれることが多く、これが積み重なって重くなります。
見直しの基準
- 停止したまま放置しているもの…削除してください。セキュリティ上のリスクにもなります
- 機能が重複しているもの…SEO系プラグインが2つ入っているケースは非常に多いです
- 1か所でしか使っていないもの…その機能のために全ページが重くなっていないか
- 1年以上更新されていないもの…速度以前に、脆弱性の観点で危険です
- テーマの機能と重複しているもの…最近のテーマは目次やSNSシェアを内蔵しています
どのプラグインが重いか調べる
一つずつ停止して、そのたびにPageSpeed Insightsで測るのが確実です。地道ですが、推測で消すより確実です。プラグインの負荷を可視化する専用プラグインもありますが、それ自体も負荷になるため、調査が終わったら削除してください。
作業前に必ずバックアップを
プラグインの削除は、設定ごと消える場合があります。作業前に必ずバックアップを取ってください。レンタルサーバーの自動バックアップ機能がある場合は、復元方法も先に確認しておきましょう。「消してから慌てる」がいちばん時間を失います。
3. キャッシュを導入する
WordPressは、アクセスのたびにPHPを実行してデータベースから記事を組み立てています。キャッシュは、この結果を保存しておいて2回目以降はそれを返す仕組みです。効果は大きいですが、設定を誤ると表示崩れが起きます。
キャッシュの種類と効果
| 種類 | 何をするか | 効果 | リスク |
|---|---|---|---|
| ページキャッシュ | 完成したHTMLを保存して再利用 | ★★★ | 更新が反映されないことがある |
| ブラウザキャッシュ | 訪問者の端末に画像やCSSを保存 | ★★☆ | 低い |
| オブジェクトキャッシュ | データベースの問い合わせ結果を保存 | ★★☆ | サーバーの対応が必要 |
| CSS/JSの圧縮・結合 | ファイルサイズと数を減らす | ★☆☆ | 表示崩れが起きやすい |
まずはページキャッシュとブラウザキャッシュだけを有効にしてください。CSS/JSの圧縮・結合は効果の割にトラブルが多いので、他をやり尽くしてから検討する程度で十分です。
サーバー側のキャッシュを先に確認する
主要な国内レンタルサーバーは、管理画面から有効にできる高速化機能を備えています。プラグインを入れる前に、まずサーバー側の機能を確認してください。サーバー側とプラグインの両方でキャッシュをかけると、干渉して不具合が起きることがあります。どちらか一方に寄せるのが基本です。
キャッシュ導入後の必須確認
- 記事を更新したら、実際に反映されるか
- お問い合わせフォームが正常に送信できるか
- ログイン中の表示がおかしくなっていないか
- スマホで表示崩れがないか
特にフォームの動作確認は必須です。キャッシュが原因で送信できなくなっているのに、気づかず何か月も放置されているサイトは珍しくありません。
4. サーバーを見直す
ここまでやってもTTFBが遅いままなら、サーバー側が原因です。判断材料は次のとおりです。
- PHPのバージョンが古い…管理画面から最新版に上げるだけで速くなることがあります。ただし互換性の確認は必要です
- 共用サーバーで、同居サイトの影響を受けている…時間帯によって速度が変わるならこれを疑います
- 格安プランの性能上限に当たっている…同時アクセスに弱いプランがあります
- データベースが肥大化している…リビジョンやスパムコメントが溜まっていないか
サーバー移転は効果が大きい一方、手間もリスクもあります。1〜3を終えてから判断してください。移転前に、移転先の試用期間で実際の速度を測るのが確実です。
5. テーマの見直し(最終手段)
多機能なテーマは、使っていない機能のCSSとJavaScriptまで読み込むことがあります。ただしテーマの変更は影響範囲が最も大きく、レイアウトが全面的に崩れます。
現実的なのは、テーマを変えるのではなくテーマの設定で不要な機能をオフにすることです。それでも解決しない場合に限り、変更を検討してください。
やりがちだが、効果が薄い対策
- 高速化プラグインを複数入れる…干渉して不具合の原因になります。1つに絞ってください
- PageSpeedのスコアだけを追う…体感速度と一致しません。数字より実際の表示を見てください
- 画像を放置してキャッシュだけ入れる…画像が重いままなら、キャッシュしても重いままです
- いきなりサーバーを乗り換える…原因が画像だった場合、移転しても変わりません
ここまで試しても改善せず、サーバーの性能そのものが原因だと判断した場合は、レンタルサーバー診断ツールで条件に合う移行先を絞り込めます。ただし移行は最後の手段です。先に上の手順で原因を特定してください。
よくある質問
表示速度は検索順位にどれくらい影響しますか?
直接の影響は、多くの人が思うほど大きくありません。ただし遅いページは読まれる前に閉じられます。順位への影響より、離脱率への影響のほうが実害が大きいと考えてください。
モバイルのスコアだけ極端に低いのですが
正常です。PageSpeed Insightsのモバイル測定は、意図的に低速な回線と非力な端末を想定しています。PCとの差を気にするより、モバイルの診断項目を1つずつ潰すほうが建設的です。
どこまでやれば十分ですか?
スマホの4G回線で、3秒以内に主要な内容が表示されるなら十分実用的です。それ以上の追求は、費用対効果が急速に落ちます。
プラグインや画像を整理しても改善しない場合、サーバー側の性能が上限になっていることがあります。乗り換えを検討するならレンタルサーバーの選び方とmixhostクラウドサーバーの評判・料金が参考になります。
まとめ
- まず測る(PageSpeed Insights + 開発者ツール)
- TTFBでサーバー側かフロント側かを切り分ける
- 画像を最適化する(ここで大半が解決)
- 不要なプラグインを消す
- キャッシュを導入する(フォームの動作確認を忘れずに)
- それでも遅ければサーバーを見直す
高速化は、順番を守れば難しくありません。逆に順番を間違えると、労力ばかりかかって体感が変わらない、という結果になります。
改善したかを数値で確かめる
施策を打つ前と後で、同じ条件で測らないと効果は分かりません。体感は当てになりません。
| 指標 | 意味 | 目安 |
|---|---|---|
| LCP | 主要な内容が表示されるまで | 2.5秒以下 |
| INP | 操作に対する反応の速さ | 200ミリ秒以下 |
| CLS | 表示中のレイアウトのずれ | 0.1以下 |
| TTFB | サーバーの応答開始まで | 0.8秒以下 |
| 総ページサイズ | 読み込む容量の合計 | 1MB以下が理想 |
測るときの注意
- モバイルとデスクトップを分けて見る — 評価基準が違う
- 同じページで比較する — トップと記事ページでは構成が違う
- 時間帯を揃える — サーバーの混雑で変わる
- 3回測って中央値を取る — 単発の値はぶれる
- キャッシュの有無を揃える — 初回と2回目で大きく違う
点数そのものより、施策の前後でどれだけ変わったかを見てください。点数を上げること自体が目的になると、体感の速さに繋がらない調整に時間を使うことになります。
表示速度は順位を決める要因の1つですが、それだけで順位が決まるわけではありません。内容が同等の場合の差として効く、という位置づけです。速度改善に時間を使いすぎて、記事の中身が薄いままでは意味がありません。
この記事で使える無料ツール
- Base64エンコード・デコード — 小さなアイコンをdata URIに変換する
- 色のコントラスト比チェッカー — 配色のコントラストを確認する
