Core Web Vitalsとは？LCP・INP・CLSの基準と改善方法を解説

Core Web Vitals（コアウェブバイタル）とは、ページの表示の速さ・操作への反応・見た目の安定を、実際の利用者のデータで測るGoogleの指標です。

検索順位に関わる要素のひとつですが、内容の良さより先には来ないため、利用者の不満が大きい場面から直すのが近道です。本記事では、LCP・INP・CLSの基準と確認方法、改善の進め方を解説します。

なお、表示速度の改善をどこから始めるか迷っている方は、カルテットコミュニケーションズのSEOコンサルティングの無料相談もご活用ください。

Search Consoleの状況を一緒に見ながら、広告の着地ページも含めて、直す順番を整理します。

Core Web Vitalsとは？LCP・INP・CLSの3つの指標

Core Web Vitalsは、読み込み・操作・見た目という、利用者がページで感じる3つの不満の場面に対応した指標です。

まずは、それぞれが何を測っていて、どこからが「良好」なのかを押さえておきましょう。

定義①｜実際の利用者の体験を測る指標

Core Web Vitalsは、Googleが「ウェブに関する主な指標（Web Vitals）」として示す指標のうち、すべてのページに当てはまる中心の3つです。

Google検索セントラルでは、次のように説明されています。

Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。

引用元：Google検索セントラル「Core Web Vitals と Google 検索の検索結果について」

ポイントは、検査用の機械ではなく、Chromeを使う実際の利用者のデータで測る点です。

このデータは「Chrome ユーザー エクスペリエンス レポート（CrUX）」として匿名で集められ、Search ConsoleやPageSpeed Insightsに表示されます。

指標の顔ぶれは見直されることがあり、web.dev「Web Vitals」では、安定版の指標は1年に1回より多くは変更しないと説明されています。

Core Web Vitalsは、利用者が実際に感じた待ち時間や不満を数値にしたものと考えましょう。

定義②｜LCPは読み込みの速さ

LCP（Largest Contentful Paint）は、画面に見えている範囲で最も大きい画像や文章のかたまりが表示されるまでの時間です。

記事ならアイキャッチ画像や最初の段落、トップページならメインビジュアルが、LCPの対象になりやすい要素です。

Search Consoleのヘルプでは、2.5秒以下が「良好」、4秒を超えると「低速」とされています。

ページを開き始めてからの時間なので、サーバーの応答やリダイレクトにかかった時間も含まれます。

なお、「LCP」だけで調べると液晶ポリマーなど別の意味の言葉も出てくるため、「LCP 改善」のように言葉を足して探すと便利です。

LCPは「メインの内容が見えるまでの時間」と覚えましょう。

定義③｜INPは操作への反応の速さ

INP（Interaction to Next Paint）は、クリック・タップ・キー入力をしてから、画面に次の表示が出るまでの時間を測る指標です。

ページを開いている間のすべての操作を見て、いちばん遅かった操作が代表値になります。

操作の多いページでは、50回ごとに最も遅い1回を除くなど、たまたま遅かった操作を外す決まりもあります。

INPは2024年3月12日に、それまでのFID（First Input Delay）に代わってCore Web Vitalsの指標になりました。

FIDは最初の操作の待ち時間だけを測っていましたが、INPは処理と表示までを含めて、すべての操作を見る点が違います。

良好は200ミリ秒以下で、500ミリ秒を超えると「低速」です。

スクロールやマウスを重ねるだけの動きは測られないため、操作のないまま離れた訪問ではINPの値が出ません。

INPは「押してから画面が反応するまでの時間」で、ページの使いやすさそのものを表します。

定義④｜CLSは見た目の安定

CLS（Cumulative Layout Shift）は、ページを見ている途中で文章やボタンが予期せず動く、レイアウトのずれの大きさを表す数値です。

単位は秒ではなく、ずれた範囲の広さと動いた距離をかけ合わせたスコアで、0に近いほど安定しています。

