Core Web Vitalsに対応した最適化と改善方法

Googleは、Core Web Vitalsに従ったウェブパフォーマンスの向上を推奨しています。その理由はシンプルで、Googleは主にウェブベースのサービスを提供しているため。低速なウェブサイトやウェブアプリケーションはユーザーに敬遠され、ネイティブアプリの使用を促すことになります。

Google検索でのページの表示順位は、検索キーワード、ページ内でのキーワードの使用、他からのリンクの数（と質）などの指標によって大きく左右されます。2021年8月以降、Googleはパフォーマンスに基づいてページを評価する取り組みも推進しています。

この記事では、GoogleのCore Web Vitalsの指標でウェブサイトを最適化する方法をご紹介します。

Core Web Vitalsの重要性

もちろん、コンテンツが重要であることに変わりはありませんが、類似のテキストと人気を持つ2つのサイトを比較した場合、よりウェブ体験が優れている方が、Google検索でより上位に表示されます。

表示順位の向上だけでなく、高性能なサイトはモバイル検索でカルーセル（画面上部で左右にスワイプできる仕様のリッチリザルト）掲載対象となります。この機能は、当初はモバイル端末でウェブページを高速表示する手法であるAccelerated Mobile Pages（AMP）のためのもので、コンテンツをGoogleの仕様にあわせて変換する、または作り直す必要がありました。また、特に最適化されたWordPressサイトや静的サイトよりも必ずしも高速であるとは限らないなどの理由から、一部批判の対象にもなりました。このような理由から、APMの導入は現在は必須条件ではありません。

いずれにしても、より高速で、レスポンシブなサイトであるほど、Googleの検索結果で上位に表示される可能性が高くなります。

平均的なページサイズが約2MB、そして60回以上のHTTPリクエストを行い、モバイル端末でレンダリングが完了するのに16秒かかることを考えれば、あなたのウェブサイトにも改善の余地があることはお分かりになるはず。後ほどご紹介する最適化の方法をぜひ実践してみてください。

Googleの検索順位に影響する主な要因

パフォーマンスの評価を始める前に、Googleの検索順位に影響を与える重要な要素を押さえておきましょう。

1. HTTPS：訪問者のブラウザとウェブサーバーとの間で安全な接続を提供することは不可欠。
2. モバイルフレンドリー：モバイル端末で快適に動作すること。また、小さな画面の端末でも問題なく利用できるか。コンテンツがはみ出したりせずに正しくレンダリングされるか。フォントサイズは小さすぎないか。クリック要素は問題なくタップできるか。
3. インタースティシャルを使用しない：インタースティシャルとは、ページ間の移動の合間などにインターフェースに表示される広告。画面占有率が高いため回避すること。また関連して、コンテンツは常に読みやすいかどうか。ポップアップ形式のインタースティシャルやバナーでコンテンツが部分的に見えにくくなったりしないか。広告やマーケティングプロモーションによってサイトの操作性が落ちていないか。
4. 安全性：マルウェア、ウイルス、フィッシング、詐欺などの脆弱性がないか。

上記の要因を満たして初めて、サイトのパフォーマンスが評価されます。

Googleのパフォーマンス評価

サイト速度を高速化し、素早くレンダリングを行い、サイトの応答性を高めることが重要ですが、実際にユーザー側でそれを体感することはできるのでしょうか。

ブラウザの開発者ツールのようなパフォーマンス測定アプリケーションでは、以下のような要素を測定することができます。

1. ブロック時間─ダウンロード開始までの待ち時間（スタイルシートやスクリプトなど、他のアセットの方が優先度が高い場合に発生）
2. DNSでの名前解決─アセットを取得するために、ドメインからIPアドレスへ変換（解決）する時間
3. 接続時間─TCP接続を開始するまでの時間
4. TTFB（Time to First Byte）─リクエストからレスポンスの1バイトを受信するのにかかる時間
5. 受信時間─アセット全体を取得するまでの時間
6. DOMの読み込時間─HTMLのドキュメントオブジェクトモデルをダウンロード、レンダリングする時間（通常、DOMを解析または変更するスクリプトを確実に実行できる最初のポイント）
7. ページ読み込み時間─ページと画像、スタイルシート、スクリプトなどのすべてのアセットをダウンロードするのにかかる時間
8. ページの総量─すべてのアセットの合計サイズ（一般的には圧縮─ダウンロード─サイズと非圧縮サイズの両方で報告される）
9. DOMの要素数─ページ上のHTML要素の総数（要素が多いほど、ページの処理にかかる時間が長い）
10. First Contentful Paint（FCP）─ブラウザが最初のコンテンツを表示するまでにかかる時間
11. FMP（First Meaningful Paint）─ページの主要コンテンツがユーザーに表示されるまでの時間
12. TTI（Time To Interactive）─ページが完全にインタラクティブになり、入力操作に確実に応答できるようになるまでの時間
13. First CPU Idle（FCI）─CPUがページをレンダリングし、すべての初期化スクリプトを実行して、ユーザーの入力操作が可能なアイドル状態になるまでの時間
14. CPU使用率─ページのレンダリングとユーザーの入力操作に応答する際に使用されたCPUの割合
15. 1秒あたりのレイアウト─ブラウザがスタイルとページレイアウトを再計算する速度

