Core Web Vitalsとは？SEOへの影響と改善方法をわかりやすく解説【2026年版】

2026年11月6日

「Search Consoleに『改善が必要』と出た」「PageSpeed Insightsの点数が低い」。何から手を付けるか迷う方は多いはずです。

結論から言うと、Core Web Vitalsは読み込み・操作への反応・画面の安定性という3つの視点で、実際の利用者の体験を測る指標です。PageSpeed Insightsの点数を上げること自体が目的ではありません。大切なのは、どのページのどの指標に、何が原因で問題が起きているかを見つけ、原因に合う対策を選ぶことです。

本記事は2026年11月6日時点のGoogleとweb.devの公式情報をもとに、基準値、測定方法、WordPressとSWELLでの設定、改善の優先順位を説明します。SWELLの設定項目はAFFICAMPの管理画面で確認した範囲で、バージョンにより異なる場合があります。公式で確認できなかった点は、その旨を書きます。

1. Core Web Vitalsとは？表示速度との違い

1-1. 定義：3つの視点で体験を測る指標

web.devによると、Web Vitalsは、優れたユーザー体験に欠かせない品質シグナルの統一した指針を示す、Googleの取り組みです。Core Web Vitalsはその中で、すべてのウェブページに当てはまり、すべてのサイト運営者が測定すべき指標にあたります。

LCP（Largest Contentful Paint）：読み込みパフォーマンス
INP（Interaction to Next Paint）：操作への応答性
CLS（Cumulative Layout Shift）：視覚的な安定性

背景として、web.devは、運営者が専門家でなくても体験の質が分かるよう、指標を絞る狙いを説明しています。

1-2. ページ表示速度との違い

表示速度は、一般に読み込みの速さを指します。Core Web Vitalsには、読み込みに加えて操作への反応と画面の安定性が含まれます。読み込みが速くても、次のサイトは体験が良いとは限りません。

画面は早く出るが、ボタンを押しても反応しない（INPの問題）
読んでいる途中で画像や広告が割り込み、文章が下へ動く（CLSの問題）

指標は固定ではなく、web.devによると、FID（First Input Delay）は2024年3月12日にINPへ置き換わりました。古い解説にFIDの基準があっても、現在の指標ではありません。

2. 3つの指標：LCP・INP・CLS

2-1. LCP：メインコンテンツの表示が終わるまで

LCPは、ページを開いてから、画面内で最も大きい画像・テキストブロック・動画が描画されるまでの時間です。web.devによると、対象は<img>、動画のポスター画像、背景画像、テキストを含むブロック要素などです。

すべてのページでメインビジュアルがLCPになるとは限りません。 web.devの例では、Google検索結果ページのLCPは、画像より先に出た文章のブロックでした。ページごとに実際のLCP要素を確認することが、改善の出発点です。

web.devのガイドは、LCPを4つの区分に分けて考えるよう勧めています。

区分	内容	目安の割合
TTFB	HTML最初の1バイトを受け取るまで	約40%
読み込みの遅延	LCP画像の読み込みを始めるまで	10%未満
読み込み時間	LCP画像の転送	約40%
描画の遅延	読み込み後に表示されるまで	10%未満

割合は目安です。「遅延」の2つは小さくします。

2-2. INP：操作に画面が応えるまで

INPは、クリック、タップ、キー入力からブラウザが次に画面を更新するまでの時間を、ページ滞在中の全操作について見る指標です。ホバーやスクロールは対象外です。

FIDは最初の操作の入力遅延だけを見ていました。INPは、入力遅延、イベント処理、画面に反映されるまでの遅れを含め、全ての操作を見ます。

操作の遅れは、入力遅延、処理時間、表示の遅延の3つに分けられます。操作がないページでは、INPの値が出ないこともあります。PageSpeed Insightsのラボデータには、INPが直接表示されません。 ドキュメントが挙げるラボ指標にINPはなく、web.devも、読み込みだけを観察するツールはINPを報告しない場合があると説明しています。

2-3. CLS：画面が意図せず動く度合い

