究極のCore Web Vitalsチェックリスト (2026)

Table of Contents!

• 究極のCore Web Vitalsチェックリスト
• Core Web Vitals最適化チェックリスト
  • 画像を最適化する
  • Webフォントを最適化する
  • スクリプトを最適化する
  • スタイルを最適化する
  • Resource Hintsを最適化する
  • アイコンを最適化する
  • サーバーの応答時間を最適化する
  • インタラクティビティを最適化する
  • Core Web Vitalsの監視
  • Critical Rendering Pathを最適化する
  • クッキーの同意を最適化する
  • シングルページアプリケーションを最適化する
  • 過剰なDOMサイズを避ける
  • APIリクエストを最適化する
  • チャットウィジェットを最適化する
  • Service Workerのパフォーマンスを最適化する
  • 動画コンテンツを最適化する

画像を最適化する

表示されるviewport内の大きな画像は、ほとんどの場合、Largest Contentful Paint要素になります。画像の最適化は、LCPに対して実行できる最も影響の大きいアクションの1つです。画像の速度を向上させるには、これらのCore Web Vitalsチェックリスト項目を使用してください。完全な戦略については、LCP画像の最適化方法に関するガイドをお読みください。

• 画面上の最大寸法に合わせて画像のサイズを変更する: これにより、最大画面サイズよりも大きい画像をダウンロードするためにバイトが無駄になることはありません。このプラクティスを、画面サイズが小さい場合のレスポンシブ画像と組み合わせてください。正しいサイズの画像を提供すると、目に見える品質の低下なしに画像ファイルサイズを50%以上削減できます。
• スクロールせずに見えない画像にはlazy loadingを使用する: lazy loadingは、viewport外の画像のロードを、スクロールして表示されるまで遅延させ、First Contentful Paint (FCP)とページ全体のロード時間を改善します。LCP画像にlazy loadingを使用しないでください。大幅に遅延します。
• LCP要素など、視覚的に重要な画像をプリロードする: プリロードは、他のコンテンツの前に重要な画像をフェッチするようにブラウザに指示し、LCPを優先します。最良の結果を得るには、<link rel="preload" as="image">とfetchpriority="high"を組み合わせて使用します。これは、LCP画像がCSSから参照されている場合、またはJavaScriptを介してロードされている場合に特に重要です。
• 幅と高さを設定する: 画像の寸法を事前に定義すると、ブラウザが画像のロードを待つことによって生じるlayout shiftを防ぐことができます。これによりCLSが向上します。最新のブラウザは、幅と高さの属性を使用して画像のロード前にアスペクト比を計算し、適切な量のスペースを確保します。
• WebPやAVIFなどの最新の画像フォーマットを使用する: これらのフォーマットは、JPEGやPNGと比較して、同様の品質を維持しながらファイルサイズを小さくできるため、ロード時間が短縮されます。通常、WebPはJPEGより25〜34%小さいファイルになりますが、AVIFはファイルサイズを最大50%削減できます。ブラウザの互換性を最大限に高めるには、フォーマットのfallbackを備えた<picture>要素を使用してください。
• ネイティブのlazy loadingを使用し、JavaScriptベースのlazy loadingを無効にする: lazy loadingは、viewport外の画像のロードを、スクロールして表示されるまで遅延させます。ブラウザがloading="lazy"属性を介して提供するネイティブのlazy loadingは、余分なスクリプトの解析や実行を必要としないため、一般的に、このタスクにJavaScriptを使用するよりも効率的です。
• srcsetを使用してレスポンシブ画像を使用する: この属性は、さまざまな画面サイズに対して異なる画像バージョンを指定し、ブラウザがユーザーのデバイスに最適な画像を提供できるようにして、不要な大規模なダウンロードを削減します。正確な制御を行うには、srcsetとsizes属性を組み合わせてください。
• decoding="async"を追加する: decoding="async"属性は、画像のデコード中にブラウザが他のコンテンツをブロックするのを防ぎます。これにより、レンダリングエンジンは、並行して行われる画像デコード中に他の要素のペイントを続行できます。
• 画像のメタデータを削除する: 画像に埋め込まれたEXIFデータなどのメタデータは、不要なバイトを追加する可能性があります。この情報を削除すると、画質に影響を与えることなくファイルサイズを縮小できます。ImageOptim、Squoosh、Sharpなどのツールを使用すると、ビルドプロセスの一部としてメタデータの削除を自動化できます。
• LCP要素にCSSの背景画像を使用しない: CSSで参照される背景画像は、HTMLの<img>要素よりも後でブラウザに検出されます。LCP要素として背景画像を使用する必要がある場合は、<link rel="preload">タグでプリロードし、早期に検出されるようにしてください。LCPのresource load delayについて詳しく学んでください。

Webフォントを最適化する