上記の指標は、サーバー負荷、CMSのキャッシュ、ブラウザキャッシュ、ダウンロード速度、JavaScriptの効率など、特定のボトルネックを特定するのに使用することができます。しかし、以下のような理由から、実際のユーザーエクスペリエンスを評価することはできません。

• アプリケーションのダウンロードや表示が早くても、最適化されていないJavaScriptコードが大量に実行されることなどが原因で、最初の操作で応答しなくなることがある。
• チャットアプリでは、ユーザーがメッセージを送信するたびにデータをダウンロードし続ける可能性がある。これによって、評価ツールでは、ページが応答しているにもかかわらず、読み込みが完了しなかったと判断されることも。

このような課題を解決すべく、Googleが提唱し始めたのがWeb Core Vitalsです。

Core Web Vitalsとは

GoogleのCore Web Vitals（CWV）は、実際のユーザー体験を評価する3つのパフォーマンス指標です。

• LCP（Largest Contentful Paint）─読み込み時間を測る指標
• FID（First Input Delay）─インタラクティブ性を測る指標
• CLS（Cumulative Layout Shift）─視覚的な安定性を測る指標

この未だ比較的新しいGoogleアルゴリズムの更新は、2021年8月末以降、全世界で展開されています。また、最初はモバイル検索に導入された指標でしたが、後にPC検索にも導入されています。

ページのLCP、FID、CLSスコアは、Chromeブラウザを通じて匿名で収集された過去28日間の実際のユーザー測定値に基づいて決まります。また、この測定値は、ユーザーのデバイス、接続、その他の同時動作によって変化する可能性があるため、平均値ではなく75パーセンタイル（小さい方から数えて任意の%に位置する値）が算出されます。

つまり、全ユーザーの指標を良いものから順に並べ替え、4分の3地点の数値を取ります。これによって、サイト訪問者の4人中3人は、その数値以上のパフォーマンスを体験しているということになります。

Core Web Vitalsの3つの指標ですべて良好（緑色）スコアを達成したページは、検索結果で上位に表示され、Google ニュースの「トップストーリー」カルーセルに表示されるようになります。

Core Web Vitalsの概要を押さえたところで、ここからは、指標スコアの計算に使用されるアルゴリズム、ページのスコアを特定するためのツール、スコアが低下する主な原因、およびパフォーマンスの問題を解決する方法についてご説明していきます。

Largest Contentful Paint（LCP）

Largest Contentful Paint（日本語で「最大コンテンツの描画」）とは、読み込み時間を測定します。つまり、使用可能なコンテンツがどれだけ素早くレンダリングされるかを調べます。

ブラウザのビューポート内（Above the foldまたはファーストビューとも）で最大サイズの画像やテキストブロックが表示されるようになるまでの時間を分析します。最大コンテンツとは、ヒーロー画像、バナー、見出し、または大きなテキストブロックなどが一般的です。

以下のいずれかの要素がLCPの解析対象となります。

• 画像（<img> 要素）
• SVG（Scalable Vector Graphics）内の画像（<image>を<svg> に埋め込んだもの）
• 動画のサムネイル（<video>内の画像URLに設定されたposter属性）
• 背景画像を持つ要素（通常はCSSのbackground-image url()プロパティで読み込まれる）
• テキストを含むブロックレベル要素

ページの読み込みを開始2.5秒以内にLCPが完了するページでは、GOOD（緑）、4.0秒を超える場合はPOOR（赤）と判断されます。

LCP解析ツール