CLSは、ページ滞在中に起きた予期しないレイアウトのずれを数値にした、単位のない値です。0はずれなし、大きいほどずれが大きいことを表します。

読んでいる途中で画像や広告が出て文章が下へ動くと、位置を見失ったり、別のボタンを押したりします。web.devによると、操作から500ミリ秒以内のずれは、多くの場合CLSに含まれません。

2-4. 3指標の比較表

指標	正式名称	測定内容	良好	改善が必要	不良	主な悪化要因	代表的な対策
LCP	Largest Contentful Paint	最大要素の表示までの時間	2.5秒以下	2.5秒超〜4秒以下	4秒超	サーバー応答、大きな画像、描画を妨げるCSS・JS	画像の最適化、優先度の調整
INP	Interaction to Next Paint	操作から画面更新までの時間	200ミリ秒以下	200ミリ秒超〜500ミリ秒以下	500ミリ秒超	重いJS、長い処理、外部スクリプト	処理の分割、不要なスクリプトの削減
CLS	Cumulative Layout Shift	レイアウトのずれの大きさ	0.1以下	0.1超〜0.25以下	0.25超	サイズ未指定の画像、広告、埋め込み	領域の確保、width・height指定

「不良」はPageSpeed InsightsのPoorにあたり、Search Consoleのヘルプでは「低速」です。Google検索セントラルの日本語ページには「200ミリ秒未満」「0.1未満」とも書かれていますが、web.dev、PageSpeed Insights、Search Consoleヘルプは「以下」で、本記事は後者に従います。

2-5. 75パーセンタイルで評価する意味

Core Web Vitalsは、実際の利用者のアクセスを集計し、75パーセンタイルで評価します。100回のアクセスを良い順に並べたとき、75番目の値で判定するイメージです。

PageSpeed Insightsのドキュメントは、平均ではなくこの値を使う理由を、厳しい端末・通信環境でも多くの利用者に良い体験を届けるためと説明しています。モバイルとデスクトップは分けて見ます。3指標すべてが良好のとき、合格です。

3. Core Web VitalsはSEOに影響するのか

Google検索セントラルは、Core Web Vitalsを、ページエクスペリエンスの他の要素とともに、コアランキングシステムが考慮する要素と説明しています。改善は、検索結果での順位向上と、優れた体験のために推奨されています。

同時に、次の注意も書かれています（ページエクスペリエンスにはスコア以外の要素もあります）。

良い結果が出ても、上位表示は保証されない
SEO上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えない

検索語句に合うヘルプフルなコンテンツが多数ある場合、その中で順位を上げるには優れたページエクスペリエンスが重要になるとされています。一方で、Google検索は、ページエクスペリエンスが平均を下回るコンテンツも含め、最も関連性の高いコンテンツを表示するよう設計されているとも述べられています。

つまり、SEOでは有益なコンテンツが重要であり、Core Web Vitalsは、ユーザー体験を改善するための重要な要素の一つです。順位への影響の大きさを示す公式の数値は確認できていないため、本記事も数値化しません。コンテンツの質については、E-E-A-Tの解説記事をご覧ください。

検索結果での見え方には、ページ体験のほかに、構造化データなどの技術要素も関わります。詳しくは構造化データの解説記事をご覧ください。

4. ユーザー体験とビジネスへの影響

SEOとは別に、体験の悪化は利用者の行動に影響する可能性があります。読み込みが遅いと離れる、反応しないと何度も押す、画面がずれると別のリンクを押す、といったことです。問い合わせや購入のあるサイトでは、成果に関わります。

web.devのケーススタディ（ページ表示は2022年7月更新）に、ECサイトFarfetchの事例があります。同社の分析では、LCPが100ミリ秒遅くなるごとに、コンバージョン率が平均で約1.3%低下したと報告されています。商品ページでLCPを600ミリ秒以上短縮したA/Bテストでは、コンバージョン率が1〜5%の範囲で上昇したとあります。

これはFarfetch自社のデータと条件での結果で、ほかのサイトでの再現は保証されません。体験改善が成果に結び付く可能性を示す一例です。

