Core Web Vitalsとは?

簡単な回答:Core Web Vitalsとは、Googleが定める3つの指標、Largest Contentful Paint(LCP)、Interaction to Next Paint(INP)、Cumulative Layout Shift(CLS)のことで、ページが実際の訪問者にとってどれだけ速く、反応が良く、視覚的に安定していると感じられるかを測定します。GoogleはこれらをページエクスペリエンスのランキングシグナルJの一部として使用しており、動作が遅く不安定なページは検索での露出もトライアル登録も失うため、SaaSのマーケティングサイトにとって重要です。実際のユーザーによる訪問の75%以上が3つの指標すべてで「良好」と評価されると、そのページは合格となります。

Googleは、ページが実際に快適に使えるかどうかという、これまで主観的だった点を数値化するためにCore Web Vitalsを導入しました。G2やCapterra、そして潤沢な資金を持つ多数の競合とオーガニックでの露出を競うSaaSチームにとって、技術的なパフォーマンスはもはやバックオフィスだけの問題ではありません。検索順位や直帰率、そして見込み顧客がデモを予約する前に自社製品に寄せる信頼に、直接表れるからです。

Core Web Vitalsの3つの指標とは?

Core Web Vitalsは、ページの読み込みパフォーマンス、インタラクティブ性、視覚的な安定性について、実際のユーザー体験を測定する指標群です。各指標は訪問者の体験における異なる場面を対象としており、それぞれに独自の合否基準があります。

Largest Contentful Paint(LCP)

Largest Contentful Paintは、読み込みパフォーマンスを測定します。良好なユーザー体験を提供するには、ページの読み込み開始から2.5秒以内にLCPが発生することを目指しましょう。SaaSのマーケティングサイトでは、最大の要素は通常、ヒーロー画像、製品のスクリーンショット、または大きな見出しです。最適化されていない画像、遅いサーバー、レンダリングをブロックするスクリプトなど、その描画を遅らせるものがあると、LCPは「改善が必要」または「不良」の領域に入ってしまいます。

Interaction to Next Paint(INP)

Interaction To Next Paintは、応答性を測定します。良好なユーザー体験を提供するには、INPを200ミリ秒未満にすることを目指しましょう。INPは3つの指標のなかで最も新しいものです。INPは2024年3月にFirst Input Delay(FID)を完全に置き換えたため、今もFIDを挙げているガイドは情報が古いといえます。最初のクリックやタップしか捉えなかったFIDとは異なり、INPはページ上のすべてのインタラクションの遅延を評価するため、応答性の指標としてはるかに厳格で実態に即しています。チャットウィジェットや料金シミュレーター、インタラクティブなデモを多数搭載したSaaSサイトでは、これらの要素がすべてINPのスコアに影響するため、この点は重要です。

Cumulative Layout Shift(CLS)

Cumulative Layout Shiftは、視覚的な安定性を測定します。良好なユーザー体験を提供するには、CLSのスコアを0.1未満にすることを目指しましょう。CLSが悪化するのは、サイズ指定のない画像が読み込まれたとき、Cookieバナーやサードパーティの埋め込みコンテンツが初期描画の後にコンテンツを挿入したとき、あるいはWebフォントが差し替わってページが再配置されたときなどです。チャットウィジェットの読み込みで料金表がずれるといった大きなレイアウトシフトが1回起きるだけで、そのセッション全体のスコアが悪化することもあります。

Core Web VitalsはGoogleの検索順位にどう影響しますか?

単一のシグナルというものはありません。当社のコアランキングシステムは、ページエクスペリエンス全体に関わるさまざまなシグナルを見ています。ランキングシステムは、その評価の一部としてCore Web Vitalsを使用します。実際には、Core Web Vitalsは決め手というより、同点の場合の判断材料として機能します。Core Web Vitalsはランキング要因ではありますが、検索エンジン最適化において関連性の高いコンテンツを作ることがもちろん最も重要であり、Googleはコンテンツの品質が同程度のページ同士で、Core Web Vitalsを「タイブレーカー」として使うことがあります。

この違いは、SaaSチームが時間の使い方に優先順位をつけるうえで重要です。非常に高速でも内容が薄く役に立たないページは、検索者の疑問により的確に答える、少し遅いページに負けてしまいます。しかし、同じ比較キーワードで2社が同程度の深さのコンテンツを公開した場合、通常はより速く安定したページのほうが上位を獲得します。これはまさに、SeedlingがSaaSのコンテンツチームの特定を支援する利点です。関連性で競えるだけの強いコンテンツが、わずかな差で順位を落とさない技術基盤の上に置かれている状態を指します。

ビジネス上のメリットは、検索順位にとどまりません。Googleが数百万件のページインプレッションを対象に行った最近の調査では、Core Web Vitalsの基準を満たしているサイトは、ページの完全な読み込み前に離脱される可能性が24%低いことがわかりました。有料と自然検索の両方のトラフィックを同じランディングページに流しているSaaSサイトでは、この離脱率の差が、そのまま無駄な広告費と失われたパイプラインにつながります。