WebフォントはFirst Contentful Paintを遅延させ、layout shiftを引き起こし、初期の帯域幅リソースを競合する可能性があります。スムーズなWebフォント体験を確保するには、このチェックリストを使用してください。フォントホスティングのベストプラクティスについては、Google Fontsのセルフホストに関するガイドを参照してください。

• より速い最初のペイントのためにfont-display: swapを使用する: @font-face宣言でfont-displayプロパティをswapに設定します。これにより、バックグラウンドでWebフォントをロードしている間、ブラウザはfallbackフォントをすぐに表示します。フォントの準備ができると、シームレスにスワップされます。Webフォントのロード中にテキストが表示されたままになるようにすることについて詳しく読んでください。
• プリロードと組み合わせたfont-display: optionalを使用して、フォントによって引き起こされるlayout shiftを排除する: font-display: optionalとプリロードを組み合わせると、速度と潜在的なlayout shiftのバランスがとれます。optional値は、fallbackフォントを使用する前にテキストを短時間（約100ミリ秒）非表示にします。プリロードはブラウザにWebフォントを早期にフェッチするように指示し、fallbackフォントに費やされる時間を最小限に抑え、layout shiftを減らします。
• fallbackフォントをWebフォントの寸法に一致させるためにfont-face記述子を使用する: これにより、WebフォントがスワップインするときのCLSが最小限に抑えられます。fallbackフォントのsize-adjust、ascent-override、descent-override、line-gap-overrideを使用して同様のメトリクスを指定することで、フォントのロード時にコンテンツがジャンプするのを防ぐことができます。
• 必要な文字のみを含めるようにフォントをサブセット化する: コンテンツに必要な文字のみを含めるようにフォントをサブセット化して、フォントファイルサイズを縮小します。Font Squirrel、pyftsubset、glyphhangerなどのツールはサブセットの生成に役立ちます。完全なラテン文字セットのフォントは、適切なサブセット化により、100KB以上から20KB未満に縮小できることがよくあります。
• フォントの太さとスタイルの数を制限する: 過剰なフォントバリエーションのロードを避けてください。最大2つの重要なフォント（通常はプリロードされる）と2つの遅延ロードフォント（初期レンダリング後にロードされる）に固執します。フォントの太さを追加するごとに、ダウンロードサイズが15〜50KB追加されます。

スクリプトを最適化する

スクリプトは、Interaction to Next Paintの問題を引き起こしたり、Cumulative Layout Shiftを引き起こしたり、Largest Contentful Paintを遅延させたりする可能性があります。最適化された比較的無害な初期スクリプトでさえ、リソースを競合し、ペイントメトリクス（LCPおよびFCP）を遅らせる可能性があります。完全なガイドについては、JavaScriptを遅延させる14の方法を参照してください。

• 不要なJavaScriptを削除する: 使用されていないJavaScriptコードを特定して排除し、ダウンロードして実行する必要があるコードの量を最小限に抑えます。Chrome DevToolsのCoverageタブを使用して、使用されていないコードを見つけます。デッドコードを削除すると、ダウンロード時間とmain threadの処理時間の両方が削減されます。
• 機能と重要度に基づいてスクリプトの優先順位を付ける: 表示されるviewportに大きな変更を加えるスクリプトは、render blockingである必要があります。重要なスクリプトは、deferまたはasyncでロードする必要があります。あれば便利なスクリプトは、ブラウザのアイドル時にロードする必要があります。詳細な戦略については、リソースの優先順位付けガイドを参照してください。
• コードの分割とlazy loading: 大きなJavaScriptバンドルを小さなチャンクに分割し、必要な場合にのみロードします。これにより、初期ロード時間が短縮されます。webpack、Rollup、esbuildなどの最新のバンドラーは、動的インポートに基づく自動コード分割をサポートしています。
• JavaScriptファイルを最小化して再コンパイルする: SWC、Terser、esbuildなどの最小化ツールを使用して、JavaScriptファイルを常に最小化および再コンパイルしてください。最小化により、通常、JavaScriptのファイルサイズが30〜50%削減されます。
• サードパーティスクリプトを制限する: サードパーティスクリプトは、大きなパフォーマンスのオーバーヘッドをもたらす可能性があります。必要性を評価し、可能であれば代替案を検討してください。サードパーティスクリプトごとに、DNSルックアップ、接続のオーバーヘッド、main threadの処理時間が追加されます。Chrome DevToolsのNetworkパネルを使用して、サードパーティスクリプトを定期的に監査します。
• サードパーティスクリプトを非同期にロードする: サードパーティスクリプトは予測できない性質があるため、サードパーティによってレンダリングがブロックされないようにしてください。すべてのサードパーティのスクリプトタグでasyncまたはdefer属性を使用します。
• サードパーティスクリプトのパフォーマンスを監視する: Long Animation Frames (LoAF) APIまたはCoreDashを使用して、サードパーティスクリプトがINPおよびLCPに与える現実世界の影響を追跡します。サードパーティJavaScriptのパフォーマンス予算を設定し、定期的に確認します。

