Core Web Vitalsを制作フローに組み込む——デザイン・実装・公開後の3地点で見る

結論から書くと、Core Web Vitalsは「公開直前にPageSpeed Insightsで測る」だけでは間に合いません。私は確認ポイントを デザイン・実装・公開後 の3地点に分けて、それぞれ見る指標を決めています。数値が悪くなる原因の多くは、実はデザインの段階で決まっているからです。

前回の記事「「モダンなWeb」とは何を指すのか」では、LCP・INP・CLSのしきい値を紹介しました。今回は、それを制作工程のどこに埋め込むかの話です。

前提：「ラボ」と「フィールド」は別物として扱う

最初にチームで揃えておきたいのが、測定の種類です。web.devのWeb Vitalsの解説では、Core Web Vitalsはまずフィールド（実ユーザー）の指標であり、多くはラボ（シミュレーション環境）でも測れる、と説明されています。

種類	何で測るか	使いどころ
ラボ	Lighthouse、DevTools	制作中・公開前の確認
フィールド	Search Console、CrUX、web-vitalsライブラリ	公開後の実態把握

注意したいのはINPです。同じページによると、Lighthouseのようにユーザー操作のない環境ではINPは測れず、代わりにTBT（Total Blocking Time）が目安になるとされています。私は進行表に「公開前はTBT、公開後はINP」と書き分けて、数値の食い違いで議論が止まらないようにしています。

デザイン段階：CLSとLCPの「原因」をカンプで潰す

CLSの改善ガイドでは、主な原因として、サイズ指定のない画像、広告や埋め込み、Webフォント、レイアウトを動かすアニメーションが挙げられています。どれもカンプの段階で決められることです。

私がデザインレビューで確認している項目は次の通りです。

• 画像の比率が決まっているか：「16:9固定」「正方形固定」など。比率が決まっていれば実装で width・height や aspect-ratio を書けます
• 後から差し込まれる要素の場所が確保されているか：お知らせバナーや埋め込み地図などは、高さを持った枠としてカンプに描きます
• ファーストビューの主役が1つか：LCPの対象になるのは、だいたい最初に見える一番大きな画像か見出しです。主役がスライダーで何枚も入れ替わる設計は、実装側の選択肢が狭まります
• フォントの数：和文Webフォントを複数使う場合は、表示の切り替わりでずれが出ないか、実装担当と事前に相談します

デザイナーに「速度のことも考えて」と頼むより、この4項目をチェックリストとして渡したほうが伝わりやすいと感じています。

実装段階：LCP画像の扱いと、コミットごとの計測

実装で一番効くのは、LCPになる画像の扱いです。LCPの最適化ガイドでは、LCP画像には fetchpriority="high" を付けること、そしてLCP画像を遅延読み込み（lazy-load）しないことが勧められています。全画像に一律 loading="lazy" を付けるテンプレートは便利ですが、ファーストビューの画像だけは外す、というルールを書いておきます。

もう一つは、計測を人の記憶に頼らないことです。Lighthouse CIは、コミットごとにLighthouseを実行し、スクリプトや画像の容量に予算（バジェット）を設定して劣化を防ぐ仕組みとして公開されています。小さな案件なら、そこまで組まずに「プルリクエストごとにLighthouseのスクリーンショットを貼る」だけでも、どの変更で数値が落ちたかを後から追えるようになります。

公開後：28日単位で見る前提をクライアントと共有する

公開後はフィールドデータの出番です。Search Consoleのウェブに関する主な指標レポートのヘルプでは、データはChromeの実ユーザー指標（CrUX）に基づき、修正後の検証は28日間のモニタリングで行われると説明されています。また、評価はアクセスの75パーセンタイルが基準とされています。

つまり「昨日直したのに、まだ赤い」は普通に起こります。私は公開時の報告書に「改善の反映確認は約1か月後」と一行書いておき、月次の定例で見るようにしています。アクセスが少ないサイトではURL単位のデータが出ず、オリジン全体でまとめて表示される場合もあるので、その点も先に伝えておくと問い合わせが減ります。

明日から試せる一手

今進めている案件のWBSに、次の3行を足してみてください。

1. デザインレビュー：画像比率・差し込み要素の枠・ファーストビューの主役・フォント数を確認
2. 実装完了時：LCP画像に遅延読み込みが付いていないか確認し、Lighthouseの結果を記録
3. 公開1か月後：Search ConsoleでLCP・INP・CLSを確認し、定例で共有

3行だけでも、「公開直前に慌てて画像を圧縮する」という作業はかなり減るはずです。