「サイトが遅いので、サーバーを移したほうがいいでしょうか」という相談をよく受ける。
結論から言うと、移す前にやることがまだ残っていることがほとんどだ。移設は費用も止まるリスクもあるので、最後の手段でいい。共有サーバーのまま改善するとき、効果が大きい順に手を付ける手順を書く。
まず計測する。体感で判断しない
改善の前に、いまどこが遅いのかを数字で押さえる。PageSpeed Insights を開いて、URL を入れるだけでいい。
見るべき指標は3つ。
| 指標 | 意味 | 目安 |
|---|---|---|
LCP |
いちばん大きい要素が表示されるまで | 2.5秒以内 |
INP |
操作してから反応するまで | 200ms以内 |
CLS |
表示中にレイアウトがずれる量 | 0.1以内 |
多くのサイトで問題になるのは LCP だ。そして LCP の遅さの内訳は、たいてい画像かサーバーの応答時間のどちらかに寄っている。まずどちらなのかを切り分ける。
1. 画像を適正なサイズにする
いちばん効くのがここで、しかも一番安い。
よくあるのが、幅 4000px の写真をそのまま載せて、CSS で 800px に縮めて表示しているケース。ブラウザは 4000px 分をダウンロードしてから縮めるので、その待ち時間がまるごと LCP に乗る。
- 表示される最大幅の2倍程度までにリサイズする（Retina 対応を考えても2倍で足りる）
- WebP か AVIF に変換する。JPEG より3〜5割軽くなる
- ファーストビューより下の画像には
loading="lazy"を付ける - 逆に、ファーストビューの画像には
lazyを付けない。付けるとLCPが悪化する
すべての画像に一律で loading="lazy" を付けるプラグインがある。手軽だが、ファーストビューの画像まで遅延読み込みになるため LCP が悪化することがある。導入したら必ず計測し直す。
2. 画像の縦横を指定して、ずれを止める
CLS（表示中のガタつき）の原因は、ほぼ画像とフォントだ。
画像に width と height を書いておくと、ブラウザは読み込む前から場所を確保できるので、あとから押し出されない。CSS で aspect-ratio を指定しても同じ効果になる。
<!-- 実サイズを書いておく。CSS 側で width:100%; height:auto; にすれば伸縮する -->
<img src="/img/photo.webp" width="1600" height="900" alt="" loading="lazy">3. Webフォントを減らす
日本語のWebフォントは重い。ウェイトを4種類読み込んでいると、それだけで数百 KB になることがある。
- 実際に使っているウェイトだけに絞る（多くの場合、通常と太字の2つで足りる）
font-display: swapを付けて、フォントの読み込みが文字の表示を止めないようにする- 見出しだけ英字フォントにして、本文は端末に入っているフォントで表示する、という割り切りも有効
4. プラグインを棚卸しする
WordPress の場合、ここが効く。
有効化されているプラグインは、そのページで使っていなくても CSS と JavaScript を出力していることがある。10個入っていれば、10個分のファイルが毎回読み込まれる。
- 半年以上使っていないものは停止して、表示を確認したうえで削除する
- 「1ページでしか使っていない」プラグインは、そのページだけで読み込むように調整する
- 同じ目的のプラグインが2つ入っていないか確認する（キャッシュ系で起きやすい）
5. キャッシュを効かせる
ここまでやってまだ遅い場合に、キャッシュを見る。
CSS・JavaScript・画像・フォントは、更新されない限り再ダウンロードする必要がない。サーバー側で長期のキャッシュ期間を指定しておくと、2回目以降の表示が明確に速くなる。HTML は逆に、記事を直したらすぐ反映されてほしいので短くする。
それでも足りないとき
ここまでやって LCP が改善しないなら、サーバーの応答時間（TTFB）そのものを疑う段階になる。このときはじめて、上位プランへの変更や移設を検討する意味が出てくる。
順番を逆にすると、移設したのに大して速くならなかったという結果になりがちだ。遅さの原因が画像だった場合、サーバーを変えても画像の重さは変わらないためだ。