スタイルを最適化する

スタイルはデフォルトでrender blockingです。スタイルを最適化すると、ペイントメトリクスが最適化されます。Webページのスタイルパフォーマンスを向上させるには、チェックリストに従ってください。render blockingのCSSは、First Contentful PaintとLCP要素のrender delayの両方に直接影響します。未使用のスタイルをクリーンアップするヒントについては、未使用のCSSを削除する方法を参照してください。

• CSSファイルを最小化する: CSSファイルから空白、コメント、フォーマットなどの不要な文字を削除します。最小化されたファイルはサイズが小さくなり、ロード時間が短縮されます。cssnano、PostCSS、またはCSSプリプロセッサに組み込まれた圧縮などのツールを使用すると、これを自動化できます。
• 未使用のCSSを削除する: Webページで使用されていないCSSコードを特定して排除します。これにより、ブラウザがダウンロードして解析する必要があるデータの量が減り、パフォーマンスが向上します。PurgeCSSまたはChrome DevToolsのCoverageタブなどのツールは、未使用のCSSを特定するのに役立ちます。
• クリティカルCSSをインライン化する: 初期ページコンテンツのレンダリングに不可欠なスタイルをHTMLで直接提供して、ペイントメトリクスを改善します。新規の訪問者にのみクリティカルCSSを提供し、リピーターにはキャッシュされた外部スタイルシートを使用することを検討してください。この手法により、外部スタイルシートのフェッチに必要なラウンドトリップが排除され、FCPが削減されます。
• CSSファイルサイズを均等に分散する: すべてのCSSを1つのファイルに結合することは効率的に思えるかもしれませんが、ファイルが大きすぎるとダウンロード時間が遅くなる可能性があります。ロードを最適化し、ブラウザがスタイルを段階的に処理できるように、CSSをより均等なサイズ分布（それぞれ10〜15KB）の小さなファイルに分割することを検討してください。
• オフスクリーンスタイルを非同期でロードする: 初期のviewport外の要素に適用されるスタイルについては、media="print" onload="this.media='all'"パターンを使用した非同期ロードの使用を検討してください。これにより、ページの初期レンダリングをブロックすることなく、ブラウザは他のリソースと並行してこれらのスタイルをフェッチできます。

Resource Hintsを最適化する

リソースヒントは、重要なリソースのダウンロードの優先順位を決定するのに役立ちます。プリロードされたリソースは通常、ダウンロードのためにキューに入れられ、プリロードしない場合よりもはるかに早くブラウザで利用可能になります。リソースヒントを効果的に使用すると、LCPのresource load delayを大幅に削減できます。高度な実装については、103 Early Hintsについてお読みください。

• 重要でないリソースヒントを削除する: 初期ページのロードに不可欠ではないリソースのプリロードヒントを削除します。これにより、帯域幅が制限された初期リソースと競合する不要なダウンロードやネットワーク接続を防ぎます。不要なプリロードはそれぞれ、重要なリソースに使用できる帯域幅を消費します。
• 重要なドメインに事前接続（preconnect）する: 重要なドメイン（コンテンツ配信ネットワークやフォントプロバイダーなど）との接続を早期に確立します。これにより、DNS、TCP、TLSハンドシェイクを事前に完了することで、これらのドメインからの重要なリソースのダウンロードが高速化されます。重要なサードパーティのオリジンには<link rel="preconnect" href="https://example.com">を使用します。
• 事前接続の代替手段としてDNSプリフェッチを検討する: 事前接続と同様に、DNSプリフェッチは潜在的な接続についてブラウザにヒントを与えます。ただし、事前接続は完全な接続の確立を優先しますが、DNSプリフェッチはドメイン名を事前に解決するようにブラウザに指示するだけです。事前接続の完全な接続オーバーヘッドが正当化されない場合は、<link rel="dns-prefetch">を使用します。
• LCP要素をプリロードする: LCPは、メインコンテンツのロードにかかる時間を測定します。LCP要素をプリロードすると、この重要なリソースのダウンロードを優先するようにブラウザに指示し、ユーザーがメインコンテンツを見るまでの時間を短縮します。これは、CSSで参照されたり、JavaScriptを介してロードされたりする画像にとって特に重要です。
• 重要なフォントをプリロードする: 重要なフォントをプリロードすると、ブラウザがフォントを早期にフェッチできるようになり、テキスト表示の遅延を防ぎ、フォントのスワップによって引き起こされるCumulative Layout Shiftを改善します。最も重要な書体には<link rel="preload" as="font" type="font/woff2" crossorigin>を使用します。
• リソースヒントには103 Early Hintsを優先する: 103 Early Hints HTTPステータスコードを使用すると、サーバーは完全なレスポンスの準備ができる前にリソースヒントを送信できます。サーバーが103をサポートしていない場合は、代わりにLinkレスポンスヘッダーを使用します。ヘッダーが使用できない場合は、fallbackとしてページの<head>に<link>要素を追加します。ヒントの配信が早いほど、リソースの検出が早くなります。
• CSSファイルがフォントを検出する前にフォントをプリロードする: CSSで参照されるフォントは、CSSファイルがダウンロードされて解析された後にのみ検出されます。HTMLの<head>でフォントを直接プリロードすることで、CSS解析への依存を排除し、フォントを並行してロードできるようにして、FCPとlayout shiftのリスクの両方を軽減します。