5. Core Web Vitalsを測定する方法

測定では、実際の利用者のデータ（フィールドデータ）と、シミュレーション環境のデータ（ラボデータ）を区別します。フィールドデータは問題があるかの判断に、ラボデータは原因の調査と修正後の確認に向いています。

5-1. PageSpeed Insights

URLを入力して「分析」を押すと、モバイルとデスクトップの結果を切り替えて確認できる無料のツールです。画面は大きく2つの部分です。

実際のユーザー体験（フィールドデータ）：Chrome UX Report（CrUX）の、直近28日間の実利用の集計です。3指標の75パーセンタイル値と、良好・改善が必要・不良の分布が出ます
パフォーマンスの問題の診断（ラボデータ）：Lighthouseによるシミュレーションです

ドキュメントによると、次の点に注意が必要です。ラボとフィールドは条件が違うため、値が食い違うこともあります。

URL単位のデータが足りないと、サイト全体（オリジン）のデータが表示されます。サイト全体にも足りなければ、フィールドデータは出ません
100点満点のパフォーマンススコアはラボデータの結果で、90以上が良好、50〜89が改善が必要、50未満が不良です
スコアとCore Web Vitalsの評価は同じではありません。合格かどうかは、フィールドデータの3指標が75パーセンタイルで良好かで決まります

web.devは、食い違うときはCrUXのほうが実際の体験を正確に表している可能性が高いと説明しています。まずフィールドデータを見て、ラボデータは原因探しに使うのが基本です。

5-2. Search Console

サイト全体の傾向をつかむのに向いています。未導入の方はGoogleサーチコンソールの導入方法から始めてください。

レポート名は、ヘルプでは「Core Web Vitals レポート」で、日本語版の本文中には「ウェブに関する主な指標レポート」という表記もあります。画面の名称や配置は更新で変わることがあります。ヘルプの記載から、次のことが分かります。

モバイルとパソコンに分かれ、URLが低速・改善が必要・良好に分類される
類似するページをURLグループにまとめ、最も悪い指標に合わせて状態が決まる
修正後は「トラッキングを開始」で28日間のモニタリングが始まる（再インデックス登録などは行われない）
「低速」から優先し、影響の大きい問題や重要なURLを先に直す

すべてのURLが表示されるわけではありません。 表示されるのはインデックスに登録されたURLだけで、LCPとCLSの両方でデータが足りないURLはレポートから除外されます。このレポートはサイト全体の問題を調べるためのもので、PageSpeed Insightsの個別URLの値とは一致しないことがあります。

5-3. Chrome DevToolsとLighthouse

Lighthouse：読み込みをシミュレーションし、スコアと改善候補を出す（PageSpeed Insightsのラボデータも同じ仕組み）
Performanceパネル：操作や読み込みを記録して、LCP要素、重い処理、レイアウトのずれを調べる

INPは、実際に画面を操作しながら記録して調べます。手元のパソコンは利用者の端末より高性能なことが多いため、実機のスマートフォンでの確認も欠かせません。

5-4. 測定ツールの比較表

ツール	主な用途	データ	確認できる内容	初心者向け	使う場面
PageSpeed Insights	ページ単位の診断	フィールド・ラボ	3指標、スコア、改善候補	向いている	特定ページの確認
Search Console	サイト全体の把握	フィールド	URLグループの状態	向いている	問題ページ群の発見、経過確認
Lighthouse	診断・スコア	ラボ	スコア、改善候補、TBT	普通	修正前後の確認
Chrome DevTools	原因の調査	ラボ	LCP要素、長い処理、ずれ	慣れが必要	原因が不明なとき

6. 指標ごとの悪化原因と改善方法

6-1. LCPが悪化する原因と改善

web.devは、LCPは一箇所を直すだけで大きく改善するのは珍しく、読み込みの流れ全体の見直しが必要と説明しています。主な原因は、サーバー応答の遅れ、大きな画像、LCP画像の読み込み開始の遅れ、描画を妨げるCSS・JS、重い外部リソース、LCP画像の遅延読み込みです。

