Webaff

公開 更新 文責 Webaff 編集部

広告表示がCore Web Vitalsへ与える影響の測り方

  • AdSense
  • SEO
  • Core Web Vitals

広告を追加すると収益機会は増えますが、広告スクリプトの読み込み、表示領域の変化、メインスレッドの処理などがページ体験に影響する可能性があります。ただし、広告導入後に数値が悪化しただけでは、広告が原因とは断定できません。記事内容、アクセス端末、通信環境、季節要因なども変化するためです。

広告導入前後のCore Web Vitalsと収益指標を同じ条件で記録し、変更を一つずつ試すことが重要です。ここでは、PageSpeed InsightsとSearch Consoleを使い、LCP、CLS、INPへの影響を確認する手順を整理します。

当サイトで測れているのは「広告なし」の側だけ（2026-09 追記）

この記事は広告の前後比較が主題ですが、当サイトにはまだ後半（広告あり）がありません。2026年9月にAdSenseを申請して「有用性の低いコンテンツ」で否認され、広告スクリプトも空の広告枠もHTMLへ出力していないためです（AdSense審査で「有用性の低いコンテンツ」と判定された原因の記録）。

そのため当サイトの立場では、この記事は承認前に基準値を取っておくための手順です。いまできるのは次の範囲です。

できること できないこと
広告なしの状態でLCP・CLS・INPを記録する 広告あり・なしの差を測る
フォントやスクリプトなど自前の要素を減らす 広告枠の高さ確定によるCLSを測る
記録した基準値を承認後の比較に使う ページRPMと速度を突き合わせる

なお広告以外の転送量削減は先に着手していて、日本語フォントを52リクエスト553KiBから3リクエスト約400KiBに減らしました（日本語Webフォントを自己ホストして転送量を削る手順）。広告を入れる前に自前の要素を軽くしておくと、あとで差を読みやすくなります。

広告表示で確認したい3つの指標

Core Web Vitalsでは、主に次の指標を確認します。

指標 確認する内容 広告による影響の例
LCP ページ内の主要コンテンツが表示されるまでの時間 広告スクリプトや画像の読み込みが主要コンテンツと競合する
CLS ページ表示中に発生する予期しないレイアウトのずれ 広告枠の高さが後から確定し、本文が移動する
INP ユーザー操作に対する応答性 広告関連のJavaScript処理がメインスレッドを長く占有する

Googleが案内する「良好」の目安は、LCPが2.5秒以下、CLSが0.1以下、INPが200ミリ秒以下です。実際のユーザーデータでは、ページ読み込みの75パーセンタイルで評価されます。基準の詳細はweb.devのCore Web Vitals解説で確認できます。

これらは合否だけを見るのではなく、広告導入前からどの程度変化したかを確認します。たとえば、良好の範囲内であってもCLSが継続的に増えているなら、広告枠の確保方法を見直す余地があります。

測定前に比較条件をそろえる

導入前後の比較では、対象ページと測定条件を固定します。トップページと記事ページでは構造が異なるため、別々に扱うのが基本です。

最初に、次のようなページを数件選びます。

  • アクセスが比較的多い記事
  • 画像が多い記事
  • 本文が長い記事
  • 広告枠を複数設置する記事
  • モバイルアクセスが多い記事
  • 広告を設置しない比較用ページ

測定時には、ページURL、測定日、端末区分、広告配置、広告枠数、テーマやJavaScriptの変更内容を記録します。広告と同時に画像最適化やテーマ変更を行うと、どの施策が数値に影響したのか判別しにくくなります。

広告導入前の記録例は次のとおりです。URLも各項目も架空の記入例で、当サイトの実測値ではありません。

対象URL: /blog/example/
測定日: 変更前
端末区分: モバイル
広告配置: なし
LCP: PageSpeed Insightsの表示値を記録
CLS: PageSpeed Insightsの表示値を記録
INP: 実ユーザーデータが表示される場合に記録
収益指標: 広告導入前のため対象外
同時に行った変更: なし

PageSpeed Insightsの結果は測定タイミングや環境によって変動します。1回だけの結果で判断せず、条件をそろえて複数回確認し、個々の値と傾向を残してください。

PageSpeed Insightsで導入前後を測る手順

PageSpeed Insightsでは、実ユーザーの環境から収集されたフィールドデータと、Lighthouseによるラボデータが表示されます。ただし、対象URLのデータ量が十分でない場合は、URL単位のフィールドデータが表示されないことがあります。