アイコンを最適化する

アイコンを最適化しないと、ページに大きな重みが追加される可能性があります。大きなインラインSVGアイコンはHTMLを肥大化させますが、アイコンフォントには何千もの未使用のグリフが含まれることがよくあります。アイコンを最適化すると、LCP（HTML/CSSの重みの軽減）とCLS（適切な寸法予約）の両方に影響します。

• HTMLでのインラインSVGアイコンを避ける: 大きなSVGアイコンをインライン化すると、HTMLコードのサイズが大きくなり、ページのロードが遅くなる可能性があります。HTMLサイズを最小限に抑え、ブラウザでアイコンをキャッシュできるようにするには、個別のファイルとして提供するか、アイコンフォントを使用する（注意して）などの代替方法を検討してください。外部のSVGスプライトシートは、多くの場合、パフォーマンスと柔軟性の間の最良のバランスです。
• 大きなアイコンフォントを避ける: Font Awesomeのような大きなアイコンセットをそのまま使用しないでください。サブセット化を使用して最適化されたアイコンフォントまたは個々のSVGを作成し、Webページ全体のサイズを縮小してロード速度を向上させます。完全なFont Awesomeセットは100KBを超える可能性がありますが、20個のアイコンを含むサブセットは5KB未満になる可能性があります。
• アイコンの幅と高さを予約する: 画像と同様に、アイコンの幅と高さを指定すると、ブラウザがスペースを予約し、ロード時のlayout shiftを防ぐのに役立ちます。SVG要素でwidthとheight属性を使用するか、CSSで明示的な寸法を設定します。
• 重要でないアイコンセットの優先順位を下げる: アイコンがページの初期レンダリングに不可欠ではない場合は、優先順位を下げてロードすることを検討してください。これにより、重要なコンテンツが最初にロードされ、Core Web Vitalsメトリクスへの影響が最小限に抑えられます。lazy loadingを使用するか、初期ペイント後にアイコンスタイルシートを非同期にロードします。

サーバーの応答時間を最適化する

サーバーの応答時間はTime to First Byte (TTFB)で測定され、すべてのペイントメトリクスと直接的な関係があります。サーバーの応答が遅いと、その後のすべてが遅延します。詳細な最適化戦略については、TTFBの問題の診断とパフォーマンスのためのCloudflareの構成に関するガイドをご覧ください。

