Core Web Vitals の改善：本当に効果のある順序
キャッシュプラグインを有効にするのは最初のステップであり、多くの場合、行われる唯一のステップです。その後、値は「改善が必要」のまま動かなくなります。理由は、3つの指標がそれぞれ異なるものを計測しており、キャッシュが本当に効くのはそのうち1つだけだからです。
3つの値を、それぞれ一言で
| 値 | 何を計測するか | 典型的な原因 |
|---|---|---|
| LCP | 最大の表示要素が表示されるまでの時間 | 大きすぎるヒーロー画像、遅いサーバー |
| INP | クリックに対するページの反応の速さ | ブラウザをブロックする過剰な JavaScript |
| CLS | 読み込み中にコンテンツがずれるかどうか | サイズ指定のない画像、後から読み込まれるバナーやフォント |
ここから順序が決まります。まず画像、次にスクリプト、そしてレイアウトです。キャッシュが主に効くのはサーバーの処理時間、つまり LCP の一部であり、INP にはほとんど効きません。
ステップ1：最大の画像
ほとんどのページでは、ヒーロー画像が LCP の候補です。すぐに効果が出る対策が3つあり、次の順序で行います。
- 実際に必要なサイズまで縮小します。1200ピクセル幅の領域に4000ピクセル幅の写真を使っているのが、単独の原因として最も多いケースです。
- 最新の形式（WebP または AVIF）に変換し、古いブラウザ向けのフォールバックを用意します。
- 遅延読み込みには絶対にしません。ページ最上部の画像はすぐに読み込まれるべきです。ここで Lazy-Load を使うと、値は改善するどころか悪化します。
変換がどこで行われるかを確認してください。プラグインによっては、変換のために画像を開発元のサービスに送信します。それを望まないなら、ローカルで変換するツールが必要です。その場合、最初の処理には時間がかかりますが、外部には何も出ません。
ステップ2：JavaScript
INP は、キャッシュが役に立たない値です。クリックに反応するまでにブラウザがかかる時間を計測するもので、それを妨げるのは、まさにその瞬間に処理を行っているスクリプトです。
最も効果的な手段は、削ることです。誰も操作しないスライダー、全ページに表示されるチャットウィンドウ、うち2つは誰にも気づかれない3つのフォントファミリーなどです。defer、結合、最初の操作までの遅延が効果を発揮するのは、その後です。
ステップ3：レイアウトのずれをなくす
- すべての画像のマークアップに width と height を指定する。そうすればブラウザが領域を確保する
- 埋め込みコンテンツは、高さを固定した枠に入れる
- フォントは外部から後で読み込むのではなく、ローカルで配信して font-display で制御する
- Cookie バナーやお知らせバーは、コンテンツを押し下げるのではなく、コンテンツの上に重なるように組み込む
その後で：キャッシュ、Minify、Preload
ページキャッシュは、ページの生成を省きます。サーバーが遅ければ大きな効果があり、速ければ効果はわずかです。Minify はバイト数を削減しますが、最適化後にページが壊れる最も多い原因でもあります。Preload はお願いではなく命令です。多すぎると、まさに最初に必要なものを押しのけてしまいます。
Minify は1つずつ有効にし、そのたびにフォームのあるページ、カート、動画のあるページを確認してください。すべてを一度に有効にすると、不具合が起きたときに10個のスイッチの中から原因を探すことになります。
正しく計測する
2種類の計測は区別する必要があります。ラボテストは一定の条件で計測するもので、変更前と変更後の比較に向いています。フィールドデータは、実際の端末と回線を使う実際の訪問者から得られるもので、Google がページをどう評価するかはこちらで決まります。
そのため、計測は常に同じ条件で、1回ではなく3回行ってください。また、フィールドデータに変更が表れるまでには数週間かかります。1時間後に確認して変化がなくても、最適化が足りないのではなく、確認が早すぎるだけです。
プラグインではもう改善できない場合
どのキャッシュプラグインでもそれ以上は進めない限界があります。30個のスクリプトを抱えた重いページビルダー、ベース負荷の高いホスティング事業者、全ページですべてを読み込むテーマなどです。コンテンツがなくてもサーバーの応答がすでに遅いなら、原因はプラグインではありません。