優先度と遅延読み込み：web.devは、LCP画像をloading="lazy"で遅延読み込みしないよう明記しています。

<!-- LCPと思われる画像（高優先度は1〜2枚まで） -->
<img src="hero.webp" width="1200" height="630" alt="説明文" fetchpriority="high">
<!-- ファーストビューの下の画像 -->
<img src="photo.webp" width="800" height="450" alt="説明文" loading="lazy">

fetchpriority="high"は、ブラウザに優先して読み込んでほしいと伝える属性です。web.devは、指定する画像は1〜2枚までとし、多く指定すると効果がなくなると述べています。loading="lazy"は、画面の外にある画像の読み込みを後回しにする属性です。

画像のサイズと形式：サイズを小さくすれば転送時間は縮み、WebPとAVIFは従来形式より一般に圧縮が優れます。ただし、軽くすればLCPが必ず改善するとは限りません。web.devの例では、画像が軽くなっても、JavaScriptの完了まで隠されていたため、時間が「描画の遅延」に移っただけでした。4つの区分のどこに時間がかかっているかを確認してから対策を選びます。

描画を妨げるCSS・JS：大きなCSSや、<head>内の同期スクリプト（async・deferなし）は描画を遅らせます。web.devは、未使用CSSの削除や、同期スクリプトを避けることを案内しています。

6-2. INPが悪化する原因と改善

主な原因は、メインスレッド（ブラウザが処理と描画を担当する場所）が長い処理でふさがることです。

重いJavaScript、長時間続く処理、操作時の複雑なイベント処理
外部スクリプト（広告、チャット、計測タグ、外部ウィジェットなど）や、スライダー・アニメーション
大量のDOM要素（ページ内の要素の多さ）

JavaScriptがあること自体が問題なのではなく、操作の場面で長い処理が走り、画面更新を待たせることが問題です。

改善の方向性は次のとおりです。1〜3はweb.devのINPガイドの内容、4は一般的な対策です。

長い処理を分割し、ブラウザが画面更新に回れるようにする
画面更新に必要な処理を先に行い、残りを後に回す
DOMを小さく保つ
使っていないスクリプトやプラグイン、外部スクリプトを見直す

TBTとの関係：LighthouseのTotal Blocking Time（TBT）は、読み込み中に、50ミリ秒を超える長いタスクの超過分を合計した指標です。web.devは、TBTはINPの診断を助けるが代わりにはならず、利用者の操作を考慮しないと説明しています。両者は同じ指標ではないため、実際の操作で確かめます。

6-3. CLSが悪化する原因と改善

web.devが挙げる主な原因は、寸法のない画像・広告・埋め込み・iframe、後から挿入されるコンテンツ（バナー、フォームなど）、Webフォントの入れ替わり、レイアウトが変わるアニメーションです。

画像と動画には、widthとheightの指定か、CSSのaspect-ratioで領域を確保します。

<img src="photo.webp" width="800" height="450" alt="説明文">

/* 16:9の領域を先に確保 */
.embed-wrap { aspect-ratio: 16 / 9; }

広告やYouTubeなどの埋め込みは、読み込み後の大きさが事前に分からないことがあります。min-heightやaspect-ratioで表示領域を先に確保します。広告が返らなくても領域を閉じると、ずれの原因になります。

Webフォントでは、font-display: optional、フォールバックフォントの指定、size-adjustでの差の縮小などが案内されています。アニメーションは、topやleftの変化がずれの原因になるため、transformを使います。

6-4. 3指標と改善方法の対応表

症状・原因	指標	確認方法	改善の例
メインビジュアルの表示が遅い	LCP	LCP要素の確認	画像の最適化、LCP画像を遅延させない
サーバー応答や描画前のCSS・JSが重い	LCP	TTFB、Lighthouse	キャッシュ・サーバー・不要分の見直し
ボタンや外部ウィジェットの反応が遅い	INP	操作して記録	長い処理の分割、外部スクリプトの見直し
画像の表示で文章がずれる	CLS	レイアウトシフトの確認	`width`・`height`の指定
広告・埋め込みでずれる	CLS	実機での目視	表示領域の確保