• 高速で信頼性の高いホスティングプロバイダーを使用する: 強力なインフラストラクチャを備えた高速なホスティングプロバイダーは、サーバーの応答時間とWebサイト全体のパフォーマンスを大幅に向上させることができます。合成されたマーケティングの主張ではなく、実際のTTFB測定値を使用してホスティングプロバイダーをベンチマークします。
• サーバーサイドのコードとデータベースクエリを最適化する: コードの実行時間とデータベースのクエリ時間を頻繁に記録して、ボトルネックを見つけ、全体の速度を向上させます。クエリプロファイリングとアプリケーションパフォーマンスモニタリング（APM）ツールを使用して、遅いエンドポイントを特定します。
• キャッシュ戦略を実装する: ブラウザキャッシュとサーバーサイドキャッシュを利用して、頻繁にアクセスされるデータを保存し、データの繰り返し取得の必要性を減らし、ロード時間を短縮します。フルページキャッシュを使用すると、TTFBを数秒から100ミリ秒未満に短縮できます。キャッシュ期間の最適化について詳しく学んでください。
• パーソナライゼーションのためのクライアントサイドまたはエッジレンダリング: フルページキャッシュ機能を維持するために、カートの数、ログインステータス、マイナーなメニューの変更など、小さなパーソナライゼーションをクライアントサイドまたはエッジでレンダリングすることを検討してください。これにより、小さな動的要素のためにページ全体のキャッシュが無効になるのを防ぎます。
• サーバー構成を最適化する: パフォーマンスを向上させるために、Webサーバーの設定を確認して調整します。これには、接続のkeep-alive設定、ワーカープロセスの数、メモリ割り当て、timeout値が含まれます。構成が不適切なサーバーはリソースを無駄にし、応答時間を増加させる可能性があります。
• コンテンツ配信ネットワーク（CDN）を使用する: CDNは、Webサイトの静的コンテンツを複数のエッジノード（サーバー）に分散させます。これにより、ユーザーがコンテンツにアクセスするために必要な物理的な距離が短縮され、グローバルなオーディエンスのロード時間が短縮されます。さらに、CDNは通常、独自のサーバーよりも適切に構成されています。実践的な設定のウォークスルーについては、Cloudflareの構成に関するガイドを参照してください。
• サーバーサイドの処理を減らす: リクエストごとにサーバーが行う作業量を最小限に抑えます。高価な操作を事前に計算し、効率的なアルゴリズムを使用し、必須ではない処理をバックグラウンドジョブに移動します。アプリケーションのリクエストライフサイクルを分析して、不要な処理手順を見つけて排除します。
• HTTP/3を使用する: HTTP/3は、Hypertext Transfer Protocolの最新バージョンです。HTTP/3はHTTP/2よりも高速で効率的であり、HTTP/1.1よりも大幅に高速です。HTTP/3にアップグレードすると、全体的なページのロード時間が改善され、潜在的に3つのCore Web Vitalsメトリクス（LCP、INP、CLS）すべてが改善される可能性があります。接続期間の最適化について詳しく学んでください。
• Server-Timingヘッダーを設定する: これらのヘッダーは、ページのさまざまな部分がサーバーで処理されるのにかかる時間に関する詳細な情報を提供します。このデータを使用して、特にLargest Contentful Paint (LCP)の改善に焦点を当てて、ボトルネックや改善の余地がある領域を特定できます。Server-TimingヘッダーはChrome DevToolsのNetworkパネルに表示され、CoreDashなどのRUMツールでキャプチャできます。
• 遅いデータベースクエリをログに記録し、定期的に最適化する: データベース（MySQL、PostgreSQL、MongoDB）でスロークエリログを有効にし、ログを毎週確認します。頻繁なクエリに対するインデックスの最適化、クエリの再構築、キャッシュレイヤーの追加により、TTFBを大幅に削減できます。
• GZIPまたはBrotli圧縮を使用する: GZIP、または新しいBrotliは、送信前にテキストベースのリソース（HTML、CSS、JavaScript）をオンザフライで圧縮し、ファイルサイズを約70%小さくします。Brotliは通常、GZIPよりも15〜20%優れた圧縮を実現します。ファイルサイズが小さいほど、ロード時間が短縮されます。

インタラクティビティを最適化する

Interaction to Next Paint (INP)は、サイトがユーザーの操作にどれだけ速く応答するかを測定します。インタラクティビティの低下は多くの場合、main threadをブロックする長時間実行されるJavaScriptタスクによって引き起こされます。3つのINPフェーズの完全な内訳については、入力遅延、処理時間、およびプレゼンテーション遅延に関するガイドを参照してください。

• 高価なスクリプトにidle-until-urgentパターンを実装する: このアプローチでは、重要なタスクを優先し、ブラウザのmain threadがアイドル状態になるまで、重要でないJavaScriptの実行を延期します。これにより、レンダリングやユーザーインタラクションなどの重要なタスクが、長時間実行されるスクリプトによってブロックされなくなります。緊急でない作業をスケジュールするには、requestIdleCallbackを使用します。処理時間の最適化について詳しく学んでください。
• main threadにyieldしてlong taskを分割する: 複雑なJavaScriptタスクはmain threadをブロックし、応答性を遅らせる可能性があります。これらのタスクを小さなチャンクに分割し、チャンク間でmain threadに制御を戻す（yield）ことで、ブラウザはユーザーインタラクションを処理し、スムーズなユーザー体験を維持できます。long taskを分割するには、（サポートされている場合は）scheduler.yield()またはsetTimeout(0)を使用します。JavaScriptスクロールを廃止してINPを改善するに関するガイドを参照してください。
• 入力後に即座にフィードバックを提供する: ユーザーは、ウェブサイトを操作した後の即時の応答性を期待しています。長時間実行されるタスクがバックグラウンドで処理されている間でも、視覚的な手がかりを提供するか、ユーザーの入力を迅速に確認します。瞬時の視覚的フィードバックには、CSSトランジションと:active疑似クラスを使用します。これは、インタラクティビティの感覚を維持し、ユーザーがウェブサイトがフリーズしていると感じるのを防ぐのに役立ちます。
• スクロールとタッチにパッシブイベントリスナーを使用する: スクロールおよびタッチのイベントリスナーに{ passive: true }を追加します。パッシブリスナーは、ハンドラーがpreventDefault()を決して呼び出さないことをブラウザに伝え、JavaScriptを待たずにすぐにスクロールを開始できるようにします。これはモバイルデバイスで特に効果的であり、スクロールに隣接するインタラクションのINPを直接改善します。

Core Web Vitalsの監視

Core Web Vitalsを継続的に監視することは、リグレッションを早期に発見し、最適化が期待される影響を与えたことを検証するために不可欠です。完全な状況を把握するために、ラボツール、field data、およびRUMを組み合わせて使用します。

