SEOと開発者のためのコアウェブバイタル

この記事はAhrefs公式ブログの日本語訳です。
原文：Core Web Vitals For SEOs & Developers
（著者：Patrick Stox, Michal Pecánek, Joshua Hardwick / 原文の最終更新日：June 18, 2023）
※フルスピード註：この記事は2023年6月18日時点の記載をもとに翻訳しています。Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。

コアウェブバイタルは、ユーザーエクスペリエンスを測定するために使用されるGoogleのページエクスペリエンスシグナルの一部である速度メトリクスです。この指標は、Largest Contentful Paint（LCP）で視覚的負荷を、Cumulative Layout Shift（CLS）で視覚的安定性を、First Input Delay（FID）でインタラクティブ性を測定します。このデータは、Chromeユーザーエクスペリエンスレポート（CrUX）から得られたものです。

2021年5月以降、モバイルページエクスペリエンスとコアウェブバイタルメトリクスが公式にランキングに影響を与える要因として導入されました。2022年2月からは、デスクトップシグナルもランキングに使用されるようになりました。

各カテゴリーの基準は以下の通り：

	良好	改善が必要	不良
LCP	2.5秒未満	4秒以下	4秒を超える
FID	100mミリ秒未満	300ミリ秒以下	300ミリ秒を超える
CLS	0.1未満	0.25以下	0.25を超える

各Core Web Vitalの詳細と、あなたのページを合格させる方法を見てみましょう。

• 最大コンテンツの描画（LCP）
• 累積レイアウトシフト（CLS）
• 初回入力遅延（FID）
• コアウェブ・バイタルの測定方法
• コアウェブ・バイタルはSEOにとって重要か？
• コアウェブ・バイタルの概要

最大コンテンツの描画（LCP）

LCPは、ビューポートにロードされる単一の最大の可視要素である。

出典：web.dev

最も大きな要素は通常、フィーチャー画像か<h1>タグでしょう。しかし、これらのどれかになる可能性もあります：

• <img>要素
• <svg>要素内の<image>要素
• <video>要素内の画像
• url()関数で読み込んだ背景画像
• テキストのブロック

<svg>と<video>は将来追加されるかもしれません。

LCPエレメントの見方

PageSpeed Insightsでは、LCP要素は「診断」セクションで指定されます。また、LCPに関連する問題のみを表示するタブがあることに注意してください。

Chrome検証ツールで、以下の手順に従ってください：

1. パフォーマンス > スクリーンショットにチェック
2. 「プロファイリングを開始してページを再読み込み」をクリックする。
3. LCPがタイミンググラフに表示
4. ノードをクリックする。

PageSpeed Insightsで見たように、LCPに関する問題は多いです。このため、LCPは最も改善しにくい指標となっています。私たちは、Largest Contentful Paintの記事で問題を修正する方法を含め、より多くの詳細をカバーしています。

累積レイアウトシフト（CLS）

CLSは、要素の動きやページの安定性を評価する指標です。コンテンツのサイズや移動距離を考慮しています。グーグルはCLSの測定方法をアップデートしており、以前はページが読み込まれた後も測定が続けられていましたが、現在は最も移動が発生する5秒間に制限されています。

出典：web.dev

ページ内で何かをクリックしようとした際に、意図しない場所をクリックしてしまい、イライラする経験をしたことはありませんか？私もよくあります。たとえば、特定のリンクをクリックしようとしたら、広告をクリックしてしまったり、ウェブサイト内での位置が変わってしまい、戸惑うことがあります。ユーザーとしてはとても不便ですよね。

CLSの一般的な原因は次のようなものがあります：

• サイズの指定のない画像
• サイズの指定のない広告、埋め込みコンテンツ、iframe
• JavaScriptによるコンテンツの挿入
• ページの後半でフォントやスタイルを適用すること

CLSの見方