ずれが1秒未満の間隔で続くまとまり（最大5秒）ごとに合計し、最も大きいまとまりの値がCLSになります。

読もうとした文章が下に押し出される、押そうとしたボタンの位置が変わって別の場所を押してしまう、といった体験がこの数値に表れます。

良好は0.1以下で、0.25を超えると「低速」です。

一方、利用者がボタンを押した直後に起きる、操作に応じた表示の変化はずれとして数えない決まりになっています。

CLSは「読んでいる途中に画面が動かないか」を表す数値です。

定義⑤｜75パーセンタイルで合否を決める

Core Web Vitalsの判定は、1回の訪問ではなく、多くの訪問をまとめて行います。

基準になるのは75パーセンタイルで、訪問を速い順に並べたときに、75%の位置にあたる値です。

Core Web Vitals の準拠状況を評価するツールでは、3 つの Core Web Vitals 指標すべてで 75 パーセンタイルの推奨目標値を満たしている場合、ページは合格と見なされます。

引用元：web.dev「Web Vitals」

言い換えると、4回の訪問のうち3回以上が基準内に収まっていれば、その指標は「良好」になります。

モバイルとパソコンは分けて評価されるため、パソコンでは良好でも、スマートフォンでは低速ということもあります。

指標	良好	低速
LCP（読み込み）	2.5秒以下	4秒を超える
INP（操作への反応）	200ミリ秒以下	500ミリ秒を超える
CLS（見た目の安定）	0.1以下	0.25を超える

出典：Search Console ヘルプ「Core Web Vitals レポート」。良好と低速の間は「改善が必要」と表示されます。

速い訪問だけでなく、遅い側の訪問まで基準内に収めることが合格の条件です。

Core Web VitalsとSEOの関係｜順位への影響をどう考えるか

「Core Web Vitalsを良くすれば順位が上がるのか」は、担当者からよく受ける質問です。

Googleの公式の説明をもとに、どこまで期待してよいのかを整理します。

関係①｜ランキングで考慮される要素のひとつ

Googleは、Core Web Vitalsを、コアランキングシステムがランキングを決めるときに考慮する要素だと説明しています。

同じページでは、検索結果でのランキングを上げ、利用者に良い体験を届けるために、Core Web Vitalsの改善を強くすすめています。

一方で、ランキングの中でどれくらいの重みがあるのかは公開されていません。

そのため、「速くすれば順位が上がる」と決めつけず、利用者の不満を減らす施策として扱うのが現実的です。

Core Web Vitalsは、順位に関わる要素のひとつとして、利用者のために整えるものです。

関係②｜ページ エクスペリエンスの一部

Googleは、Core Web Vitalsを含む「ページ エクスペリエンス」全体を良くすることをすすめています。

ページ エクスペリエンスのドキュメントでは、自己評価の質問として、次のような項目が挙げられています。

ランキングに使われるのはCore Web Vitalsで、それ以外の要素は直接は順位を上げないものの、満足度を高めるので取り組む意味があるとされています。

また、単一の「ページ エクスペリエンス シグナル」はなく、さまざまなシグナルで評価されると説明されています。

Core Web Vitalsだけでなく、広告の量や見やすさも含めて体験全体を見直しましょう。

関係③｜内容の関連性が先に来る

順位の決まり方について、Googleは次のように説明しています。

Google 検索は、ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています。ただし多くの場合、検索語句に一致するヘルプフル コンテンツが多数存在するため、その中で検索結果でのランキングを上げるには、優れたページ エクスペリエンスを実現していることが重要になります。

引用元：Google検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」

つまり、検索した人の疑問に答えていないページは、どれだけ速くても上位には来にくいということです。

逆に、内容が同じくらい役立つページが並ぶテーマほど、体験の差が効いてきます。

弊社では、まず内容と検索意図の一致を整え、そのうえで「低速」のページの型を直す順番で進めます。

内容の改善を先に、Core Web Vitalsの改善をその後押しとして考えましょう。