• 定期的にLighthouseを確認する: LighthouseはGoogleが提供する無料のオープンソース監査ツールであり、Webページのパフォーマンスの問題を特定するのに役立ちます。Lighthouseは実際のユーザーのコンテキストでCore Web Vitalsを直接測定するわけではありませんが、規制された標準的な条件下でWebサイトを定期的にテストおよび比較するための優れたツールです。デプロイ前にリグレッションを検出するために、CI/CDパイプラインでLighthouseを実行します。
• 定期的にCrUXの履歴データを確認する: CrUX（Chrome User Experience Report）は、実際のパフォーマンスデータを提供するGoogleのパブリックデータセットです。CrUXは、Core Web Vitalsに合格しているかどうかを判断するためにGoogleが使用するデータソースです。履歴データを使用して、リグレッションをすばやく見つけます。PageSpeed Insights、CrUX Dashboard、またはCrUX APIを通じてCrUXデータにアクセスできます。
• RUMトラッキングを設定する: RUM (Real User Monitoring)には、Webサイトでの実際のユーザー体験の追跡が含まれます。RUMツールは、さまざまな場所やデバイスから訪問者がページをロードするのに実際にどれくらいの時間がかかるかに関するデータを収集します。これにより、実際のパフォーマンスに関する貴重な洞察が得られ、LighthouseやCrUXからのシミュレートされたデータを補完します。詳細なCore Web Vitalsアトリビューションデータを得るには、RUM追跡ツールとしてCoreDashをお勧めします。
• パフォーマンス予算を設定する: パフォーマンス予算は、さまざまなメトリクスに対して特定のパフォーマンス目標（たとえば、LCPを2.5秒未満、INPを200ミリ秒未満、CLSを0.1未満）を設定します。これらは、最適化の取り組みを導くベンチマークとして機能します。これらの予算に照らしてパフォーマンスを定期的に確認することで、直ちに注意が必要な領域を特定し、最適化の優先順位を付けることができます。
• セグメンテーションを使用する: セグメンテーションを使用して、最も価値のある訪問者タイプとさまざまなページタイプを追跡します。そうしないと、大量のトラフィックが、これらの重要なグループに特有のパフォーマンスの問題を隠してしまう可能性があります。デバイスタイプ、接続速度、地域、およびページテンプレートでセグメント化して、隠れた問題を明らかにします。

Critical Rendering Pathを最適化する

Critical rendering pathは、ブラウザがHTML、CSS、およびJavaScriptを視覚的なピクセルに変換するために実行する一連のステップです。このパスを最適化すると、First Contentful PaintとLCP要素のrender delayが直接向上します。過剰なDOMサイズを回避する方法も参照してください。

• 重要なリソースの数を最小限に抑える: すべてのrender blockingリソース（CSSおよび同期JavaScript）は、ブラウザがペイントする前にダウンロードして処理する必要があります。必須ではないスクリプトを遅延させ、重要ではないスタイルシートを非同期ロードすることで、重要なリソースの数を減らします。
• リソースロードの順序を最適化する: 重要なCSSとフォントが最初にロードされ、次にアバブザフォールドの画像、次に遅延スクリプトがロードされるようにします。重要性をブラウザに伝えるには、fetchpriority属性とリソースの優先順位付けヒントを使用します。
• DOMツリーの深さを減らす: 深くネストされたDOMツリーは、スタイル計算時間を増加させ、レイアウト作業を増加させます。可能な場合は、深さを最大32レベル、合計DOM要素を1,500個未満にすることを目指してください。DOM構造をフラットにすると、ペイントパフォーマンスとINPのプレゼンテーション遅延の両方が向上します。
• 要素タグや属性よりもクラスとIDを優先する: p.importantの代わりに、.importantを使用します。これにより、ブラウザがスタイルの照合のためにそのタイプのすべての要素を検索する必要性が減り、スタイルの再計算が高速化されます。
• セレクタを深くネストしない: CSSセレクタを深くネストするほど、ブラウザが実行する必要がある計算が多くなります。ネストを減らすようにHTMLを再構築するか、要素に近いより具体的なクラスを使用してみてください。セレクタの深さは最大3レベルに制限します。
• 子孫セレクタを最小限に抑える: .container > .contentのようなセレクタは、ブラウザにコンテナ内のすべての要素をチェックさせます。可能であれば、コンテンツ要素に直接クラスを使用して、セレクタの照合を高速化します。
• 同じスタイルを持つセレクタを統合する: 複数の要素が同じスタイルを共有している場合は、それらを単一のクラスにグループ化するか、メンテナンス性を高め、CSS出力を小さくするためにBEM（Block Element Modifier）命名規則を使用します。

クッキーの同意を最適化する

クッキーの同意バナーはGDPRなどの規制によって義務付けられていますが、慎重に実装しないとCore Web Vitalsに大きな影響を与える可能性があります。適切にロードされない同意バナーは、LCPを遅延させ、CLSを引き起こし、INPを増加させる可能性があります。詳細については、Core Web Vitalsのためのサードパーティウィジェットの最適化についてお読みください。