LCPは、Core Web Vitalの指標の中で最も理解しやすいものですが、どの要素で分析すればいいのかわからないことも。

Google提供の無料ツール「Lighthouse」は、Chromeの他、Edge、Brave、Opera、VivaldiなどのChromiumベースのブラウザで使用できます。ブラウザのメニューからデベロッパーツールに移動し、Lighthouseタブに移動する手順です。例えば、Chromeであればメニューから「その他のツール」、もしくはショートカット「Ctrl | Cmd + Shift + i」、またはF12で「デベロッパー ツール」を開き、「Lighthouse」タブに移動します（古いものでは、Lighthouseではなく「Audit」と表示されていることも）。

モバイルのパフォーマンスレポートを作成し、結果の「パフォーマンス」セクションで「Largest Contentful Paint」を確認します。クリックすると詳細が表示されます。

Chromiumベースのブラウザが利用できない場合には、オンラインのPageSpeed Insightsやweb.dev Measureを使用することもできます。

デベロッパーツールの「パフォーマンス」タブには、LCPも表示されます。開始するには、円形の「記録」ボタンをクリックし、ページを再読み込みしてから、「停止」ボタンをクリックすると、レポートが表示されます。「タイミング」セクションにある「LCP」アイコンをクリックして要素を特定し、統計のサマリーを表示します。

ChromeにはWeb Vitals拡張機能がありますが、その他のChromiumベースのブラウザにもインストール可能です。この拡張機能を有効にすると、アクセスしたサイトごとにCore Web Vitalsの指標を計算し、その結果に応じてアイコンが緑、オレンジ、または赤に変化します。また、拡張機能のアイコンをクリックすると、LCPの詳細情報を表示することができます。

Google Search Consoleでは、サイトがプロパティとして追加されている場合、Core Web Vitalsセクションが表示されます。このレポートでは、CWVの指標がどのように変化してきたかを確認することができます。なお、特定のページのLCPではなく、ある程度のアクセス数があるサイトのみが対象です。

Chrome User Experience Reportでは、特定のURL、国、接続、デバイスでのLCPを含む実際の使用統計を確認することができます。GoogleのBigQueryによる公開プロジェクトであるため、Google Cloud Platformでアカウントの登録と支払い情報の設定が必要になります。なお、このレポートが役立つのは、アクセス数がそれなりにある場合のみです。

web-vitals JavaScriptライブラリは、1kBの小さなスクリプトで、本番サイト上の実際のユーザーを対象にして、LCPをはじめとするCore Web Vitalの指標を測定することができます。CDNからダウンロードできるため、以下のスクリプトをHTMLの<head>に貼り付ればOKです。

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>

getLCP()は非同期関数で、LCPのスコアが測定されたときにトリガーされるコールバックが渡されます（ただし、バックグラウンドのタブでページが読み込まれた場合にはトリガーされないことも）。コールバック関数には、以下の内容を含むオブジェクトが渡されます。

• name：指標名（ここでは「LCP」）
• value：測定値
• id：そのページでの指標を表す一意のID
• delta：現在の測定値と前回の数値の差分
• entries：値の測定に使用されるエントリの配列

上記スクリプトでは、オブジェクトをコンソールに出力するものですが、データをサーバーやGoogle アナリティクスに送信して分析するのが賢明です。

LCPのスコアが低下する主な原因

LCPのスコアが下がる一般的な原因は、ページの表示速度が遅く、最大サイズのブロックが素早く表示されないことにあります。

• サーバーに負荷がかかっていたり、ページを表示するのに必要な処理が多すぎたりするために、サーバーの応答が遅くなっている可能性が。ただし、これは必ずしもサイト自体に問題があるというわけではなく、共用サーバーをしている場合は、サーバーの制約が原因になっていることもある。
• CSSやJavaScriptが主要コンテンツより上のHTMLで参照されていると、レンダリングブロックによってページの読み込みが遅延することも。
• 大きな画像や動画などは帯域幅を消費し、レンダリングに時間がかかる可能性がある。
• サーバーではなくクライアント側で生成されたページコンテンツも表示に時間がかかることがある。

LCPを向上させる方法

徹底的に監査を行うことで、問題の原因を特定することができますが、基本的にはブラウザに送信されるデータ量を減らすことが重要です。以下のヒントを取り入れて、LCPのスコアを改善してみてください。