関係④｜満点を目指さなくてよい

Core Web Vitalsのスコアについて、Googleは次のように注意を促しています。

Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。優れたページ エクスペリエンスには Core Web Vitals スコア以外の要素もあります。

このスコアは、サイトの全体的なユーザー エクスペリエンスの改善に役立てるためのものなので、SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。

引用元：Google検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」

よく混同されますが、PageSpeed Insightsの点数（パフォーマンス スコア）は試験環境での診断で、Core Web Vitalsの合否とは別のものです。

点数を90から100に上げる作業より、「低速」のページを「良好」にする作業のほうが、利用者にとっての意味は大きくなります。

目標は満点ではなく、3つの指標を「良好」に保つことです。

関係⑤｜広告の着地ページにも通じる

弊社は、リスティング広告などの運用型広告の運用代行を本業としています。

Google 広告の品質スコアでも、「ランディング ページの利便性」が3つの要素のひとつとされています。

これは、広告をクリックした人にとってページが関連性があり有用かを示すもので、表示の速さだけを測るものではありません。

それでも、広告費をかけて呼んだ人が表示を待てずに離れてしまえば、広告でもSEOでも同じ損失になります。

広告とSEOの役割分担は、リスティング広告とSEOを併用するメリットでも解説しています。

着地ページの作り方は、ランディングページはSEOも考慮しようもあわせてご覧ください。

広告の着地ページこそ、Core Web Vitalsを確かめておきたいページです。

Core Web Vitalsの確認方法｜Search ConsoleとPageSpeed Insights

Core Web Vitalsは、無料のツールだけで確かめられます。

サイト全体から1つのURL、さらに1つの要素へと、見る範囲を狭めながら使い分けるのがコツです。

確認①｜Search Consoleでサイト全体を見る

最初に開きたいのは、Search Consoleの[Core Web Vitals]レポートです。

モバイルとパソコンに分けて、「低速」「改善が必要」「良好」のURLの数がグラフで表示されます。

URLは、似た作りのページごとに「URLグループ」としてまとめられ、グループの中で最も悪い指標の状態がグループの状態になります。

たとえば、INPが良好でもCLSが低速なら、そのグループは「低速」と表示されます。

表の行を開くと、問題の種類ごとに、影響を受けているURLのサンプルを確かめられます。

ただし、表示されるのはインデックスに登録されたURLの一部で、すべてのURLを網羅したものではありません。

Search Consoleの基本的な使い方は、Google Search Consoleについてで紹介しています。

まずSearch Consoleで、どの型のページがどの指標で「低速」なのかをつかみましょう。

確認②｜PageSpeed Insightsで1つのURLを見る

PageSpeed Insightsは、URLを入れるだけで、そのページのCore Web Vitalsを調べられる無料のツールです。

結果の上段には実際の利用者の過去28日間のデータによる評価が、下段にはLighthouseで試験的に読み込んだ診断と改善案が表示されます。

上段では、3つの指標の75パーセンタイルがすべて良好なら、Core Web Vitalsの評価に「合格」と表示されます。

INPのデータが足りない場合は、LCPとCLSが良好なら合格になる、という決まりもあります。

下段のパフォーマンス スコアは、90以上が良好、50〜89が改善が必要、50未満が不良の目安です。

モバイルとパソコンの結果は切り替えて見られるので、スマートフォンの結果から確かめましょう。

PageSpeed Insightsは、上段で合否を、下段で原因の手がかりを読むツールです。

確認③｜利用者のデータと試験環境のデータの違い

利用者のデータ（フィールドデータ）は、さまざまな端末や通信環境で集めた過去の記録です。

試験環境のデータ（ラボデータ）は、決まった端末と通信条件で、その場で読み込んだ結果です。

そのため、2つの数値が食い違うことは珍しくなく、どちらかが間違っているわけではありません。

Lighthouseは操作をしないためINPを測れず、代わりにTBT（Total Blocking Time）が目安として表示されます。