Core Web Vitalsはどのように測定されますか?

Googleは2種類のデータをはっきり区別しており、この2つを混同することはテクニカルSEOで最もよくある間違いのひとつです。

フィールドデータは、ランキングに関係するデータです。Googleは、過去28日間にChromeブラウザーでアプリケーションにアクセスした実際のユーザーの75パーセンタイルにあたる、グローバルなフィールドデータを収集しています。このデータはChrome User Experience Report(CrUX)に保存され、Google Search ConsoleのCore Web Vitalsレポートに表示されます。

PageSpeed InsightsやLighthouseなどのツールが出力するラボデータは、デバッグには役立ちますが、ランキングを決定するものではありません。Lighthouseのスコアは、Googleのランキングに直接影響しません。ラボテストでパフォーマンスのスコアが低かったからといって、実際のユーザーによるCore Web Vitalsのデータでも成績が悪いとは限りません。ラボデータが実際のユーザーデータと大きく異なることはよくあります。

Googleは、合否の基準を平均値ではなく、特定のパーセンタイルに設定しています。Core Web Vitalsに合格するには、GoogleのCrUXデータセットでURL単位に見て、訪問者の75%以上がLCP、INP、CLSのすべてで「良好」のスコアになる必要があります。光回線につないだ高性能なノートパソコンで高速に表示されるだけでは不十分で、4人に1人の最も遅い環境にいるユーザー、つまり通信が不安定なモバイル回線で中程度のスマートフォンを使っている人にとっても速くなければなりません。この設計原則ひとつで、社内のQAチェックには合格するのに、Search Consoleでは「不良」と表示されるSaaSのマーケティングサイトが多い理由が説明できます。

SaaSサイトのCore Web Vitalsを悪化させるよくある間違いとは?

SaaSのマーケティングサイトがCore Web Vitalsで不合格になるパターンは、ECサイトやメディアサイトとは異なります。その主な理由は、マーケティングチームが利用しているツールの構成にあります。

• サードパーティ製ウィジェットの使いすぎ。チャットツール、プロダクトツアー用ソフトウェア、マーケティングオートメーションのスクリプトはメインスレッドをブロックし、INPを悪化させます。それぞれが、ページ上のあらゆるインタラクションに測定可能な遅延を加えます。
• マーケティングページへのダッシュボードや製品の埋め込み。ホームページのヒーローセクションの目玉であることが多いライブの製品プレビューは、静止画や動画よりも読み込みが遅いため、LCPを悪化させる最大の原因になりがちです。
• Cookieや同意取得のモーダル。これらは描画サイクルの終盤に挿入されるため、GDPRや同様の同意要件のもとで運営されるB2BサイトでCLSが不合格になる主な原因です。
• ホームページだけをテストする。ホームページは通常は合格します。CWVの問題が実際に集中するのは、アクセスの多いブログ記事、比較ページ、有料広告用のランディングページであり、これらはオーガニックと有料の両方でトラフィックの大部分を担うページでもあります。
• フィールドデータよりラボのスコアを信頼する。Lighthouseのスコアが緑色でも、それは誤った安心感につながります。Googleがページエクスペリエンスの評価に実際に使用しているのは、CrUXのフィールドデータだけです。

Core Web Vitalsを改善するには?

LCPの改善は、通常、最も取り組みやすい成果です。ヒーロー画像をWebPまたはAVIFに変換し、幅と高さの属性を明示的に指定し、重要なアセットをプリロードし、必須でないスクリプトは読み込みを遅延させます。INPの改善はより難しく、多くの場合、JavaScriptのアーキテクチャの見直し、長いタスクの分割、サードパーティ製ウィジェットの遅延読み込み、最初のインタラクションに不要なものすべての遅延読み込みが必要になります。CLSは、画像、広告、埋め込みコンテンツのすべてに読み込み前からスペースを確保し、font-display swapを使ってテキストの再配置を防ぐことで解決できます。

本当に成果を左右するのは、ひとつの修正ではありません。CrUXまたは実ユーザーモニタリングツールのフィールドデータを、コンテンツやトラフィックの指標がある同じダッシュボードに集約することです。そうすれば、CrUXがデフォルトで使う28日間のローリングウィンドウを待たず、数日で悪化に気づけます。すでにSeedlingでコンテンツ制作を管理し、オーガニックでの露出を追跡しているSaaSチームなら、そのワークフローにCore Web Vitalsのモニターを組み合わせることで、公開したものと、実際の訪問者が実際のデバイスでページを読み込んだときの成果との間のループを閉じることができます。

Googleが現場で「良い体験」の定義を磨き続けるにつれ、Core Web Vitalsも進化し続けます。これを継続的な取り組みではなく、一度きりの監査として扱うことは、最初の修正を終えてからずっと後になって、SaaSサイトの順位とコンバージョンを静かに押し下げる間違いです。