PageSpeed Insightsを使用して、CLSに関連する問題をチェックできます。特に注意すべきポイントは、「大きなレイアウトシフトを避ける」という点です。

WebPageTestを活用している場合、Filmstrip Viewでは以下のオプションを選択します：

• ハイライト・レイアウト・シフト
• サムネイルサイズ：巨大
• サムネイル間隔：0.1秒

この設定で、5.1秒から5.2秒の間にカスタムフォントが適用される際にどのようにレイアウトが変わり、フォントがどのようにリスタイリングされるかに注目してください。

スマッシング・マガジンはまた、レイアウトのずれがどこで発生しているかを特定するために、すべてを3pxの赤い実線でアウトライン表示し、ページ読み込みの過程を動画で記録するという興味深い手法も取られています。

CLSを最適化するには、通常、画像やフォント、場合によっては注入されたコンテンツに関する問題に取り組む必要があります。累積レイアウトシフトの記事で、問題を修正する方法を含め、より多くの詳細をカバーしています。

初回入力遅延（FID）

FIDとは、ユーザーがあなたのページとやり取りしてから、ページが反応するまでの時間を指します。反応性とも言えます。FIDは、2024年3月にInteraction to Next Paint (INP)という名前でコアウェブバイタルに置き換えられる予定です。

ユーザーとのやり取りの例：

• リンクやボタンをクリックする
• 空白のフィールドにテキストを入力する
• ドロップダウンメニューから選択する
• チェックボックスをクリックする

スクロールやズームなどの一部の動作はFIDには含まれません。

何かをクリックしてもページが反応しないのは、とてもイライラすることがあります。

出典：web.dev

全てのユーザーがページとやり取りするわけではないため、ページにはFIDの値が存在しないこともあります。これは、ラボテストツールがページとやり取りしないため、値がない理由の一つでもあります。ラボテストで表示されるのは、総ブロッキング時間（Total Blocking Time）などかもしれません。PageSpeed Insightsでは、TBTタブを使用して関連する問題を見ることができます。

遅延の原因は？

JavaScriptのメインスレッドは1つしかなく、JavaScriptはその上でタスクを競い合って実行されます。JavaScriptが交代で実行するようなものだと思ってください。

出典：web.dev

タスクが実行されている間、ページはユーザーの入力に反応することができません。これが遅延を感じる原因です。タスクが長いほど、ユーザーが遅延を感じる時間も長くなります。タスクとタスクの間の休憩時間は、ページがユーザーの入力に切り替わり、ユーザーがしたい操作に対応するチャンスです。

ほとんどのページはFIDの要件をクリアしています。ただし、FIDに問題がある場合は、First Input Delayの記事で、問題の修正方法など、詳細な情報を得ることができます。

コアウェブ・バイタルの測定方法

テストやモニタリングに使えるツールはたくさんあります。一般的には、測定したいのは実際のフィールドデータであるChrome User Experience Report（CrUX）の情報です。これは、実際のChromeユーザーから集めたデータで、データを共有することを選んだユーザーから得られます。このデータセットには、さまざまな方法でアクセスできます。

特に重要なのは、API経由でしか取得できないページレベルの数値です。これらは、ページに関する十分なデータがある場合にGoogleが利用する数値であり、データが不足している場合は、似たようなページのグループまたはドメイン全体の数値をスコアリングのために使用することもあります。ページレベルのデータを提供する他のツールは、直接的または間接的にこのソースから情報を取得します。

例えば、Google Search Consoleはデータを取り込んで、各カテゴリに属するURLの数を表示します。

問題の一つをクリックすると、影響を受けるページグループの内訳が表示されます。このページのグループ分けは非常に理にかなっている。というのも、コアウェブバイタルを改善するための変更のほとんどは、多くのページに影響を与える特定のページテンプレートに対して行われるからです。テンプレートに一度変更を加えれば、グループ内のページ全体で修正されます。

