Core Web Vitals 101 & 開発ガイダンス
公開: 2021-04-01何が起きて変化しているのか?
2021 年 5 月、Google は、ページの速度とユーザー エクスペリエンスに関連するページ ランキングのシグナルに追加の要素を追加するコア アルゴリズムの更新のロールアウトを開始しました。 コア アップデートのロールアウトは 2021 年 6 月まで延長され、これは史上最大のコア変更の 1 つになりました。 Core Web Vitals は、HTTPS で安全なサイト、モバイル フレンドリー、邪魔にならないインタースティシャルなどの古いランキング シグナルに加えて、全体的なページ エクスペリエンスのランキング要素の検索シグナルとなります。
Core Web Vitals の 3 つのコンポーネントには、次のものが含まれます。
- Largest Contentful Paint (LCP) : 知覚される読み込み速度を測定し、ページのメイン コンテンツが読み込まれた可能性が高いページ読み込みタイムラインのポイントをマークします。 優れたユーザー エクスペリエンスを提供するために、サイトは、ページの読み込みが開始されてから最初の 2.5 秒以内に LCP が発生するように努める必要があります。
- 最初の入力遅延 (FID) : 応答性を測定し、ユーザーが最初にページを操作しようとしたときに感じるエクスペリエンスを定量化します。 優れたユーザー エクスペリエンスを提供するために、サイトはFID を 100 ミリ秒未満にするよう努める必要があります。
- Cumulative Layout Shift (CLS) : 視覚的な安定性を測定し、表示されるページ コンテンツの予期しないレイアウト シフトの量を定量化します。 優れたユーザー エクスペリエンスを提供するために、サイトはCLS スコアが 0.1 未満になるように努力する必要があります。
このアルゴリズムの更新に関する Google の公式リリース ステートメント: https://developers.google.com/search/blog/2020/11/timing-for-page-experience
さらに、Google はロールアウト中のパフォーマンスを監視し続けたため、CLS の変更に関する詳細情報をリリースしました。 その結果、最近の変更により、多くのサイトがより良いスコアを獲得し、サイトのレイアウトを調整するための多くの開発作業を回避できました. いつものように、これらの変更は変更される可能性があるため、毎週または毎月のチェックリストの一部として CWV を監視することをお勧めします。
ランキングの更新について私たちは何を知っていますか?
ほとんどの Google アルゴリズムの更新と同様に、現在の検索環境にどのように影響するかについては不明な点がたくさんあります。 これがページランキングの要因になることはわかっています. ただし、要因の何パーセント、またはアルゴリズム内での影響力がどの程度になるかはわかりません。 別の未知の要因は、直接の競合他社が新しい要因に準拠するためにサイトを更新する際に適応または行動を起こすかどうかです. 競合他社の行動に基づいて、これらの競合他社と比較して、サイトのランキングにプラスまたはマイナスの影響を与える可能性があります. 私たちが知っていることは、Google は引き続き、脆弱なコンテンツを含む高速な Web サイトよりも、ユーザーにとって価値がある、またはユーザーにとって関連性があると見なすコンテンツのランク付けを優先するということです。
実際、Google はこの更新についてより多くの情報を提供しており、関連コンテンツが検索ランキングの最も重要な要素の 1 つであることを確認しています。
「当社のシステムは、ページ エクスペリエンスのいくつかの側面が平均以下であっても、全体的に最良の情報を含むページを引き続き優先します。 優れたページ エクスペリエンスは、優れた関連性の高いコンテンツを上書きするものではありません。」
Google ページ エクスペリエンス ランキングの更新に備えるには?
この更新と Google の 6 か月の通知ウィンドウに関連する未知の要因により、この変更は、これがランキング要因になることを示しているように見えます。 したがって、SEO チームと開発チームの両方がサイトの現在の Core Web Vitals のパフォーマンスを確認し、ランキング シグナルの更新に関連する問題を確認して更新するために迅速に対応することを強くお勧めします。 ランキングの低下は回復するのにかなりの時間がかかる可能性があるため、受け身ではなく積極的に行動することが重要です。 SEOが長いゲームであることは誰もが知っています!
サイトの問題を特定する方法、問題と追加のヒントに基づく次のステップ?
Core Web Vitals は、サイトの Google Search Console アカウントの [Enhancements] の下に概説されています。 さらに、アカウントの [概要] セクション内に全体的な外観があり、以下の例のようになります (アカウントはサイト固有の潜在的な問題に依存するため、差異が生じる可能性があります)。 デスクトップとモバイルの両方について概説されているセクションもあります。 この例では、モバイル関連の問題を検討しています。
2020 年 9 月の時点ですべてのサイトがモバイル ファーストでインデックス登録されているため、最初にモバイルの問題に開発時間を費やすことをお勧めします。 そうは言っても、サイトがレスポンシブである場合、モバイルで行った更新はデスクトップにもプラスの影響を与える可能性があります. さらに、サイトの規模によっては、「質の悪い」問題や「改善が必要」な問題が発生する場合があります。 「改善が必要」な項目は、努力と影響、または 80/20 ルールに見合う価値がない可能性があるため、「質の低い」URL に注目することを強くお勧めします。これについては後で詳しく説明します。
Google Search Console で概説されている、最適なパフォーマンスとは言えない URL を確認するときは、 Google の John Muellerが、場合によっては Google が複数のページの平均としてコア ウェブ バイタル スコアを計算する方法について明らかにしたことを覚えておくことが重要です。
これは質問です:
「これがランキングシグナルになると…ページレベルになるのかドメインレベルになるのか?」
ミュラーは次のように答えました。
「…フィールド データで何が起こるかというと、すべてのページにデータ ポイントがないということです。
そのため、ほとんどの場合、個々のページをグループ化する必要があります。
そして、私たちが持っているデータの量に応じて、それはウェブサイト全体 (ドメインの種類) のグループになる可能性があります。
…Chrome ユーザー エクスペリエンス レポートでは、サブドメインであるオリジンとそこでのプロトコルを使用していると思います。
つまり、それは一種の包括的な種類のグループ化になります。
そして、ウェブサイトの個々の部分についてより多くのデータがある場合は、それを使用しようとします.
これは、1 つの URL のように表示される検索コンソールでも見られるもので、それに関連する他のページが非常に多くあると思います。 そして、それが私たちがそこで使用するグループ化のようなものです。」
Core Web Vitals に関する会話の冒頭で、なぜこれを持ち出すのかと自問するかもしれません。 Mueller 氏は、URL の問題をまとめた Google Search Console レポートは、同じ問題のあるページをグループに分類して報告しようとしていると説明しています。 残念ながら、実際には、これらの URL のグループ化は、私たちの経験から、一部の Web サイトではあまり役に立ちませんでした。
ときどき、Google Search Console レポートでパフォーマンスが「悪い」と示されている URL を確認しますが、Lighthouse と Page Speed Insights でテストしたところ、まったく同じページが正常な状態にあるように見えます。
要約すると、Google Search Console レポートで概説されている URL の問題を確認するときは、「大まかに考える」ことをお勧めします。 私たちの推測では、Google は、実際の実際の閲覧データ (Google で言えば「フィールド データ」) の 28 日間の履歴に基づいて、ページの「ウェブ バイタル」スコアをランク付けするつもりです。 ただし、ページのトラフィックがそれほど多くない場合、実際のデータはドメイン全体 (または Google で言えば「オリジン」) から集計される可能性があります。 Search Console は、Web Vitals に TLC が必要であることを特定するのに役立ちますが、監査のために Search Console に依存しないでください。 また、修正を実行および監査または検証する際には、フィールド データ (複数のページの可能性があり、常に 28 日間のルックバック ウィンドウを超える) ではなく、ラボ データ (リアルタイムでテストされたページの個々の結果) を確認するように注意してください。
問題があることがわかった後、ソース ページを特定できない場合は、各コア テンプレートのサンプル ページをラボでテストすることから始めます。 たとえば、ホームページ、製品ページ、カテゴリ ページ、ブログ記事などです。多くの場合、特定のページ タイプのすべてのインスタンスで構造上の問題が見つかり、Web 開発者が基になるテンプレートを更新することで一度修正されます。コード。 これでうまくいかない場合は、最も頻繁にアクセスされるページから始めて、個々のページのサブセットの同様の分析を検討してください。 このプロセスで役立つツールは、Screaming Frog を介して Core Web Vitals を監査することです。
Cumulative Layout Shift (CLS) 改善ガイダンス
累積レイアウト シフト (CLS)は、ページの存続期間全体で発生する予期しないレイアウト シフトごとに、すべての個々のレイアウト シフト スコアの合計を測定します。 レイアウト シフトは、レンダリングされたフレーム間で可視要素の位置が変わるたびに発生します。
Google では、いくつかの指針に従うことでほとんどの Web サイトの CLS を改善する方法について、次のガイダンスを推奨しています。
- 画像や動画要素には常にサイズ属性を含めるか、 CSS アスペクト比ボックスなどで必要なスペースを確保してください。 このアプローチにより、ブラウザは、画像の読み込み中にドキュメントに適切な量のスペースを割り当てることができます。 unsized-media 機能ポリシーを使用して、機能ポリシーをサポートするブラウザーでこの動作を強制することもできます。
- ユーザーの操作に応じる場合を除き、既存のコンテンツの上にコンテンツを挿入しないでください。 これにより、発生するレイアウト シフトが確実に想定されます。
- レイアウトの変更をトリガーするプロパティのアニメーションよりも、変換アニメーションを優先します。 状態から状態へのコンテキストと連続性を提供する方法で遷移をアニメーション化します。
Google では、次の一連のアクションを利用して、サイト全体で更新を分析、テスト、展開することをお勧めします。
- 作業が必要なページ (上記の概要) を特定したら、 PageSpeed Insightsを使用して、ページのラボおよびフィールドの問題を診断します。
- ラボでローカルにサイトを最適化する準備はできましたか? LighthouseとChrome DevToolsを使用して Core Web Vitals を測定し、正確に何を修正すべきかに関する実用的なガイダンスを取得します。 Web VitalsのChrome 拡張機能を使用すると、デスクトップでメトリックをリアルタイムで表示できます。
- ガイダンスをお探しですか? web.dev/measureはページを測定し、PSI データを使用して、最適化のためのガイドとコードラボの優先順位を示します。
- 最後に、本番環境に変更をデプロイする前に、プル リクエストでLighthouse CIを使用して、Core Web Vitals に回帰がないことを確認します。
CLS を改善する方法の詳細については、CLS の最適化を参照してください。
最大のコンテンツ ペイント (LCP) 改善ガイダンス
Largest Contentful Paint (LCP)メトリクスは、ビューポート内に表示される最大の画像またはテキスト ブロックのレンダリング時間を報告します。
Largest Contentful Paint APIで現在指定されているように、 Largest Contentful Paintと見なされる要素のタイプは次のとおりです。
- <img>要素
- < svg>要素内の<image>要素
- <video>要素 (ポスター画像を使用)
- url()関数を介してロードされた背景画像を持つ要素( CSS グラデーションとは対照的に)
- テキスト ノードまたは他のインライン レベルのテキスト要素の子を含むブロック レベルの要素
Google は、主に 4 つの要因によって影響を受ける LCP を改善する方法について、次のガイダンスを推奨しています。
- サーバーの応答時間が遅い
- レンダリングをブロックする JavaScript と CSS
- リソースの読み込み時間
- クライアント側のレンダリング
LCP を改善する方法の詳細については、LCP の最適化を参照してください。 LCP も改善できる個々のパフォーマンス手法に関する追加のガイダンスについては、以下を参照してください。
- PRPL パターンでインスタント ロードを適用する
- クリティカル レンダリング パスの最適化
- CSS を最適化する
- 画像を最適化する
- Web フォントの最適化
JavaScript を最適化する(クライアント レンダリング サイト用)
これまでの開発のコア Web 重要な調査結果
私たちの開発チームは、Core Web Vitals ランキングの更新の多くが、行われる更新が Google によって設定された基準を満たしていることを確認するために、開発側で広範なテストを必要とすることを認識しています。
小規模なサイトの多くの場合、これらの項目の多くは Web 開発者の制御を超えています。 たとえば、サーバーの速度は主にホスティング プロバイダーによって制御され、共有ホスティング (WP Engine や Shopify など) の場合、開発者は制御できません。 同様に、すぐに使用できるサイト テーマには、多くの場合、レンダリングをブロックする Javascript と CSS が「組み込まれています」。 このような場合、報告された問題の多くに対処することは現実的ではない可能性があります。 これらの理由から、(1) どの問題が最も影響力があり、(2) 開発チームが変更でき、また変更すべきコードが原因でどの問題が発生しているかを判断するには、重要な分析が必要です。
いくつかのクライアントで Core Web Vitals の問題を確認するプロセスを開始した後、問題 (コンテンツの負荷の変化など) を特定できる限り、Google が提供する関連ツールの多くは未熟なままであることがわかりました。特定の原因を特定するのに常に役立ちます。 これは、このツール (特に Chrome 開発ツール) の今後のイテレーションで成熟すると予想されますが、特定の問題を特定するには別の診断プロセスが必要になる可能性があることがわかりました。
また、これらの指標を改善するために取り組むことは、ページ速度のパフォーマンス全体を改善することと本質的に似ていることもわかりました. いずれの場合も、「完璧なスコア」を追求しないことをお勧めします。 代わりに、80/20 ルールが適用されます。 簡単に達成できる問題に対処すれば、指標が大幅に改善される可能性があります。 その後、改善にはより多くの時間と費用がかかり、影響が少なくなります。
すべての画像、動画、およびコンテナー要素にスペースを保持するマークアップまたは CSS を含めるという Google の提案などの基本的なガイダンスは、一般的に実装が簡単な適切なアドバイスです。 その他の問題は追跡がより困難であり、メトリクスに過度の影響を与えていない限り (推奨されるツールの一部で報告されているように)、それらの問題を脇に置いておくのが最善の場合があります。
サイト アーキテクチャも、これらの項目への対処を比較的容易にする上で重要な役割を果たします。 Shopify や WordPress などの人気のあるサイト プラットフォームは、WP Bakery や Shogun などのグラフィカル ページ ビルダーとともに、HTML 生成プロセスの一部を「舞台裏」で処理します。 ページ ビルダー コンポーネントによって隠されている問題 (たとえば、特定の画像の遅延読み込み) は、サイトに根本的な変更を加えるか、プラットフォーム、テーマ、またはプラグイン/アプリ ベンダーのサポートなしでは、すぐに対処できない場合があります。
上記の概念は、javascript を使用してウィジェットをページに遅延読み込みするサード パーティにも適用されます (たとえば、Klaviyo などの電子メール プラットフォームからの埋め込みサインアップ フォーム)。 場合によっては、問題のあるコンポーネントの埋め込みコードの周りに適切かつ明示的にサイズ設定されたコンテナー要素を配置することが実行可能な解決策です。 それ以外の場合は、ベンダー自身が変更を加える必要がある場合があります。
簡単にアクセスできるコア サイト テンプレート (製品ページ、製品コレクション ページなど) を変更することで対処できる、影響の大きい問題から修復プロセスを開始することをお勧めします。 これにより、多くの場合、コードを 1 回変更するだけで、数十または数百のサイト ページの結果を改善できます。 次に、ほとんどの場合、サイトで最も頻繁にアクセスされるページであるため、ホームページに対処します。 最後に、問題の重大度とページの可視性に基づいて、修正が必要な他の個々のページに優先順位を付けます。
ページ速度の改善の場合と同様に、Core Web Vitals の管理は重要ですが、これは Google のランキング アルゴリズムの多くの変数の 1 つにすぎず、SEO は、時間と予算を競う他のサイトやビジネスの優先事項とバランスを取る必要もあります。