7. WordPressで実践する高速化対策

7-1. 画像を最適化する

画像はLCPとCLSの両方に関わります。極端に大きい画像を避ける、圧縮してWebPなどを検討する、使っていない大容量画像を整理する、ファーストビューの画像は遅延させずその下にloading="lazy"を使う、width・heightを指定する、の順で確認します。

画像最適化プラグインは作業を助けますが、導入だけで画像の問題は解決しません。SWELL公式マニュアルには、EWWW Image Optimizerで画像をアップロードできなくなる不具合に遭遇したとあり、必要なときだけ有効にする使い方が書かれています。導入前にバックアップを取ってください。記事投稿の基本はSWELLの記事投稿マニュアルにあります。

7-2. キャッシュの種類と違い

キャッシュは、作った結果を保存して処理を省く仕組みです。

種類	保存場所	役割
ブラウザキャッシュ	訪問者の端末	再訪問時に画像やCSSを再利用
ページキャッシュ	サーバー	作成済みのHTMLを返し、処理を省く
サーバー側のキャッシュ	サーバー	サーバーの機能で応答を速める
CDN	各地の配信拠点	利用者に近い場所から配信
テーマ独自のキャッシュ	テーマの仕組み	SWELLのように部品の出力を保存

web.devは、効率的なキャッシュ方針があれば再訪問者には保存済みのリソースが使われること、CDNでリソースの移動距離を縮められることを説明しています。キャッシュは重ねるほど速くなるわけではありません。 役割が重なると、変更が反映されない、表示が崩れるなどの原因になります。

7-3. プラグインとサーバーを見直す

不要なプラグインの整理、使っていない機能の停止、似た機能の重複と外部スクリプトの確認が基本です。数だけで速度は決まりません。 少数でも重いものもあるため、読み込まれるCSS・JavaScriptやデータベース処理の負荷で判断します。停止はバックアップ後に1つずつ行い、表示と操作を確認します。

サーバーは、まずTTFB（最初のHTMLを受け取るまでの時間）を確認します。web.devは、TTFBが高いとLCPを2.5秒以内にするのが難しく、不可能にもなり得ると説明し、0.8秒以下を目安、1.8秒超を不良としています。ただしTTFBはCore Web Vitalsの指標ではなく、LCPなどを妨げなければ必須ではないとも述べています。そのほか、PHPのバージョン（更新前に対応を確認し、バックアップを取る）、サーバー側のキャッシュ、CDNの要否を確認します。サーバーを変えるだけで3指標すべてが改善すると断定はできません。 主因がTTFBでなければ、別の対策が必要です。

8. SWELLで実践する高速化対策

基本設定はSWELL導入後の初期設定の記事が参考になります。以下の項目名は、AFFICAMPの管理画面の「SWELL設定」ページで2026年11月6日に確認した範囲と、SWELL公式マニュアルの記載にもとづきます。SWELLを導入するだけで必ず高速化するわけではありません。

「高速化」タブには、キャッシュ機能、ファイルの読み込み、遅延読み込み機能、スクリプトの遅延読み込み、ページ遷移高速化があります。

8-1. キャッシュ機能

動的なCSS、ヘッダー、サイドバー、トップページコンテンツ、ブログカードなど、部品ごとの項目があります。

SWELL公式マニュアルによると、このキャッシュはブラウザではなくデータベースに保存されます（Transients API）。注意点は次のとおりです。

有効にすると、ログイン中でもトップページの投稿リストに非公開記事が表示されなくなる
変更が反映されないときは、「設定」の「SWELL設定」内のキャッシュクリアボタンで削除できる（マニュアルの記載。AFFICAMPの画面では位置を確認していません）
項目によっては、画面に「ウィジェットのページ分岐は効かなくなります」と注記がある

マニュアルには全てオンを勧める記載がありますが、1項目ずつ変えて表示を確認するのが安全です。

8-2. ファイルの読み込み（CSS）