項目	利用者のデータ	試験環境のデータ
集め方	Chromeの実際の利用者	決まった条件で読み込む
期間	過去28日間	その場の1回
INP	測れる	測れない（TBTで代用）
向いている用途	合否の判断	原因探し・修正の確認

出典：PageSpeed Insights「PageSpeed Insights について」、web.dev「Web Vitals」

合否は利用者のデータで判断し、試験環境のデータは原因探しに使いましょう。

確認④｜「データがありません」と出るとき

公開したばかりのサイトや訪問の少ないサイトでは、Search Consoleに「データがありません」と表示されることがあります。

これは、CrUXに十分な量の利用者のデータが集まっていないためです。

PageSpeed Insightsでは、URL単位のデータが足りないとき、サイト全体（オリジン）のデータに切り替えて表示されます。

オリジンのデータも足りない場合は利用者のデータは出ず、試験環境の診断だけが表示されます。

この場合は、Lighthouseの結果で大きな問題がないかを確かめ、訪問が増えてから利用者のデータで見直します。

データがないときは、試験環境の診断で目立つ問題だけを先に直しておきましょう。

確認⑤｜Chrome DevToolsで原因を探す

原因の特定には、Chromeの開発者ツール（Chrome DevTools）の[パフォーマンス]パネルが役立ちます。

ページを読み込みながら記録すると、LCPになった要素や長い処理、レイアウトのずれが起きた場所を確かめられます。

web.dev「LCP を最適化する」では、[パフォーマンス]パネルで手元の値と利用者のデータを並べて見られると説明されています。

社内に開発の担当者がいなければ、ここから先は制作会社に任せ、Search ConsoleとPageSpeed Insightsの結果を共有するだけでも十分です。

DevToolsは、どの画像や処理が遅いかを突き止める段階で使いましょう。

LCPの改善方法｜メインの画像を早く表示する

「LCP 改善」も月に140回ほど検索されていて、直し方を探している担当者が多いテーマです。

web.dev「LCP を最適化する」では、LCPの時間を4つの区間に分け、区間ごとに直す方法が示されています。

4つとは、最初の1バイトが届くまで（TTFB）、画像を取りに行き始めるまでの遅延、画像の読み込み時間、画面に表示するまでの遅延です。

LCP①｜LCPの要素を特定する

まず、どの要素がLCPになっているかを確かめます。

PageSpeed Insightsの診断や、Chrome DevToolsの[パフォーマンス]パネルで、LCPの要素を確かめられます。

多くのページではメインの画像ですが、見出しや段落など文章のかたまりがLCPになるページもあります。

要素が文章なら、画像の対策よりも、ウェブフォントやサーバーの応答を先に見るほうが近道です。

LCPの要素を特定してから、効く対策を選びましょう。

LCP②｜画像を早く見つけてもらう

LCPの画像は、ブラウザがHTMLを読んだ時点で見つけられるようにしておくことが大切です。

web.dev「Core Web Vitals 改善のための最も効果的な方法」では、data-srcのようにJavaScriptで差し込む書き方を避け、<img>のsrc属性やsrcset属性で読み込むことをすすめています。

あわせて、LCPの画像には fetchpriority=”high” を付けて優先度を上げ、loading=”lazy”（遅延読み込み）は外します。

<img src="hero.webp" width="1200" height="630"
     fetchpriority="high" alt="…">

※書き方の例です。ファイル名と数値は架空のものです。

遅延読み込みは画面の下のほうにある画像には有効ですが、最初に見える画像に付けると、かえって表示が遅れます。

最初に見える画像だけは、遅延読み込みを外して優先度を上げましょう。

LCP③｜画像を軽くする

画像のファイルが重いと、ダウンロードの時間が長くなります。

表示する大きさに合わせて画像を書き出し、WebPやAVIFのような軽い形式を使うと、読み込み時間を短くできます。

スマートフォン向けには、srcset属性で画面の幅に合った大きさの画像を出し分ける方法もあります。