実際の確認手順は次のとおりです。

  1. 広告導入前に対象URLをPageSpeed Insightsへ入力する
  2. モバイルとデスクトップを分けて結果を保存する
  3. LCP、CLS、INPのフィールドデータがあるか確認する
  4. ラボデータではLCP、CLS、Total Blocking Timeなどを確認する
  5. 診断欄に表示されるレイアウトシフトやJavaScript関連の指摘を記録する
  6. 広告を導入し、ほかの変更を加えずに再測定する
  7. 導入前後の差と、診断内容の変化を比較する

当サイトは1〜5までで止まっています。6以降は広告を配信できる状態が前提で、審査に通っていなければ実行できません。基準値だけ先に保存しておけば、承認後にこの手順の後半から再開できます。

ラボデータのTotal Blocking TimeはINPそのものではありません。INPは実際のユーザー操作に基づくフィールド指標であり、ラボ環境では直接同じ形で評価できないため、混同しないようにします。

差分は次のように整理できます。

LCPの変化 = 広告導入後のLCP - 広告導入前のLCP
CLSの変化 = 広告導入後のCLS - 広告導入前のCLS
INPの変化 = 広告導入後のINP - 広告導入前のINP

例:
導入前LCP: 測定値A
導入後LCP: 測定値B
差分: B - A

フィールドデータは直近28日間の実ユーザーデータを集計したものです。そのため、広告を追加した直後には導入前のデータも含まれます。変更直後の確認にはラボデータを利用し、中長期の確認にはフィールドデータを利用すると役割を分けられます。

Search Consoleでサイト全体の傾向を確認する

Search Consoleの「ウェブに関する主な指標」レポートでは、Chromeユーザーエクスペリエンスレポートの実ユーザーデータをもとに、URLが状態別にまとめられます。モバイルとパソコンは別に確認します。

確認手順は次のとおりです。

  1. Search Consoleで対象プロパティを開く
  2. 「エクスペリエンス」から「ウェブに関する主な指標」を開く
  3. モバイルとパソコンの「不良」「改善が必要」「良好」の推移を確認する
  4. 広告導入日を検証記録に残す
  5. 問題のあるURLグループを開く
  6. 代表URLをPageSpeed Insightsで個別に調べる
  7. 改善後は必要に応じて検証を開始し、推移を確認する

Search Consoleでは、類似する問題を持つURLがグループ化されることがあります。特定の1ページだけを精密に測る道具ではなく、テンプレート単位やサイト全体の悪化傾向を見つけるために使います。

検索流入も含めて継続的に確認する場合は、GA4とSearch Consoleで毎月追う指標と実測例もあわせて整理しておくと、速度改善による変化とアクセス構成の変化を区別しやすくなります。

LCPが悪化した場合の調べ方

広告導入後にLCPが悪化した場合は、まずLCPとして判定された要素を確認します。Lighthouseやブラウザの開発者ツールでは、LCP候補になった画像やテキスト要素を調査できます。

特に確認したい点は次のとおりです。

  • ファーストビュー内の広告が主要コンテンツより先に大きな領域を占めていないか
  • 広告スクリプトの読み込みが画像やCSSの取得と競合していないか
  • 広告コードの追加により、レンダリングを妨げる処理が増えていないか
  • LCP画像に不要な遅延読み込みを設定していないか
  • 広告以外のタグやアクセス解析スクリプトも同時に増えていないか

対応策として、ファーストビューの広告位置を変更する、不要な第三者スクリプトを減らす、主要画像の配信を優先する、といった候補を一つずつ試します。広告コードを独自に変更する場合は、広告サービスのポリシーや公式実装方法に反しないことを必ず確認してください。

CLSが悪化した場合の調べ方

広告では、広告内容が読み込まれた後に枠の高さが変わり、本文が押し下げられることがあります。CLSを抑えるには、読み込み前から広告用の領域を確保できているかを確認します。

主なチェック項目は次のとおりです。

  • 広告コンテナに表示前の領域があるか
  • 広告の読み込み後に本文や見出しが移動していないか
  • レスポンシブ表示で枠の高さが大きく変わっていないか
  • 広告が表示されない場合に、枠の折りたたみで大きな移動が発生しないか
  • 固定ヘッダーや同意管理バナーによる移動を広告の影響と誤認していないか

Chrome DevToolsのPerformanceパネルでは、レイアウトシフトが発生した箇所を調べられます。画面録画も併用し、どの要素がいつ移動したかを確認すると原因を切り分けやすくなります。

広告枠のサイズを固定すれば常に最適になるとは限りません。画面幅や配信される広告形式に合わない領域を確保すると、大きな空白や表示崩れにつながる可能性があります。公式の広告実装ガイドを確認したうえで、サイトのレイアウトに合う方法を選びます。

INPが悪化した場合の調べ方

INPは、クリック、タップ、キーボード入力などへの応答性を示します。広告関連のJavaScriptが長い処理を発生させると、ユーザー操作への応答が遅れる可能性があります。