1. サーバーやホスティングサービスをアップグレードする。帯域幅の使用量が増えてもダウンロード速度を高速に保てるようにする。
2. サーバー圧縮とHTTP/2以上を使用する。
3. サーバーの負荷を減らす。未使用のコードやCMSプラグインは削除して、キャッシュを使用する。
4. ブラウザが効率的にファイルをキャッシュするように設定する。HTTPヘッダーに適切なExpires、Last-Modified、ETagを設定して、ファイルが再度リクエストされるのを回避。
5. コンテンツデリバリネットワーク（CDN）で負荷を分散し、物理的にユーザーに近いサーバーでアセットを配信する。
6. MyKinsta内蔵のコード圧縮で全体的に最適化を図る。
7. 画像を最適化する。最小サイズに縮小し、適切なフォーマットを使用してファイルサイズを最大限小さくする。最大サイズのコンテンツブロックにある画像は、できるだけ早い段階でリクエストするようにする（プリロードが効果的）。
8. loading="lazy"属性を追加して、画像を遅延読み込みする。画像の読み込みが完了する前に、ページ上に適切なスペースが確保されるよう、width属性とheight属性を設定する。
9. サードパーティのリクエストを最小限に抑え、不必要なDNSルックアップを避けるため、アセットをプライマリドメインに移すことも検討。
10. 要求されるファイル数とサイズは、特にHTMLの先頭で最小限に抑える。
11. 必要なウェブフォントのみを読み込む。またパフォーマンス最大化を考慮して、ウェブセーフフォントに変更する。
12. 未使用のJavaScriptとCSSファイルを削除する。
13. JavaScriptとCSSのファイルを結合して最小化する。
14. CSSの@import構文はレンダリングブロックを引き起こし、スタイルを連続して読み込むため回避する。
15. Base64エンコードは、ファイルサイズが大きくなり、追加の処理が必要になる可能性があるため避ける。
16. クリティカルCSSのインライン化。ページ上部の<link>ブロックにクリティカルCSS（Above the foldに必要なもの）を埋め込み、スタイルシートを非同期で読み込む。
17. 非同期、遅延、またはES modules（JavaScriptモジュール）を使用して、後でスクリプトを実行。Service Workerで時間のかかるJavaScriptプロセスを実行する。

First Input Delay（FID）

First Input Delay（日本語で「初回入力までの遅延時間」）は、ページの応答性を測定します。クリックやタップ、スクロールなどのユーザー側の操作に対して、どれだけ素早く反応するかを調べるものです。

FIDはユーザーとの対話からブラウザがリクエストを処理するまでの時間を測定します。なお、入力処理とDOMの更新を行うイベントハンドラの実行時間は計測されません。

F100ミリ秒以下のページはGOOD（緑）、300ミリ秒を超えるページはPOOR（赤）と判断されます。

FID解析ツール

First Input Delayは、訪問者が実際にページを操作したときにしか測定することができず、再現を行うことができません。したがって、結果は各デバイスのCPUの速度と機能に依存します。

FIDの場合、開発者ツールのLighthouseやPageSpeed Insightsでは計測できませんが、FIDの近似値を示す合計ブロック時間（TBT）を確認することができます。TBTは以下の時間の差を計算したものです。

1. FCP（First Contentful Paint）─コンテンツのレンダリングを開始する時間
2. TTI（Time to Interactive）─ページがユーザーの入力操作に応答できるまでの時間（長時間実行するタスクがなく、HTTPリクエストが3つ未満である場合に推定）

Chromeの拡張機能Web Vitalsでは、スクロールやクリックでページを操作した後にFID指標を確認することも可能です。拡張機能のアイコンをクリックすると、詳細が表示されます。

LCPと同様に、Chrome User Experience Reportで、特定のURLや国、接続、デバイスで記録された実際の統計情報を確認することができます。

web-vitals JavaScriptライブラリは、本番サイト上の実際のユーザーのFID指標を計算することもできます。以下のスクリプトをHTMLの<head>に追加し、FIDをコールバック関数に出力します。

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>

FIDのスコアが低下する主な原因

FIDおよびTBTのスコアが下がる一般的な原因は、CPUを占有する以下のようなクライアント側のコードにあります。

• コードのダウンロードと解析にページの読み込みを停止させ、レンダリングブロックとなる大量のCSSやJavaScript
• ページ読み込み時に即座に実行される大きく処理負荷の高いスクリプト
• 長時間にわたって実行される、または最適化されていないJavaScript処理

