表示速度改善の優先順位 — 全部やらないという判断
速度改善で最も多い失敗は、PageSpeed Insightsの指摘を上から全部潰そうとすることです。指摘には効果が10倍違うものが混在しています。この記事は「何をやるか」より「何をやらないか」を決めるための記事です。
公開日: 2026年8月16日 ／ 最終更新日: 2026年9月6日
スコアではなく指標を見る
最初に目的を確認します。速度改善の目的は、スコアを100点にすることではなく、ユーザー体験の閾値（Core Web Vitalsの「良好」基準）を満たすことです。順位の観点でも、評価されるのは実ユーザーの体感データ（CrUX）であり、ラボのスコアではありません。
したがって判断基準はこうなります。「Search ConsoleのCore Web Vitalsレポートで不良・改善が必要になっている指標があるか」。無ければ、速度改善の優先度自体を下げて、コンテンツに時間を使うべきです。
効果の大きい施策は3つに集約される
大半のサイトで、体感を変えるのは次の3つです。逆に言えば、これ以外の細かい指摘は後回しで構いません。
- 1. ページキャッシュ — 毎回動的生成しているページを静的に配信する。WordPressならキャッシュプラグイン導入。TTFB（サーバー応答）が数百ms〜秒単位で変わる、最も費用対効果の高い施策です
- 2. 画像の最適化 — 適切なサイズでの配信・WebP等への変換・遅延読み込み。転送量の大半は画像です
- 3. 不要なJavaScript/CSSの削減 — 使っていないプラグイン・計測タグ・ウィジェットの削除。追加した施策の「引き算」です
優先度を下げてよい指摘の例
- 数十ミリ秒単位の改善提案（次世代フォーマットで数KB削減等）— 労力に対して体感がほぼ変わりません
- 外部サービス起因の指摘（埋め込み地図・SNSウィジェット・広告）— 自分では直せません。そのサービスが必要かの判断だけします
- 既に「良好」の指標をさらに縮める改善 — 順位面の意味はほぼありません
「2.4秒を2.2秒にする」ことに時間を使うくらいなら、記事を1本書くほうがSEO全体への効果は大きい、というのが実務的な判断です。
進め方の型
- Search ConsoleのCWVレポートで、不良のページグループと指標を特定する
- その指標の主因を特定する（LCPならサーバー/描画ブロック/画像の3系統）
- 上の3施策から該当するものを実施する
- 実ユーザーデータの反映を待って確認する（28日間の移動平均のため、反映に時間がかかります）
定点観測の仕組み化
速度は劣化するものです。プラグイン追加・画像の増加・タグの追加で、気づかないうちに戻ります。月1回の定点観測をルーチンにするか、Smash SEOの定期監視のように自動でスコア低下を検知する仕組みを入れておくと、「気づいたら遅くなっていた」を防げます。
よくある質問
スコア100点を目指すべきですか？
いいえ。100点は「良好」の証明としては過剰で、そこに使う労力に見合う追加効果はありません。全指標が「良好」に入っていれば十分です。
AMPは導入すべきですか？
現在は不要です。AMPは検索結果での優遇（トップニュース枠の要件等）を失っており、通常のページを速くするほうが本筋です。
関連記事
- LCPが遅い（表示に4秒以上かかる）
LCPは「ページの主要コンテンツが表示されるまでの時間」で、Core Web Vitalsの中核指標です。2.5秒以内が良好、4秒超は不良という基準をGoogleが公表しています。改善は闇雲にやらず、原因の系統を特定してから効く順に手を付けます。 - CLSが大きい（表示中に画面がずれる）
CLSは「表示中に画面のレイアウトがどれだけずれたか」の指標です。読んでいた文章が急に下がる、押そうとしたボタンがずれて別のものを押す、という体験の数値化です。原因はほぼ3つに絞られ、いずれも対処法が確立しています。 - 画像のalt属性が設定されていない
alt属性は「画像が表示できないとき・見えない人のための代替テキスト」です。検索エンジンにとっては画像の内容を知る主要な手がかりで、スクリーンリーダー利用者にとっては画像の内容そのものです。ただし全画像に書けばよいわけではなく、書き方に原則があります。