「ファイルの読み込み」には、「SWELLのCSSをインラインで読み込む」「コンテンツに合わせて必要なCSSだけを読み込む」「フッター付近のCSSを遅延読み込みさせる」があります。注記によると、2つ目は使われている機能やブロックを読み取り、不要なCSSをできる限り読み込まないようにする設定で、3つ目は1つ目がオンのときは効果がありません。効果と表示崩れの有無は、変更ごとに確認してください。

8-3. 画像・コンテンツの遅延読み込み

「遅延読み込み機能」には、「記事下コンテンツ」「フッター」を遅延させる項目と、「画像等のLazyload」があります。Lazyloadは「使用しない」「loading=”lazy”を使用する」「スクリプト（lazysizes.js）を使って遅延読み込みさせる」から選びます。

特に注意したいのは、LCPになる画像を遅延させないことです。web.devはLCP画像のlazy-loadを避けるよう明記し、JavaScriptのライブラリでsrcが隠れると、ブラウザが画像を早く見つけられなくなるとも説明しています。SWELLがファーストビューの画像を自動で除外するかは、公式マニュアルでも確認できていません。設定後にLCP要素を調べ、遅延されていないか、不具合がないかをPCとスマホで確かめてください。

8-4. スクリプトの遅延読み込み

指定したキーワードを含むscriptタグを後から読み込む機能です。対象キーワード、オフにするページ、遅らせる秒数（0〜15秒）を設定します。SWELL公式マニュアルは、全てのスクリプトを遅延させるべきではなく、動かなくなることもあるため、自己判断・自己責任で設定するよう明記しています。

必要性が低く重いもの（SNS埋め込みなど）から検討する
計測タグや広告は、動作と計測への影響を確かめてから
問題が出るページは除外ページの設定で外す
遅延は処理を後ろへずらすだけで、減らすわけではない。INPへの影響は実際の操作で確認する

8-5. ページ遷移高速化

「使用しない」「Prefetch」「Pjaxによる遷移（非推奨）」から選びます。マニュアルによると、これはページ間の遷移を速くする機能で、最初の表示は速くならず、スクリプトが増えることもあります。Core Web Vitalsの改善を目的に選ぶ機能ではありません。

8-6. 高速化プラグインとの併用

SWELL公式マニュアルは、テーマ内の機能を優先し、重複する機能のプラグインは逆にパフォーマンスを悪化させるおそれがあると説明しています。例として、Flying Scripts、Autoptimize、Async JavaScript、画像の遅延読み込みプラグイン、Jetpackの画像遅延読み込み（SWELLと両方オンで不具合）、WP Super CacheやW3 Total Cacheなどのキャッシュ系（知識がないまま導入しない）が挙がっています。同じ機能を二重にオンにしないことが基本です。

8-7. 安全な設定変更の手順

バックアップを取る
現在のスコアを記録する（PageSpeed Insights、Search Console）
設定を1つずつ変える（原因を切り分けるため）
PCとスマートフォンで確認する
表示崩れや操作不良を確認する（メニュー、フォーム、埋め込み）
問題があれば元に戻す
再測定する

9. 改善を進める流れ（説明用の架空例）

仮想のWordPressサイトでLCPが課題だったときの進め方です。状況は説明用のシミュレーションで、実際の測定結果ではありません。

STEP 1 計測：トップページをPageSpeed Insightsで測定する
STEP 2 問題の指標：モバイルのLCPが「改善が必要」だったとする
STEP 3 原因の特定：LCP要素がメインビジュアル画像で、読み込み時間の区分が長いと分かったとする
STEP 4 改善策：画像の寸法と容量を見直す。LCP画像が遅延されていないかも確認する
STEP 5 設定の変更：バックアップ後、画像を差し替える。変更は1つずつ
STEP 6 再計測：ラボデータで、時間のかかっていた区分が変わったか見る
STEP 7 Search Console：トラッキングを開始し、28日間の経過を見る

ラボデータが改善しても、フィールドデータにすぐ反映されるとは限りません。 フィールドデータは直近28日間の集計で、利用者の端末や通信にも左右されます。

