プロとしてお金をもらうレベルの「本質の高速化」
「〇〇さん、先月リニューアルしてもらったサイトなんですけどね、お客さんから『遅くてイライラする』ってクレームが入ってるんですよ。これ、なんとかなりませんかね」
月曜日の朝一番、電話口から聞こえるクライアントの不機嫌な声。
胃がキリキリと痛むこの感覚、エンジニアなら一度は経験があるはずです。
慌ててPageSpeed Insightsで計測してみると、モバイルのスコアは無慈悲な「32点」。真っ赤な数値が、僕の未熟さをあざ笑うかのように表示されている。
「いや、PCで見れば速いんですけどね」なんて言い訳は通用しません。今の時代、スマホで遅いサイトは、存在しないのと同じ扱いを受けるからです。
僕自身、駆け出しの頃はこの「高速化」という壁に何度もぶち当たりました。
キャッシュ系プラグインを適当に入れて画面を真っ白にしたり、画像を圧縮しすぎて画質がガビガビになったり。
「高速化なんて、プラグインをいくつか入れれば終わるでしょ」と高を括っていた過去の自分を殴りたくなります。
Webサイトの表示速度は、もはや「使いやすさ」だけの問題ではありません。
GoogleはCore Web Vitalsという指標を検索順位の決定要因に組み込みましたし、Amazonの調査では「表示が0.1秒遅れるごとに売り上げが1パーセント下がる」というデータも出ています。
つまり、サイトが重いということは、クライアントの財布に穴を空けているのと同じことなんです。
今回は、数々の炎上案件を鎮火し、泥臭いチューニングを繰り返してきた僕が、現場で実践している「WordPress高速化の生存戦略」をすべて公開します。
巷に溢れる「おすすめプラグイン10選」みたいな表面的な話ではありません。
サーバーの選定から、画像の取り扱い、危険なキャッシュプラグインの制御、そしてクライアントへの報告の仕方まで。
プロとしてお金をもらうレベルの「本質の高速化」について、じっくり語らせてください。
これを読み終える頃には、あなたは真っ赤なスコアを見ても動じることなく、「あ、ここはこう直せば速くなるな」と冷静にメスを入れられるようになっているはずです。
高速化の前に知っておくべき「遅延の犯人」たち
具体的な作業に入る前に、まずは敵を知ることから始めましょう。
なぜWordPressは重くなるのか。
「WordPressは重い」というのが定説になっていますが、実はWordPress自体が重いわけではありません。
犯人は大抵、以下の3つのどれか、あるいは全部です。
1. サーバーという土台の問題
例えるなら、軽自動車のエンジンでダンプカーを走らせようとしている状態です。
月額数百円の格安レンタルサーバーに、アクセス数の多いメディアサイトや、高機能なプラグイン満載のコーポレートサイトを載せていませんか。
PHPの処理速度、メモリの上限、ディスクI/Oの速度。これら土台のスペックが低ければ、どんなにコードを最適化しても限界があります。
「高速化してくれ」と頼まれた案件で、サーバーを確認したら化石のようなプランだった時の絶望感といったらありません。
2. 画像という脂肪
最近のスマホカメラは高性能です。撮影した写真は平気で5MBとかあります。
それをそのまま「アップロード」して記事に貼り付けているクライアント、山ほどいます。
5MBの画像をスマホの4G回線で読み込もうとしたら、そりゃあ数秒かかりますよ。
適切なサイズにリサイズし、圧縮し、次世代フォーマットに変換する。この「ダイエット」をサボっているサイトが多すぎます。
3. JavaScriptという重り
SNSの埋め込み、広告タグ、アクセス解析、チャットボット、動くアニメーション。
「あれもこれも」と機能を追加するたびに、JavaScriptファイルが増えていきます。
ブラウザはこれらのスクリプトを読み込み、実行するまで、画面の描画を待たされます。これを「レンダリングブロック」と呼びます。
便利機能を追加しているつもりが、ユーザーの足を引っ張っている。皮肉な話ですが、これが現実です。
計測なくして改善なし｜正しい診断方法
「なんか遅い気がする」という感覚で作業してはいけません。エンジニアなら数値で語りましょう。
使うツールは定番の「PageSpeed Insights」ですが、スコア（0から100点）だけに囚われると本質を見誤ります。
見るべきは以下の3つの指標です。
- LCP (Largest Contentful Paint): メインのコンテンツが表示されるまでの時間。2.5秒以内が合格ライン。
- FID (First Input Delay) / INP: ユーザーがボタンを押すなどの操作をしてから反応するまでの時間。
- CLS (Cumulative Layout Shift): 読み込み中にレイアウトがガクッとずれる量。
特にLCPが悪ければ、ユーザーは「まだかな」と感じて離脱します。CLSが悪ければ、誤クリックを誘発してイライラさせます。
スコアが90点でも、LCPが4秒かかっていたらダメなんです。
逆に、スコアが50点でも、体感速度が速ければOKな場合もあります（クライアントへの説明が難しいところですが）。
また、ブラウザの「シークレットモード」で実際のサイトを開き、Chromeのデベロッパーツール（Networkタブ）で読み込み状況を確認するのも必須です。
どのファイルがボトルネックになっているのか、ウォーターフォールチャートを見て特定する。
これがプロの診断です。
ステップ1：サーバー環境を見直す（引越しという荒療治）
ここからは具体的な改善手順に入ります。
まず最初に疑うべきはサーバーです。
もしあなたが使っているのが、何年も前に契約した旧式のサーバーや、格安サーバーなら、悪いことは言いません。「サーバー移転」を検討してください。
PHPのバージョンを上げる
移転が難しい場合でも、今すぐできることがあります。PHPのバージョン確認です。
PHP5系や7.0系を使っていませんか。
現在はPHP8系が主流です。PHPのバージョンを上げるだけで、処理速度が2倍以上になることも珍しくありません。
サーバーの管理画面からポチッと切り替えるだけ。これだけで劇的に速くなるなら、やらない手はありません。
ただし、古いテーマやプラグインを使っているとエラーが出る可能性があるので、必ずバックアップを取ってから行いましょう。
HTTP/2 (HTTP/3) に対応しているか
通信プロトコルの確認も重要です。
従来のHTTP/1.1では、ファイルの同時読み込み数に制限がありましたが、HTTP/2以降では一度に大量のファイルを並列で読み込めます。
画像やCSSがたくさんあるサイトでは、これだけで表示速度が体感できるレベルで変わります。
最近の主要なレンタルサーバー（ConoHa WING、Xserverなど）は標準対応していますが、古いサーバーだと未対応の場合があります。
僕の実体験ですが、チューニングをどれだけ頑張ってもスコアが上がらなかったサイトを、高性能なサーバーに移転させただけで、何も設定を変えていないのにスコアが30点アップしたことがあります。
「ハードウェアの力は偉大だ」と痛感した瞬間でした。
クライアントに「サーバーを変えましょう」と提案するのは勇気がいりますが、「月額数百円の差で、機会損失を防げますよ」と数字で説明すれば、案外納得してくれるものです。
ステップ2：画像の徹底的なダイエット
サーバーが整ったら、次はコンテンツの贅肉を落とします。
一番効果が出やすいのが画像です。
EWWW Image Optimizerの導入
WordPressを使っているなら、このプラグインは必須装備です。
画像をアップロードした瞬間に自動で圧縮してくれます。
さらに重要なのが、「WebP（ウェッピー）」への変換機能です。
WebPはGoogleが開発した次世代画像フォーマットで、JPEGやPNGと同等の画質を保ちながら、ファイルサイズを2割から3割ほど小さくできます。
プラグインの設定で「WebP変換」をオンにするだけで、対応ブラウザにはWebPを、非対応ブラウザには元の画像を表示し分けてくれます。
TinyPNGでの事前圧縮
プラグインに頼り切るのも良くありません。サーバーの負荷になるからです。
僕は記事を書く際、画像をアップロードする前に必ず「TinyPNG」などの圧縮ツールを通すようにしています。
Photoshopで書き出した画像でも、ここを通すと驚くほど軽くなります。
「画像は幅1200px以下、容量は200KB以下にしてからアップする」
こういう運用ルールをクライアントやライターチームと共有することも、エンジニアの大事な仕事です。
遅延読み込み（Lazy Load）の落とし穴
画面外にある画像を、スクロールして表示領域に入ったタイミングで読み込む技術です。
WordPress 5.5以降は標準機能になりましたが、ここで注意点があります。
「ファーストビュー（最初に見える範囲）の画像は遅延読み込みさせてはいけない」ということです。
メインビジュアルやロゴまで遅延読み込みさせてしまうと、LCP（最大コンテンツの描画時間）が悪化します。
「EWWW Image Optimizer」や「SWELL」などのテーマ設定で、ファーストビューの画像を除外する設定を忘れないでください。これ、結構やらかしているサイトが多いです。
ステップ3：キャッシュプラグインという諸刃の剣
高速化といえばキャッシュ。
「WP Super Cache」や「W3 Total Cache」といったプラグインが有名ですね。
これらは、動的に生成されるWordPressのページを、静的なHTMLとして保存し、2回目以降のアクセスを爆速にする魔法のツールです。
しかし、声を大にして言いたい。
「キャッシュプラグインは、素人が安易に手を出してはいけない」
画面が真っ白になる恐怖
僕も過去にやらかしました。
設定を適当にオンにしたら、サイトのデザインが崩れ、ログイン画面にすら入れなくなり、FTPソフトを使ってプラグインを強制削除する羽目になりました。冷や汗でTシャツがびしょ濡れになりました。
特にECサイトや会員制サイトでキャッシュを効かせすぎると、Aさんの買い物かごの中身がBさんに表示される、なんていう個人情報漏洩事故にも繋がりかねません。
安全なキャッシュ戦略
最近のレンタルサーバーは、サーバー側で強力なキャッシュ機能を持っています。
まずはそちらを使いましょう。プラグインを入れるのは最終手段です。
もし入れるなら、「WP Fastest Cache」のような設定がシンプルでリスクの少ないものを選ぶか、使用しているテーマ（SWELLなど）が推奨しているキャッシュ設定に従うのが無難です。
「なんでもかんでもキャッシュすればいい」というのは間違いです。
更新頻度の高いページや、動的な要素があるページはキャッシュ除外設定をする。この細やかなチューニングこそがエンジニアの腕の見せ所です。
ステップ4：不要なコードとプラグインの断捨離
サイトを長く運営していると、ゴミが溜まってきます。
使っていないプラグイン、誰も見ていないウィジェット、無効化されたままのテーマ。
これらはセキュリティリスクになるだけでなく、サイトを重くする原因にもなります。
「Autoptimize」でコードを圧縮
HTML、CSS、JavaScriptのコードから、改行や空白を削除してファイルサイズを小さくする（Minify）。
そして、バラバラに存在する複数のCSS/JSファイルを1つにまとめる。
これをやってくれるのが「Autoptimize」です。
HTTP/2環境下ではファイルをまとめるメリットは薄れていますが、コードの圧縮は依然として有効です。
ただし、これもキャッシュプラグイン同様、設定によってはデザイン崩れを引き起こします。
「JavaScriptの最適化」をオンにしたらスライダーが動かなくなった、なんてことは日常茶飯事です。
一つずつチェックボックスをオンにして、動作確認をする。地道な作業ですが、これをサボると痛い目を見ます。
プラグインの整理整頓
「便利そうだから」と入れたプラグイン、本当に必要ですか。
機能が重複しているものはありませんか。
例えば、SEOプラグインを入れているのに、XMLサイトマップ生成プラグインも入れている、とか。
Googleアナリティクスのタグを入れるためだけに、重たいプラグインを入れていませんか。（テーマの機能や直接記述で十分です）
プラグインは減らせば減らすほど、サイトは速くなり、安全になります。
僕は「20個以内」を目安にしています。それ以上あるなら、何かがおかしいと疑ってください。
ステップ5：外部スクリプトの遅延読み込み
これが意外と盲点です。
Googleアドセンス、Twitterのタイムライン埋め込み、YouTube動画。
これらの外部サービスから読み込むスクリプトは、自分たちのサーバーの外にあるので、コントロールが難しく、非常に重いです。
Flying Scripts の活用
そこで役立つのが「Flying Scripts」などのプラグインです。
これは、指定したJavaScriptの読み込みを、「ユーザーがマウスを動かすまで」とか「数秒経ってから」といった具合に、遅らせることができます。
ファーストビューの描画を最優先し、重たい外部スクリプトは後回しにするのです。
これだけで、PageSpeed Insightsのスコアが20点くらい跳ね上がることがあります。
ただし、これもやりすぎると「広告が表示されない」「計測データが取れない」といった問題が起きるので、クライアントと相談しながら、どのスクリプトを遅延させるか決める必要があります。
クライアントへの報告と「体感速度」の話
ここまでやっても、スコアが90点に届かないことはあります。
特にモバイルのスコアは厳しく、リッチなデザインのサイトでは50点から60点が限界ということもザラです。
そんな時、どうやってクライアントに納得してもらうか。
スコアはあくまで目安
「社長、スコアは60点ですが、実際の表示を見てください。タップしたらすぐに画面が出ますよね」
と、実機での体感速度（UX）を見せます。
PageSpeed Insightsは、劣悪な通信環境や低スペックな端末を想定して厳しめに採点しています。
実際のターゲットユーザーが快適に使えているなら、無理に100点を目指す必要はありません。
100点を目指すために、デザインを削ぎ落とし、機能を削除して、真っ白なテキストサイトにするのは本末転倒ですから。
「Googleのスコアを上げること」が目的ではなく、「ユーザーに快適に買い物をしてもらうこと」が目的です。
この視点をずらさずに説明すれば、クライアントも納得してくれます。
「これ以上速くするには、デザインをシンプルにするか、開発費をかけてサーバーをAWSなどに移行する必要がありますが、どうしますか」と、コストと効果のバランスを提示するのもプロの仕事です。
よくあるトラブルと解決策（FAQ）
現場でよく遭遇するトラブルをまとめておきます。
Q. 高速化したら「お問い合わせフォーム」が動かなくなりました。
A. JavaScriptの圧縮や遅延読み込みが原因の可能性が高いです。reCAPTCHAなどのスクリプトが動いていないのかもしれません。お問い合わせページだけ高速化設定を除外するか、該当のスクリプトを除外リストに入れてください。
Q. デザインが崩れて元に戻りません。
A. ブラウザのキャッシュ、プラグインのキャッシュ、サーバーのキャッシュ、CDNのキャッシュ。これらが悪さをしていることが多いです。全てのキャッシュをクリアし、スーパーリロード（Ctrl + F5）を試してください。それでもダメなら、AutoptimizeなどのCSS最適化をオフにしてください。
Q. モバイルだけ遅いんですが。
A. 画像サイズがPC用のまま読み込まれているか、モバイル回線でのJavaScript実行に時間がかかっている可能性があります。画像のレスポンシブ対応（srcset属性）の確認と、不要なアニメーションの削除を検討してください。
Q. データベースの掃除って必要ですか。
A. 長年運用しているサイトなら効果があります。「WP-Optimize」などのプラグインで、リビジョン（記事の編集履歴）やスパムコメントを削除すると、DBのクエリ実行速度が上がり、管理画面がサクサクになります。ただし、必ずバックアップを取ってから行ってください。
高速化は「愛」である
長々と技術的な話をしてきましたが、僕が思うに、Webサイトの高速化とは「ユーザーへの愛」です。
「忙しい朝の電車の中で見ているかもしれない」
「通信制限がかかってイライラしているかもしれない」
「古いスマホを大切に使っているかもしれない」
画面の向こうにいる、そんな一人ひとりのユーザーを想像できるかどうか。
1秒でも早く情報を届けたい、ストレスなく楽しんでほしい。
その「思いやり」が、画像の1KBを削り、コードの1行を修正する原動力になります。
クライアントから「速くなったね、ありがとう」と言われるのも嬉しいですが、それ以上に、アナリティクスの滞在時間が伸びたり、コンバージョン率が上がったりして、数字として結果が出た時の達成感は格別です。
それは、あなたの技術が、誰かの役に立ったという確かな証明だからです。
高速化に終わりはありません。ブラウザの仕様も、通信環境も、Webのトレンドも日々変わっていきます。
でも、基本となる「土台（サーバー）」「素材（画像）」「無駄の排除」という考え方は変わりません。
この3つを徹底するだけで、あなたの作るサイトは劇的に変わります。
今、あなたの手元にあるその重たいサイト。
それは、ただのバグの塊ではなく、磨けば光る原石です。
さあ、検証ツールを開いて、ボトルネックを探しに行きましょう。
赤いスコアを緑色に変える快感を、ぜひ味わってください。
あなたの書いたコードが、世界中の誰かにストレスなく情報を届ける。
その快適なインターネットの一部を、あなたが支えているんです。
そう考えると、ちょっとワクワクしてきませんか。