デフォルトでは、ブラウザは1つのスレッドで動作し、一度に1つのタスクしか処理することができません。つまり、JavaScriptの関数の実行に1秒かかると、その1秒の間には他のすべてのレンダリング処理が停止することになります。ページがユーザーの入力操作に応答したり、DOMを更新したり、アニメーションを表示したりすることができず、古いブラウザでは、GIFアニメーションもブロックされることがあります。

FIDを改善する方法

クライアント側のJavaScriptを監査して問題を特定するのが確実ですが、基本的には、冗長なコードを削除し、効率的に処理が実行されるようにすることが鍵となります。

FIDのスコアを改善する方法には、以下のようなものが挙げられます。

1. できる限りの静的なHTMLコンテンツをサーバー上で生成してキャッシュする。クライアントサイドのJavaScriptフレームワークに頼らず、すべてのユーザーに対して同じHTMLをレンダリングするようにする。
2. ブラウザが効率的にファイルをキャッシュするように設定する。HTTPヘッダーに適切なExpires、Last-Modified、ETagを設定して、ファイルが再度リクエストされるのを回避。
3. プログレッシブエンハンスメント技術を使用して、JavaScript実行前にHTMLとCSSでインターフェースを使用できるようにする。
4. 未使用のJavaScriptやCSSファイルを削除する。
5. JavaScriptとCSSのファイルを結合して圧縮する。
6. box-shadowやfilterなどの高度なCSSプロパティを過度に使用しない。
7. スクリプトを後で実行するために、非同期、遅延、またはES modules（JavaScriptモジュール）を使用する。
8. 分析、SNSウィジェット、意見交換フォーラムなど、サードパーティからのJavaScriptリクエストは、すぐに数メガバイトまで膨れ上がる可能性があるため最小限に留める。
9. チャットウィジェットや動画再生など、必要に応じてJavaScriptコンポーネントを遅延読み込みする。
10. 分析、広告、SNSツールなど、重要度の低いスクリプトの読み込みを遅らせる。
11. 長時間実行されるJavaScript処理を一連の小さなジョブに分割し、短いrequestIdleCallback、setTimeout、requestAnimationFrameを遅延させた後に実行する。
12. バックグラウンドのスレッドを使用するウェブワーカーで、時間のかかるJavaScript処理を実行することを検討する。

Cumulative Layout Shift（CLS）

Cumulative Layout Shift（日本語で「累積レイアウトシフト」）は、ページの視覚的な安定性を測定するものです。特に最初の読み込み時に、どれだけページのコンテンツが意図せず動いたり、ずれたりするかを数値化します。

CLSは、警告やユーザーインタラクションなしにコンテンツが動く場合に計測されます。モバイル端末で記事を読んでいると、突然テキストが画面外にはみ出して、どのコンテンツを閲覧しているかわからなくなってしまった、という経験はありませんか？コンテンツのずれによって、誤ったリンクをクリックしてしまうというのは最悪の例です。

CLSの問題として、スクロール位置より上に大きな画像や広告が読み込まれ、急に数百ピクセルのずれが生じるといったこともあります。

CLSのスコアは、以下の指標を掛け合わせて算出されます。

• インパクト係数─ビューポート内のすべての不安定な要素、つまりずれる要素の総面積を示します。60％を占める要素がページの読み込み中にずれる場合、インパクト係数は0.6になります。また、ずれを引き起こした画像や広告などの要素は、レンダリング後に動かなくなる可能性があるため、「安定している」とみなされます。
• 距離係数─ビューポート内の単一の不安定な要素が移動した最大の距離を示します。例えば、最大の変位が0,100から0,800への移動である場合、縦700ピクセル分要素が移動したことになります。デバイスのビューポートの高さが1,000 pxの場合、距離の割合は700px / 1000px = 0.7となります。したがって、上記の例と掛け合わせると、この場合のCLSスコアは、0.6 x 0.7 = 0.42となります。

Googleは、以下のような状況に対する策としてCLSの指標を変更しています。

• コンテンツのずれ（レイアウトシフト）は5秒間の「セッション」にまとめられ、それ以上発生することがなければ1秒後に終了。1秒以内に2つ以上の要素が動いた場合は、そのスコアが加算される。
• レイアウトシフトは、クリックなどのユーザーインタラクションの後、500ミリ秒は記録されない。これがDOM更新のトリガーになることもある（メニューを開く、エラーメッセージを表示する、モーダルダイアログを表示するなど）。
• 長時間、開いた状態のままで、多くのDOM更新を行うシングルページのアプリケーションは、悪影響を受けない。