次の場面で操作感を確認します。

  • ページ読み込み直後にメニューを開く
  • 目次リンクをタップする
  • アコーディオンを開閉する
  • フォームへ文字を入力する
  • 広告が更新・描画されるタイミングでリンクを操作する

Chrome DevToolsのPerformanceパネルでは、長いタスクやスクリプト実行の流れを確認できます。ただし、第三者スクリプトが表示されているだけで広告を原因と断定せず、実行時間と操作遅延が重なっているかを調べます。

実ユーザー環境のINPを詳しく把握したい場合は、web-vitalsライブラリなどを使った独自計測も候補になります。その際は、ユーザーの同意、プライバシーポリシー、データ送信先の設定を確認してください。

表示速度と収益を同時に比較する

Core Web Vitalsが改善しても、広告表示回数や収益が大きく減れば、運営上の目的と合わない場合があります。反対に、短期的な収益増加だけを見て表示体験の悪化を放置するのも適切ではありません。

比較表には、少なくとも次の項目を含めます。数値欄は各自が自分の計測値を書き込む枠として空けてあり、当サイトの実測値ではありません。当サイトで実際に計測できている検索指標は検証データのページで公開しています。

項目 変更前（記入枠） 変更後（記入枠） 判断時の注意
LCP 測定値 測定値 モバイルとパソコンを分ける
CLS 測定値 測定値 広告表示時の移動を確認する
INP 測定値 測定値 フィールドデータの有無を確認する
ページビュー 集計値 集計値 期間や流入の差を考慮する
広告表示回数 集計値 集計値 配置や広告枠数を記録する
ページRPM 管理画面の値 管理画面の値 同程度の期間・ページ群で比較する
推定収益額 管理画面の値 管理画面の値 確定収益と混同しない

下3行はAdSense管理画面から取る値なので、審査に通るまでは埋まりません。当サイトはこの3行が空のまま、上4行だけを記録しています。

ページRPMは、AdSenseヘルプで案内されている考え方では、推定収益額をページビュー数で割り、1,000を掛けて算出します。

ページRPM = 推定収益額 ÷ ページビュー数 × 1,000

収益指標は曜日、広告需要、流入元、閲覧地域、端末構成などの影響を受けます。導入前後の短い期間だけで結論を出さず、同じページ群と端末区分で比較します。配置ごとの収益検証は、AdSense広告配置でRPMを改善する検証手順も参考にしてください。

一度に変更する広告要素は一つに絞る

原因を特定するには、変更単位を小さくします。たとえば次の順番で検証します。

  1. 広告なしの基準値を保存する
  2. 記事下広告だけを追加する
  3. PageSpeed Insightsと収益指標を記録する
  4. 問題がなければ記事内広告を追加する
  5. LCP、CLS、INPを再確認する
  6. 次にファーストビュー付近の配置を試す
  7. Search Consoleでサイト全体の推移を確認する
  8. 収益増加と表示体験の変化を比較して採用可否を決める

検証記録には、採用・不採用の理由も残します。

変更内容: 記事内の見出し直前に広告枠を追加
対象期間: 比較した期間を記録
対象ページ: 同じテンプレートの記事群
CWVの変化: LCP、CLS、INPを記録
収益の変化: ページRPM、推定収益額などを記録
その他の変化: 流入元、端末比率、記事更新の有無
判断: 継続／配置変更／撤去
判断理由: 数値と目視確認をもとに記録

広告表示の影響は、サイト構造、閲覧端末、広告形式によって異なります。「広告枠は何個まで」「この位置なら必ず速い」といった一律の答えではなく、自分のサイトの実測値で判断することが大切です。

検証時のチェックリスト

最後に、実作業で確認する項目をまとめます。

  • 広告導入前のPageSpeed Insights結果を保存した
  • モバイルとデスクトップを分けて測定した
  • フィールドデータとラボデータを区別した
  • 対象URLと広告配置を記録した
  • 広告以外の変更を同時に行っていない
  • LCPとして判定された要素を確認した
  • 広告表示前後のレイアウト移動を目視した
  • 操作時の長いJavaScript処理を調べた
  • Search ConsoleでURLグループの傾向を確認した
  • 収益額だけでなくページRPMやページビューも比較した
  • 流入元や端末構成の違いを考慮した
  • 変更内容と採用理由を記録した

PageSpeed Insightsは個別ページの診断、Search Consoleは実ユーザーデータに基づくサイト全体の傾向確認に向いています。短期のラボ測定と中長期のフィールドデータを組み合わせ、収益指標も同じ記録表に残すことで、表示速度と広告収益の両立を検証しやすくなります。

関連記事