10. 改善の優先順位

優先順位はサイトの問題によって変わります。実際に課題のある指標を優先してください。

第1段階：測定と特定。Search Consoleで問題を確認し、PageSpeed Insightsで対象ページを調べ、指標を特定する
第2段階：取り組みやすい改善。大容量画像の最適化、画像サイズの指定、不要なスクリプトの整理、キャッシュ設定の確認、プラグインの見直し
第3段階：技術的な改善。JavaScriptの最適化、LCP画像の優先度調整、描画を妨げるリソースへの対処、サーバー側の最適化、レイアウト構造の改善

11. WordPress高速化チェックリスト

測定

□ Search Consoleで問題のURLグループを確認した
□ PageSpeed Insightsでフィールドデータの3指標を確認した
□ LCP要素を確認した

画像

□ 大きすぎる画像がない
□ 画像を圧縮した
□ ファーストビューの画像を遅延読み込みしていない
□ 画像にwidth・heightを指定した

キャッシュ・サーバー

□ TTFBを確認した
□ PHPのバージョンを確認した
□ キャッシュの機能が重複していない

JavaScript・プラグイン

□ 使っていないプラグインを整理した
□ 外部スクリプトを整理した
□ スクリプト遅延後、フォームやメニューの動作と反応を確認した

レイアウト・記録

□ 広告・埋め込みの領域を確保した
□ スマホ実機でずれがないことを確認した
□ 変更前後のスコアを記録した

12. よくある質問

Core Web Vitalsとは何ですか？

読み込み（LCP）、操作への反応（INP）、画面の安定性（CLS）で、実際の利用者の体験を測る指標です。

Core Web VitalsはSEOに影響しますか？

コアランキングシステムが考慮する要素の一つですが、上位表示は保証されません。有益なコンテンツが重要です。

PageSpeed Insightsは何点以上を目指すべきですか？

一律の目標点は公式に示されていません。90以上が良好の区分ですが、まずフィールドデータを見てください。

Core Web Vitalsとページ表示速度の違いは？

表示速度は読み込みの速さが中心です。Core Web Vitalsは操作への反応と画面の安定性も含みます。

LCP・INP・CLSとは何ですか？

最大要素の表示（LCP）、操作への反応（INP）、レイアウトのずれ（CLS）です。詳しくは2章をご覧ください。

FIDは現在も使用されていますか？

使用されていません。2024年3月12日にINPへ置き換わりました。

WordPressでもCore Web Vitalsを改善できますか？

できる場合が多いです。ただし原因はサイトごとに違うため、原因の特定が先です。

SWELLは表示速度が速いテーマですか？

高速化の機能があります。ただし速さは画像、プラグイン、サーバーなどにも左右され、導入だけで必ず高速化するとは言えません。

Core Web Vitalsの評価はどこで確認できますか？

PageSpeed InsightsとSearch Consoleで確認できます。

スコアを改善すれば検索順位は上がりますか？

公式には保証されていません。体験改善の取り組みとして行ってください。

Search Consoleでデータが表示されない場合は？

アクセスが少ない、または新しいサイトでは、データが足りないことがあります。その間はラボデータと実機を使います。

改善した結果はいつ反映されますか？

フィールドデータは直近28日間の集計で、Search Consoleの検証も28日間です。数日で判断しないでください。

13. まとめ

基準は、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下（75パーセンタイル）
SEOでは有益なコンテンツが重要で、Core Web Vitalsは体験を改善するための重要な要素の一つ
点数ではなく、フィールドデータで問題を見つけ、原因に合う対策を選ぶ
SWELLの設定は、バックアップを取り、1つずつ変えて確認する

WordPressサイトの表示速度の改善、SEOを意識したWebサイトの見直し、SWELLの設定でお困りの方は、ご相談ください。AFFICAMPは、WordPressを活用したホームページ制作、ブログ制作、SEOを意識したWebサイト設計を行っています。

AFFICAMPへのお問い合わせはこちら

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

構造化データとは？SEO初心者でも分かる役割と設定方法を解説