CLSスコアが0.1以下のページは、GOOD（緑）と判断されます。0.25を超えるページはPOOR（赤）と判断されます。

CLS解析ツール

CLSは、デベロッパーツールの「Lighthouse」パネル、PageSpeed Insights、web.dev Measureで測定できます。

また、Chromeの拡張機能Web Vitalsでも、CLSの指標を確認可能です。

LCPやFIDと同じように、Chrome User Experience Reportで、特定のURL、国、接続、デバイスで記録された実際の統計情報も確認できます。

同様に、web-vitals JavaScriptライブラリは、本番サイト上の実際のユーザーのCLS指標を計算可能です。以下のスクリプトをHTMLの<head>に追加して、コールバック関数に出力します。

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>

CLSのスコアが低下する主な原因

CLSのスコアは、ページアセットの読み込みが遅い、DOM要素が動的またはサイズ不足であることが原因で低下します。例えば以下の通りです。

• ページ上に、画像、iframe、広告に必要なスペースが確保されていない。
• コンテンツがDOMに動的に注入されている（典型的な例としては、広告やSNSウィジェットなどのネットワークリクエストの後）。
• ウェブフォントの読み込みが、FOIT（Flash of Invisible Text: テキストが一瞬表示されない）やFOUT（Flash of Unstyled Text: テキストが一瞬代替フォントで表示される）を引き起こしている。

CLSを改善する方法

クライアントサイドの監査で問題を特定できますが、一般的には、ダウンロード前に要素のスペースを確保しておくことが重要です。LCPのセクションで提案したサーバー最適化のヒントを取り入れれば、ある程度の改善が期待できますが、加えて以下のような対策も効果的です。

1. HTMLの<img>と<iframe> タグに幅と高さの属性を追加するか、CSSのaspect-ratioプロパティを使って、アセットのダウンロード前にページ上に適切なスペースを確保する。
2. 広告やウィジェットなど、読み込みの遅いサードパーティーのコンテンツを囲むコンテナ要素には、あらかじめ適切な寸法を設定する。
3. ページの上部に表示される画像やその他のアセットは、できるだけ早い段階でリクエストする（プリロードが効果的）。
4. ウェブフォントの使用を最小限に抑え、一般的に入手可能なOSフォントの採用を検討する。
5. ウェブフォントを読み込み、CSSのfont-displayをオプションまたはスワップに設定。類似サイズのフォールバックフォントを使用して、レイアウトのずれを最小限にする。
6. クリックなどの操作に対応する場合を除いて、ページ上部への要素の挿入は避ける。
7. 入力トリガーから500ミリ秒以内にユーザーインタラクションが完了するようにする。
8. CSSのtransformとopacityを使用して、アニメーションを最適化し、再レイアウトを行わない。
9. クリティカルCSSをインライン化する。ページ上部の<link>ブロックにクリティカルCSSを埋め込み、非同期でスタイルシートを読み込む。
10. ページの任意のサブツリーを特定できるCSSの新機能containment（封じ込め）の使用を検討する。これによって、特定のDOMコンテンツブロックをレンダリングする（またはしない）ことで、ブラウザが処理を最適化することができる。

まとめ

中には、何から何までGoogleの推奨に忠実に従うことに対して、憤りを感じている方もいるでしょう。しかし、Googeは今日大きな影響力を持っており、ちょっとした検索エンジンの更新が、ウェブベースの企業の生産性や収益性に悪影響を及ぼすことがあります。

GoogleのCore Web Vitalsは、飴と鞭でいうところの「飴」にあたります。質の低いモバイルUI、ポップアップ要素の多い肥大化したサイトよりも、最適化されて使いやすく、ダークパターン（ユーザーを騙す目的で設計されたUI）を排除したサイトの方が成功する確率が高くなるのは当然とも言えます。

Core Web Vitalsは、ユーザー体験を評価するための指標となり、重要な改善点を特定するのに役立ちます。改善すれば必ず収益がアップするというわけではありませんが、訪問者はより快適にサイトを閲覧することができるようになり、信頼性の向上につながります。

Core Web Vitalsの改善について、他にも何か対策やヒントをご存知ですか？以下のコメント欄でぜひお聞かせください。