ただしweb.devは、画像だけを軽くしても、時間がほかの区間に移るだけでLCPが変わらない場合があると注意しています。

画像の軽量化は、ほかの区間の遅れとあわせて直すと効果が出ます。

LCP④｜サーバーの応答を速くする

TTFBは、ページを開き始めてから、HTMLの最初の1バイトが届くまでの時間です。

ここが長いと、ほかをどれだけ直してもLCPを2.5秒以内に収めにくくなります。

web.devでは、TTFBが長くなる原因として、重なったリダイレクト、利用者から遠いサーバー、通信状況、URLのパラメータでキャッシュが使えないことなどを挙げています。

対策は、CDNで利用者に近い場所から配信する、キャッシュを使う、不要なリダイレクトをなくすことです。

WordPressなどのCMSは、ページを毎回組み立てる処理が重くなりやすいため、キャッシュの設定やサーバーの見直しが効く場合があります。

PageSpeed Insightsでは、TTFBは試験運用の指標として、800ミリ秒以下が良好の目安とされています。

サーバーの応答が遅いときは、画像より先にキャッシュとCDNを見直しましょう。

LCP⑤｜表示を止めるCSS・JavaScriptを減らす

画像が届いても、ほかのCSSやJavaScriptの処理が終わるまで、画面に表示されないことがあります。

これが「描画の遅延」で、最初に読み込む大きなCSSや、すぐに実行されるスクリプトが原因になりやすい部分です。

使っていないCSSを減らす、急がないスクリプトは後から読み込む（defer・async）などの方法で、表示を早められます。

広告や分析のタグも、増えるほど負担になるため、使っていないタグは定期的に外します。

画面の表示を待たせているCSSとスクリプトを洗い出して減らしましょう。

INPの改善方法｜操作への反応を速くする

「inp とは」は月に320回ほど検索されていて、FIDから切り替わった新しい指標として関心が集まっています。

web.devでは、INPは改善の余地が最も大きい指標のひとつと紹介されています。

1回の操作は、入力遅延・処理時間・表示の遅延の3つの区間に分けて考えます。

INP①｜遅い操作を見つける

INPは利用者の操作で決まるため、どの操作が遅いのかを見つけることから始めます。

Search ConsoleやPageSpeed Insightsでは、INPが悪いことはわかっても、どのボタンが原因かまではわかりません。

web.dev「INP を最適化する」では、利用者のデータを自社で集めて遅い操作を特定し、そのうえでラボで再現する流れをすすめています。

データの集め方としては、web-vitalsというJavaScriptのライブラリが紹介されています。

手元で試すなら、Chrome DevToolsの[パフォーマンス]パネルで、メニューの開閉やフォームの入力をしながら記録します。

まず、メニューや絞り込みなど、よく使われる操作から試しましょう。

INP②｜長いタスクを分割する

ブラウザは、メインスレッドという1本の道で、処理を順番にこなしています。

長い処理（長いタスク）が道をふさいでいると、利用者がタップしても、その処理が終わるまで反応できません。

web.devでは、長いタスクをこまめに区切って、操作への反応を先に行えるようにする方法（scheduler.yield() など）を紹介しています。

ボタンを押したときの処理も、画面の反応を先に返し、送信や集計などの重い処理を後に回すと、利用者の待ち時間が短くなります。

長い処理は区切って、画面の反応を先に返す作りにしましょう。

INP③｜不要なJavaScriptとタグを減らす

読み込むJavaScriptが多いほど、メインスレッドは混み合います。

web.devでは、タグマネージャーで使われなくなった古いタグを定期的に削除することもすすめています。

終わったキャンペーンの計測タグや、使っていないチャット・分析のツールは、担当者が気づかないまま残りがちです。

弊社では広告運用の立場から、広告の計測タグは成果の計測に必要なものだけを残し、重複したタグを整理するところから手をつけます。