PageSpeed Insightsは、ページレベルのデータ、オリジンデータ、 Lighthouseから来るラボテストデータも取り込む 。ラボのデータについては、また後ほど紹介します。

PageSpeed Insightsは、一度に1つのページをチェックするには素晴らしいです。しかし、ラボデータとフィールドデータの両方を大規模に取得したい場合、最も簡単な方法はAPIを利用することです。 Ahrefsのウェブマスターツール（無料）やAhrefsのサイト監査で簡単に接続でき、パフォーマンスの詳細なレポートを得ることができる。

テストやモニタリングに使えるツールはたくさんあります。一般的には、実際のフィールドデータを見たいものです。しかし、テストにはラボのデータの方が役立ちます。

ラボデータとフィールドデータの違いは、前者は実際のユーザー、ネットワーク状況、デバイス、キャッシュなどを調べるものです。しかし、ラボのデータは、テスト結果の再現性を高めるために、同じ条件に基づいて一貫してテストされます。

これらのツールの多くは、ラボテストのベースとしてLighthouseを使用しています。ただし、WebPageTestは例外で、Lighthouseでもテストを実行できます。フィールドデータはCrUXによるものです。

表示されるコアウェブバイタルデータは、設定時にクロールに選択したユーザーエージェントによって決定されることに注意してください。モバイルからクロールした場合は、モバイルCWVの値が表示されます。

フィールドデータとラボデータ

フィールドデータとラボデータの違いは、前者は実際のユーザー、ネットワーク状況、デバイス、キャッシュなどを調べるものです。しかし、ラボのデータは、テスト結果の再現性を高めるために、同じ条件に基づいて一貫してテストされます。

CWVデータは28日間のローリング平均を示すため、ラボテストデータはテストに役立ちます。

独自のリアル・ユーザー・モニタリング（RUM）データを収集するために使用できる追加ツールがいくつかあります。これは、自社のユーザーからフィールドデータを収集することです。この種のデータは、ラボのテストに頼るよりも、スピードの改善が実際のユーザーにどのような影響を与えるかについて、より即時のフィードバックを提供することができます。

コアウェブ・バイタルはSEOにとって重要か？

ランキング要因は200以上あり、その多くはあまり重みを持ちません。コアウェブバイタルについて話すとき、Googleの担当者はこれらを小さなランキングファクター、あるいはタイブレーカーと呼んでいる。コアウェブバイタルの改善によるランキングの向上は、あったとしてもあまり期待できません。それでも、コアウェブバイタルは要因の一つであり、ジョン氏のこのツイートは、コアウェブバイタルを高めることがどのように機能するかを示している。

Think of it like this. Graphic not to scale. pic.twitter.com/6lLUYNM53A

— John Mueller (official) · #MaybeABot (@JohnMu) May 21, 2021

スピード指標をターゲットにしたランキングファクターは何年も前からありました。そのため、モバイルページエクスペリエンスのアップデートが実施された際に、目に見える影響があったとしても、あまり期待していませんでした。残念なことに、ページエクスペリエンスアップデートの期間中にグーグルのコアアップデートもいくつかあったため、影響を判断するのが面倒で結論が出なかったのです。

コアウェブバイタルの合格とランキングの向上との間に正の相関関係を見出した研究がいくつかありますが、個人的にはこれらの結果を懐疑的に見ています。SEOに力を入れているサイトは順位が上がる傾向があると言っているようなものです。コアウェブバイタルにすでに取り組んでいるサイトであれば、他の多くのことも正しく行っている可能性が高いでしょう。そして、私たちのデータ調査の下のグラフを見ればわかるように、人々は取り組んでいたのです。

コアウェブ・バイタルの概要

事実1： 指標はデスクトップとモバイルに分かれている。モバイルシグナルはモバイルランキングに使用され、デスクトップシグナルはデスクトップランキングに使用されます。