• 動的ページの場合はサーバーサイドのクッキー同意を検討する: サーバーサイドで動的にレンダリングされるページの場合、初期HTMLレスポンスで同意バナーをレンダリングするサーバーサイドソリューションを実装する方が、個別のJavaScriptベースのソリューションをロードするよりも速いことがよくあります。これにより、余分なネットワークリクエストとスクリプト評価のオーバーヘッドがなくなります。
• キャッシュされたページにクッキー同意スクリプトを非同期ロードする: キャッシュされたページの場合は、クッキー同意スクリプトを非同期ロードし、スクリプトにfetchpriority="high"を追加して、ユーザーインタラクションの前に表示されるのに十分早くロードされるようにすることを検討してください。
• LCPの干渉を避けるために同意テキストを短くする: ブラウザは表示される最大のテキストブロックを潜在的なLCP候補と見なすため、クッキー通知テキストが長いとLCP要素を乗っ取る可能性があります。テキストを短くするか、表示領域が小さい複数の段落に分割することを検討してください。
• クッキー通知スクリプトをセルフホストする: 可能な限り、クッキー通知スクリプトとスタイルシートをキャッシュしてセルフホストします。これにより、サードパーティの同意管理プラットフォームへのDNSルックアップと接続のオーバーヘッドが解消され、ロード動作を完全に制御できるようになります。

シングルページアプリケーションを最適化する

React、Vue、Angularなどのフレームワークで構築されたシングルページアプリケーション（SPA）は、Core Web Vitalsの固有の課題に直面しています。クライアントサイドレンダリングはFCPとLCPの両方を遅延させる可能性があり、ハイドレーションはINPをブロックする可能性があります。

• 常にサーバーサイドレンダリングまたはプリレンダリングを使用する: クライアントサイドレンダリングのみに依存するSPAは、コンテンツが表示される前に、ブラウザにJavaScriptのダウンロード、解析、実行を強制します。SSR（Next.js、Nuxt、SvelteKit）または静的プリレンダリングを使用して、ブラウザがすぐにペイントできる初期HTMLを提供します。
• 動的生成よりも静的プリレンダーを優先する: 静的プリレンダー（ビルド時に生成）は、サーバーサイドでの処理なしにCDNから直接提供できるため、動的に生成されたプリレンダーよりもはるかに高速です。リクエストごとのデータを必要としないページには静的生成を使用します。
• ハイドレーション後にサードパーティスクリプトをロードする: ハイドレーション中、フレームワークはすでにページをインタラクティブにするためにかなりのmain threadの時間を消費しています。サードパーティスクリプトを同時にロードすると問題が複合化し、入力遅延が悪化します。ハイドレーションプロセスが完了するまで、必須ではないすべてのスクリプトを延期します。

過剰なDOMサイズを避ける

大きなDOM（1,500を超える要素、または深さが32レベルを超える）は、メモリ使用量を増加させ、スタイル計算を遅くし、コストのかかるレイアウトの再フローを引き起こします。これは、INPのプレゼンテーション遅延とペイントメトリクスの両方に直接影響します。過剰なDOMサイズを修正する方法を参照してください。

• 不要なDOM要素を減らす: スタイルや構造の目的を持たないラッパー要素がないかHTMLを監査します。深くネストされた<div>構造をセマンティックなHTML要素に置き換えます。アクティブなDOMを小さく保つために、react-windowやvirtual-scrollerなどのライブラリを使用して長いリストを仮想化することを検討してください。
• 効率的なJavaScriptおよびCSSセレクタを使用する: 複雑なCSSセレクタとJavaScriptのDOMクエリ（幅広いパターンを持つquerySelectorAllなど）は、DOMサイズが大きくなるにつれて指数関数的に遅くなります。特定のクラスセレクタを使用し、可能な限りDOMクエリの範囲をサブツリーに制限します。
• オフスクリーンコンテンツにcontent-visibility: autoを使用する: CSSのcontent-visibility: autoプロパティは、スクロールして表示されるまで、オフスクリーン要素のレンダリングをスキップするようにブラウザに指示します。これにより、コンテンツセクションが長いページの初期レンダリング作業を大幅に削減できます。

APIリクエストを最適化する

レンダリングをブロックしたりコンテンツを遅延させたりするAPIリクエストは、LCPおよびTTFBに悪影響を及ぼす可能性があります。クライアントサイドのデータフェッチは、シングルページアプリケーションでの遅いLCPの一般的な原因です。

