この記事でできること
- 「遅い」感覚を、同じ条件の計測メモに置き換える
- 改善を1つだけ入れて再計測する実験ループを回す
- キャッシュや画像最適化を同時に盛りすぎない判断基準を持つ
だれ向けか
WordPressサイトが重いと感じ、改善系プラグインに手を出しそうな個人・小規模事業者向けです。サーバー移管の詳細手順や、全プラグインの決定版比較は扱いません。計測ツールの名称・閾値・UIは変わりうるため、数値目標の断定はしません。Core Web Vitals などの指標も「参考」として扱います。
結論：速さの改善は実験である
表示速度の改善で一番多い失敗は、計測なしにプラグインを足すことです。速くなったのか遅くなったのか分からず、サイトが複雑だけになります。
順番はこれだけです。
- 同じ条件で計測して記録する
- ボトルネック仮説を1つ書く
- 改善を1つだけ入れる
- 再計測して比較する
スコアを100にすることより、「何を変えたら何が変わったか」が分かることが先です。
計測→改善ループ
| ステップ | やること | メモの例 |
|---|---|---|
| 計測 | 代表ページ（トップ／重要LP）を同じ端末・同じ時間帯で測る | 日付、URL、ツール、結果の要約 |
| 仮説 | 「大きい画像が主因」など1行 | 複数仮説は今週扱わない |
| 改善 | 画像圧縮／キャッシュ1つ／不要プラグイン停止など1つ | 同時変更禁止 |
| 再計測 | 同条件で再度 | 良くなっても悪くなっても記録 |
画像まわりは画像ルール、プラグインの増やしすぎ防止はセキュリティ最小の思想とつながります。サーバー側の確認項目はConoHaチェックも参考にしてください（環境が違う場合は読み替え）。
よくある仮説の優先度（目安）
- 画像が大きすぎる／枚数が多い
- プラグインや埋め込みが多すぎる
- キャッシュやサーバー応答
- テーマやページビルダーの重さ
最初からサーバー乗り換えを結論にしないでください。計測と1改善のあとに、まだ不足ならサーバー選びを検討する、が安全です。
チェックリスト
- 代表URLを1〜2本に決めた
- 計測結果を日付付きで残した
- 仮説は1つだけ書いた
- 改善も1つだけ入れた
- 再計測した
- 「効いた／効かない」を1行でメモした
AIへの投げ方
役割: 表示速度の実験設計サポーター
前提: スコア目標の断定禁止。同時に複数改善を提案しない。
現状: [遅いと感じるページURL]
計測メモ: [貼る]
出力:
1. 仮説を優先度順に3つ（各1行）
2. 今週やる改善は1つだけ選ぶ理由
3. 再計測の記録テンプレ（項目だけ）やってはいけないこと
- 計測せずにキャッシュ系を複数入れること
- 本番でテーマ・プラグイン・画像を一気に全部いじること
- スコアだけ見てコンテンツ品質を犠牲にすること
- 「この数値なら必ず成約する」と断定すること
- 比較検討なしにサーバーを煽る記事だけで決めること
参照（公式・一次情報）
計測ツールの名称・閾値・UIは変わりうるため、作業前は公式を正としてください。
- PageSpeed Insights — 計測の公式入口
- web.dev：Core Web Vitals — 主要指標の一次情報
- WordPress：最適化 — WP側の公式概要
次のステップ（シリーズ内）
計測が終わったら、内部リンクと Search Console の接続も並行して進められます。
ツール・サービス紹介
※以下はアフィリエイトリンクです。
速度は計測と改善の話が本体です。ホスティングを検討する段階になったときの一例として、ConoHa WING への導線を示します（プラン・性能は公式で要確認）。
- 高性能レンタルサーバー ConoHa WING（A8.net）