事実2： このデータは、Chromeユーザー・エクスペリエンス・レポート（CrUX）から得られたものです。測定基準は、ユーザーの75パーセンタイルで評価されます。つまり、70％のユーザーが 「良好」で、5％のユーザーが 「改善が必要」だったとしても、あなたのページは 「改善が必要」と判定されます。

事実3： 指標はページごとに評価される。しかし、十分なデータがない場合、Googleウェブマスタートレンドアナリストのジョン・ミューラーは、サイトのセクションまたはサイト全体からのシグナルが使用される可能性があると述べています。 私たちのコアウェブバイタルのデータ調査では、4,200万以上のページを調査し、11.4%のページしかメトリクスが関連付けられていないことがわかりました。

事実4： これらの新しい測定基準の追加に伴い、モバイルのトップストーリー機能からAMP（Accelerated Mobile Pages）が要件から外されました。新しいストーリーは実際にはスピードメトリクスのデータを持たないため、より大きなカテゴリのページ、あるいはドメイン全体のメトリクスが使用される可能性があります。

事実5 : シングル・ページ・アプリケーションは、ページ遷移を通じてFIDとLCPという2つのメトリクスを測定しない。App History APIや、Responsivenessと呼ばれるインタラクティブ性の測定に使用されるメトリクスの変更の可能性など、いくつかの変更案があります。

事実6： 測定基準は時間の経過とともに変化する可能性があり、しきい値も同様に変化する可能性があります。Googleはすでに数年にわたり、ツールで速度を測定するための指標を変更し、高速か否かの基準値も変更しています。

事実7： プロキシメトリクスや補足的なメトリクスとして機能する追加のウェブバイタルがありますが、ランキングの計算には使用されません。視覚的な負荷に関するウェブバイタルの指標には、Time to First Byte（TTFB）とFirst Contentful Paint（FCP）があります。インタラクティブ性の測定には、TBT（Total Blocking Time）とTTI（Time to Interactive）が役立ちます。

コアウェブバイタルはすでに変更されており、さらにメトリクスの変更案があります。ページサイズが追加されても驚きません。アセットに優先順位をつけることで、現在の指標をパスすることができますが、それでも非常に大きなページがあります。これはかなり大きなミスだと私は思います。

まとめ

コアウェブバイタルがSEOに大きな影響を与えるとは思いませんし、極端に遅くない限り、一般的に私はコアウェブバイタルの修正を優先することはないでしょう。コアウェブバイタルの改善を主張したいのであれば、それはSEOのためには難しいと思います。

しかし、ユーザーエクスペリエンスのためにそれを主張することはできます。あるいは、ページスピードの記事で述べたように、改善はアナリティクスでより多くのデータを記録するのに役立つはずです。また、より多くのコンバージョンを得ることができるかもしれません。このことを示す多くの研究があります（しかし、より多くのデータを記録した結果かもしれません）。

もう一つの重要なポイントは、開発者と協力することです。ページスピードは非常に複雑です。もしあなたが自分だけでやっているのであれば、プラグインやサービス（例えばWP RocketやAutoptimize）に頼る必要があるかもしれません。

新しいテクノロジーが導入され、CMSやCDN、あるいはブラウザのような多くのプラットフォームが最適化タスクの一部を担うようになれば、物事はより簡単になるでしょう。私の予想では、数年以内に、ほとんどの最適化はすでに処理されているので、ほとんどのサイトはあまり心配する必要もなくなるだと思います。

多くのプラットフォームは、すでにあなたの助けとなるものを既に展開しているか、取り組んでいます。

すでにWordPressは最初の画像をプリロードしており、Core Web Vitalsに取り組むチームを編成しています。Cloudflareはすでに、Early Hints、Signed Exchanges、HTTP/3など、サイトを高速化する多くのものを展開しています。サイトオーナーがこの作業を心配する必要さえなくなるまで、この傾向は続くと予想しています。

何か質問があれば、いつものようにツイッターでメッセージをください。