タグマネージャーの中身を棚卸しし、使っていないタグを外しましょう。

INP④｜描画の負担を軽くする

処理が終わったあとも、画面を描き直す量が多いと、次の表示までに時間がかかります。

ページの要素（DOM）が多すぎると描き直しの負担が大きくなるため、不要な要素を減らします。

CSSのcontent-visibilityを使うと、画面の外にある部分の描画を後回しにでき、描き直しの量を抑えられます。

一覧ページで大量の商品や記事を一度に表示している場合は、ページを分けるなどの見直しも有効です。

1ページに詰め込みすぎた要素を減らすことが、INPの改善につながります。

CLSの改善方法｜レイアウトのずれを防ぐ

web.dev「CLS を最適化する」では、CLSの主な原因として、サイズのない画像、サイズのない広告・埋め込み・iframe、あとから差し込まれるコンテンツ、ウェブフォントを挙げています。

どれも、あとから入るものの場所が決まっていないことが共通の原因です。

CLS①｜画像と動画にサイズを指定する

画像や動画のタグにwidth属性とheight属性を書くと、ブラウザは読み込む前に必要な場所を空けておけます。

CSSで幅を100%にしていても、heightをautoにしておけば、縦横の比率を保ったまま縮むので、スマートフォンでもずれません。

画像以外の要素には、CSSのaspect-ratioで縦横の比率を指定する方法もあります。

CMSで入れた画像でも、テーマやプラグインの作りによっては属性が付かないことがあるため、ページのソースで確かめます。

すべての画像と動画に、widthとheightを書きましょう。

CLS②｜広告・埋め込みの場所を確保する

広告の枠や動画の埋め込み、地図や予約フォームのiframeは、読み込んだあとに大きさが決まることがあります。

web.devでは、あらかじめ場所を確保し、正確な大きさがわからないときもmin-heightで最低限の高さを取っておくことをすすめています。

広告が表示されなかったときに枠ごと消す作りだと、その分だけ下の内容が動くため、枠は残しておくほうが安全です。

広告や埋め込みは、読み込む前に枠の高さを決めておきましょう。

CLS③｜あとから差し込む表示を上に出さない

Cookieの同意バナーやキャンペーンのお知らせ帯を、読み込み後にページの上部へ差し込むと、本文全体が下に押し下げられます。

web.devでは、利用者の操作なしに新しいコンテンツを差し込まないことや、読み込みの遅い内容は画面の下のほうに置くことをすすめています。

お知らせを出したいときは、最初から場所を確保するか、画面の下に固定して本文に重ねる形にすると、ずれが起きにくくなります。

読み込み後に上部へ差し込むバナーは、場所を確保するか重ねる形に変えましょう。

CLS④｜ウェブフォントのずれを抑える

ウェブフォントを使うと、最初に別のフォントで表示され、切り替わった瞬間に文字の幅が変わって行がずれることがあります。

web.devも、ウェブフォントをCLSのよくある原因のひとつに挙げています。

使うフォントの数と太さを絞る、重要なフォントは早めに読み込むなどの方法で、切り替わりのずれを小さくできます。

日本語のフォントはファイルが大きくなりやすいため、本当に必要かどうかから見直す価値があります。

ウェブフォントは数を絞り、切り替わりでずれないかを確かめましょう。

CLS⑤｜アニメーションはtransformで動かす

要素のtopやleftを動かすアニメーションは、ほかの要素を押していなくても、レイアウトのずれとして数えられることがあります。

web.devでは、代わりにtransform（translateX・translateY）で動かすことをすすめています。

スライダーやアコーディオンを自作している場合は、どのプロパティで動かしているかを制作会社に確かめると安心です。

また、戻る・進むでページを一瞬で表示するバックフォワード キャッシュ（bfcache）の対象にすると、戻ったときのずれもなくせるとされています。

動きのある部品は、transformで動かす作りになっているかを確かめましょう。

Core Web Vitalsの改善の進め方｜優先順位と検証

