速さと更新しやすさは、両立できる
WordPressの高速化というと、真っ先に思い浮かぶのが「プラグインを減らす」「機能を削る」といった引き算です。しかし現場で本当に困るのは、速くなった代わりに担当者が自分でページを更新できなくなってしまうケースです。CMSを入れた意味がなくなり、結局すべての更新が制作側への依頼に逆戻りしてしまいます。当スタジオでは、更新のしやすさを損なわない範囲でどこまで速くできるかを設計の出発点にしています。順序としては、キャッシュ・画像・CSS/JS・プラグインの4つを、この並びで整理していきます。
キャッシュを「層」で整理する
WordPressは、アクセスのたびにPHPがデータベースを参照してHTMLを組み立てます。この処理を毎回やらせないことが高速化の中心です。キャッシュにはいくつかの層があり、それぞれ役割が違います。
- ページキャッシュ … 生成済みのHTMLを再利用し、PHPとDBの処理そのものを省く
- オブジェクトキャッシュ … DBへの問い合わせ結果を再利用する
- ブラウザキャッシュ … 画像やCSSを訪問者の端末に保持させる
- CDN … 静的ファイルを訪問者に近いサーバーから配信する
重要なのは、更新した内容がいつ反映されるかを決めておくことです。投稿を更新したら該当ページのキャッシュを自動で破棄する設定にしておかないと、担当者が「更新したのに変わらない」と混乱します。キャッシュ設計は、速度の話であると同時に運用の話でもあります。
画像は「入り口」で自動最適化する
運用が始まると、記事や実績の画像は担当者が管理画面からアップロードします。ここでカメラの元データがそのまま入ってしまうと、せっかく整えた表示速度は少しずつ崩れていきます。対策は、担当者に圧縮作業をお願いすることではなく、アップロードした時点で自動的に最適化される仕組みを用意しておくことです。
- アップロード時にWebPを自動生成し、対応ブラウザへ配信する
- 用途に合ったサイズを自動生成し、原寸を直接表示しない
- テンプレート側でwidth / height属性とloading="lazy"を必ず出力する
- ファーストビューの主役画像だけはlazyを外し、優先的に読み込ませる
「担当者が何も意識しなくても崩れない」状態まで作り込んでおくと、公開から一年経っても速度が保たれます。
CSS・JSは、必要なページにだけ届ける
WordPressのテーマやプラグインは、すべてのページで同じCSS・JSを読み込む作りになっていることが少なくありません。問い合わせページでしか使わないスクリプトが全ページで読み込まれていれば、その分だけ全ページが遅くなります。ページごとに必要なファイルだけを読み込む形に整理し、ファーストビューの描画に必要なCSSはクリティカルCSSとして先に届け、残りは後から読み込ませます。JavaScriptはdefer / asyncで描画をブロックしないようにします。テーマを自作する場合は、この読み込み制御を最初から組み込んでおくのが最も確実です。
プラグインは数ではなく中身で判断する
「プラグインは10個以内に」といった数の目安が語られることがありますが、実際には数より中身です。全ページで重い処理を走らせるものが1つあれば十分に遅くなりますし、管理画面でしか動かないものは表示速度にほぼ影響しません。整理するときは、次のような観点で1つずつ判断します。
- フロント側で毎回動くのか、管理画面だけで動くのか
- テーマ側の数十行で置き換えられる機能ではないか
- 更新が続いており、セキュリティ面で安心して使えるか
- 担当者の更新作業に直結していて、外すと運用が止まらないか
最後の観点が抜けると、速度と引き換えに運用が壊れます。「これは担当者が使っているから残す」という判断も、立派な設計です。速さは目的ではなく、使われ続けるサイトであるための条件のひとつだと考えています。
