各CORE WEB VITALを修正する
3つのメトリクス、3つの異なる役割。理論的な説明なしに、各メトリクスを改善する具体的な修正方法。
← Guides All guides in this topic
LCP:メインコンテンツを高速に読み込む
Largest Contentful Paintは通常、ヒーロー画像、大きな見出し、またはポスターフレームです。その要素を特定してください。それが高速になるまで、他のすべてはセカンダリです。
LCPを改善するレバー:リソースを圧縮・リサイズ、モダンフォーマットを使用、寸法を設定、遅く検出されるときは正確なURLをプリロード、CDNに配置、TTFBを減らしてバイト転送を開始。LCP画像の遅延読み込みは避ける。本来のLCPノードを遅延させるカルーセルは避ける。
サーバー側:HTMLそのものが遅い場合、画像トリックでは解決しません。キャッシュとオリジンを最初に修正してください。
重要なポイント:LCP要素に名前を付け、そのファイルと検出パスを退屈なほど高速にしてください。
INP:メインスレッドを自由に保つ
Interaction to Next Paintは、タップやクリック後にページがどれだけ素早く応答するかを測定します。メインスレッドの重いJavaScriptが通常の犯人です:大規模なハイドレーション、高コストなハンドラ、永遠に実行されるサードパーティスクリプト。
レバー:サードパーティを削除または遅延、ハンドラを分割、マーケティングページで大規模な同期コンポーネントを避ける、小さなアイランドを備えたサーバーレンダリングHTMLを優先、デスクトップスロットリングプリセットだけでなく実際の中級Androidデバイスでテスト。
重要なポイント:INPはメインスレッドから作業を削除したときに改善され、CSSトランジションをマイクロ最適化したときではありません。
CLS:ページのジャンプを止める
Cumulative Layout Shiftは視覚的な不安定性です。寸法のない画像、後から読み込まれてテキストをリサイズするフォント、レイアウトに穴を開けるアドと埋め込み、コンテンツの上に挿入されるバナー。
レバー:メディアに幅・高さまたはCSS aspect-ratio、アド用の予約スロット、レイアウトを破壊しないfont-displayストラテジ、既存コンテンツの上への遅延ロードUI廃止。新しいブロックをトップに挿入するより既存スペースを変形することを優先。
重要なポイント:後で表示されるものがあれば、その領域をあらかじめ確保しておく。
失敗し続ける間違い
| Metric | Common miss | Better move |
|---|---|---|
| LCP | Lazy-loading the hero | Eager + preload the real LCP URL |
| LCP | Optimising a non-LCP image | Identify the LCP node first |
| INP | Blaming CSS animations | Cut JS and third parties |
| INP | Testing only on desktop | Use a mid-tier phone |
| CLS | Ignoring font metrics | Subset fonts, reserve space |
| CLS | Cookie banners without space | Reserve or overlay carefully |
重要なポイント:繰り返される失敗のほとんどは、微細な最適化の不足ではなく、プロセスの誤りである。
3つすべてをパスする方法
不調なサイトの対応順序:まずLCPをクリアし、次にINPをクリアし、その後CLSをクリアする。各ステップ間でフィールドデータを再測定する。CWVチェックリストを本番リリースの関門として使用し、サーバーとフロントエンドの判別ができない場合は低速サイトガイドを参照する。
モバイルの75パーセンタイルで3つすべてに合格することで十分である。フィールドデータが健全な状態になったら、ラボ環境の100スコアのためにリリースを遅延させてはいけない。
重要なポイント:LCPを最初にクリアする。主要なコンテンツパスが正確になれば、INPとCLSは容易になる。
1週間の改善計画
1日目:フィールドデータを取得し、上位3テンプレートのLCP要素を特定し、すべてのサードパーティスクリプトをオーナーのリストアップする。2日目と3日目:LCPメディアとディスカバリー修正のみを実装する。4日目:最悪のサードパーティを削除するか遅延させ、スマートフォンでINPを再確認する。5日目:フィールド経験で確認できるCLS問題のある要素の領域を確保する。6日目と7日目:再測定し、残された問題を文書化し、残りの作業がリリースを阻害するかどうかを判断する。
その1週間は混在した複数のリファクタリングに1ヶ月を費やすことより優れている。なぜなら、毎日1つのメトリクスと1つの検証ループを持つからである。3日目の後もLCPが赤のままであれば、デザインシステムのクリーンアップを開始してはいけない。LCP要素が改善されるまで、それに専念する。
重要なポイント:再測定を伴う1日1メトリクスは、混在したパフォーマンスバックログより優れている。