すべてのページを一度に直そうとすると、時間も費用もかかります。

Search Consoleのレポートを起点に、影響の大きいところから順番に進めましょう。

進め方①｜「低速」から直す

どこから直すかについて、Search Consoleのヘルプでは次のようにすすめています。

まず、「低速」とラベル付けされたものをすべて修正し、その後、大多数の URL に影響を与える問題、または重要な URL に影響を与える問題に対処することをおすすめします。

引用元：Search Console ヘルプ「Core Web Vitals レポート」

「改善が必要」のURLは改善の余地があるものの、「低速」に比べると重要度は下がると説明されています。

弊社では、これに加えて、問い合わせや購入につながるページ、広告の着地ページを含むグループを先に見ます。

「低速」のうち、成果につながるページを含むグループから手をつけましょう。

進め方②｜URLグループからテンプレートを特定する

URLグループは似た作りのページの集まりで、同じ原因を抱えている可能性が高いとされています。

記事・商品・一覧のように、テンプレート（型）ごとに直すと、1回の修正で多くのURLがまとめて改善します。

グループの中のURLは表示回数の多い順に並ぶため、上から順に直すのが効率的です。

サンプルのURLをPageSpeed Insightsで調べ、どの指標が、どの要素で悪いのかを書き出しておきます。

1ページずつではなく、テンプレート単位で原因を探しましょう。

進め方③｜制作会社・開発会社への依頼のしかた

社内で直せない場合は、制作会社や開発会社に依頼します。

そのとき「ページを速くしてほしい」とだけ伝えると、何をどこまで直すかがあいまいになります。

Search Consoleのレポートには共有ボタンがあり、問題の詳細ページだけを、プロパティを操作する権限を渡さずに共有できます。

社内に担当者がいない場合は、カルテットコミュニケーションズのSEOコンサルティングで、レポートの読み解きから依頼内容の整理までお手伝いします。

依頼するときは、指標・端末・テンプレート・サンプルURLをそろえて伝えましょう。

進め方④｜直したら28日間の検証で確かめる

修正が終わったら、Search Consoleの問題の詳細ページで[トラッキングを開始]を押します。

すると28日間のモニタリングが始まり、その間にどのURLでも問題が起きなければ、問題は解決したと判断されます。

このボタンは再インデックスなどをGoogleに頼むものではなく、利用者のデータの見守りを始めるだけのものです。

利用者のデータは過去28日間の記録なので、直した直後はまだ数値が変わらないことも覚えておきましょう。

その間は、PageSpeed InsightsやDevToolsで、修正が効いているかを試験環境で確かめておきます。

直したら[トラッキングを開始]を押し、28日間は利用者のデータの変化を待ちましょう。

進め方⑤｜改善後も月に1回は見る

Core Web Vitalsは、一度直せば終わりではありません。

新しいプラグインや計測タグ、大きな画像の追加など、サイトの更新で数値は簡単に悪くなります。

Search Consoleのヘルプでも、サイトを変えていないのに状態が変わる例として、アクセスの急増や画像を配信するサービスの遅れなどが挙げられています。

月に1回はレポートを開き、境目の近くにあるグループが「改善が必要」や「低速」に移っていないかを確かめます。

サイト全体の見直しの進め方は、中小企業のホームページ改善の具体策でも紹介しています。

月に1回、Search Consoleのレポートを見る習慣をつけましょう。

まとめ｜Core Web Vitalsは利用者の不満を減らすための指標

Core Web Vitalsは、点数を競うためのものではなく、利用者が待たされる・押し間違えるといった不満を減らすための指標です。

内容を磨いたうえで、Search Consoleの「低速」から順に直していけば、SEOにも広告の成果にも良い土台ができます。

どこから手をつけるべきか判断に迷う場合は、カルテットコミュニケーションズのSEOコンサルティングにご相談ください。

レポートの読み方から制作会社への依頼内容まで、広告運用の視点も交えて一緒に整理します。