• APIリクエストの数を最小限に抑える: APIリクエストごとに、全体的なページロード時間が長くなります。ウェブサイトの機能を評価し、初期コンテンツのレンダリングに必要なAPIリクエストの数を減らす機会を特定します。データバッチ処理（複数のリクエストを1つに結合する）やGraphQLなどの手法を使用すると、ラウンドトリップを減らすことができます。
• 効率的で最適化されたAPIを使用する: API自体の設計と実装はパフォーマンスに影響を与える可能性があります。速度と効率が最適化された適切に設計されたAPIを使用していることを確認してください。頻繁に要求されるデータの応答時間を短縮するために、API側にキャッシュメカニズムを実装します。
• 重要なAPIリクエストをプリロードする: 画像などの重要なリソースのプリロードと同様に、重要なAPIリクエストをプリロードすると、知覚されるパフォーマンスが大幅に向上する可能性があります。<link rel="preload" as="fetch">を使用して、初期コンテンツのレンダリングに必要なときの遅延を最小限に抑え、重要なAPIを早期にフェッチするようにブラウザに指示します。その他のテクニックについては、リソースの優先順位付けガイドを参照してください。

チャットウィジェットを最適化する

チャットウィジェットは、layout shiftの一般的な原因であり、早期にロードされた場合、LCPの問題を引き起こす可能性さえあります。段階的なアプローチについては、完璧なCore Web Vitalsでチャットウィジェットを実装する方法をお読みください。

• メインコンテンツのロード後にチャットウィジェットをロードする: インターネットの歴史上、ページのメインコンテンツがロードされる前にチャットする必要があった人は一人もいません。requestIdleCallbackまたはスクロールベースのトリガーを使用して、ページが初期レンダリングを終了するまでチャットウィジェットの初期化を延期します。
• チャットウィジェットのlayout shiftを防ぐ: チャットウィジェットがlayout shiftを引き起こす場合は、ページ上で完全にレンダリングされるまでopacity: 0で非表示にすることをお勧めします。これにより、表示されるコンテンツをジャンプさせることなく、ウィジェットをバックグラウンドでレイアウトできます。CSSトランジションを使用して、ウィジェットをスムーズにフェードインさせます。
• 軽量のチャットウィジェットプロバイダーを選択する: 比較検討してください。一部のチャットウィジェットははるかに軽量であり、他のチャットウィジェットよりもCore Web Vitalsの問題が少なくなります。導入する前に、さまざまなプロバイダーのJavaScriptバンドルサイズ、ネットワークリクエスト数、およびINPへの影響を比較してください。

Service Workerのパフォーマンスを最適化する

Service Workerは、アセットやページ全体のレスポンスをキャッシュすることで、リピート訪問のパフォーマンスを大幅に向上させ、再訪問者のTTFBを削減できます。ただし、適切に実装されていないService Workerは、実際にはナビゲーションを遅らせる可能性があります。キャッシュ期間の最適化について詳しく学んでください。

• 重要なアセットをService Workerにキャッシュする: CSS、JavaScript、フォント、画像などの静的アセットにはキャッシュファーストの戦略を使用します。これにより、リピーターはローカルキャッシュからほぼ瞬時にサイトをロードできるようになります。Service Workerのインストールイベント中に、最も重要なリソースをプリキャッシュします。
• Service Workerコードを最適化する: Service Workerを無駄なく効率的に保ちます。複雑なルーティングロジック、event.waitUntil()の過剰な使用、およびインストールを遅らせる大規模なプリキャッシュマニフェストを避けます。頻繁に変更されるが、即時の鮮度を必要としないリソースには、stale-while-revalidateパターンを使用します。

動画コンテンツを最適化する

動画要素は、viewport内で最大の表示コンテンツである場合、LCP要素になる可能性があります。また、大きく最適化されていない動画は、他の重要なリソースと帯域幅を競合します。

• 動画を圧縮して最適化する: 適切な品質設定で、H.264、VP9、またはAV1などの最新のコーデックを使用します。動画の解像度を最大表示サイズに合わせて下げます。幅400pxで表示される動画を1920pxでエンコードする必要はありません。最高の品質とファイルサイズの比率を得るには、2パスエンコーディングを使用します。
• 動画にlazy loadingを使用する: スクロールせずに見えない動画の場合は、<iframe>要素にloading="lazy"属性を使用するか、Intersection Observer APIで動画のロードを遅延させます。自動再生されるバックグラウンド動画をポスター画像に置き換え、ユーザーがその近くにスクロールしたときにのみ動画をロードします。
• 高速なCDNで動画をホストする: 動画ファイルはサイズが大きく、CDN配信の恩恵を大きく受けます。アダプティブビットレートストリーミング、地理的分散、および最適化された配信を提供する専用の動画CDNまたはホスティングサービス（Cloudflare Stream、Mux、Bunny.netなど）を使用します。
• 動画要素にポスター画像を使用する: 常に<video>要素にposter属性を設定してください。ポスター画像は、ブラウザに動画のロード中にすぐにペイントするものを提供します。これはLCP要素として機能します。他のLCP画像と同様にポスター画像を最適化します。