SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Core Web Vitalsが悪化したとき、最初の30分でやること

Core Web Vitals（LCP/INP/CLS）が悪化したとき、最初の30分で「対象固定→フィールド/ラボ分離→直近変更→戻す/直す優先順位」を決める手順です。

著者: 川原更新: 2026-05-15運用改善RSS
Xで共有FacebookLinkedIn
料金相談

Core Web Vitals（CWV）が悪化したとき、最初にやるべきことは「改善案を考える」ではなく「“どの指標が・どの端末で・どのURL群で・いつから”悪化したのかを15分で固定する」ことです。CWVは“実ユーザーの体感”なので、計測（ラボ/フィールド）を混ぜると判断がブレます。最初の30分は、原因を当てにいくより「触る順番」を決めます。

0. まずやらないこと

  • いきなり全ページの画像を一括で差し替える
  • 不明な最適化ライブラリ/プラグインを衝動で入れる
  • 広告/計測タグを大量に追加・削除する（影響範囲が広い）
  • “スコアだけ”を見て、直近変更を無視して手当たり次第に触る

CWVの悪化は「本当に遅くなった」だけでなく「計測の見え方が変わった」でも起きます。まず“対象と期間”を固定します。

1. どの話かを固定（5分）

最低限、次をメモに残しておきます（後で迷わないため）。

  • 対象ドメイン
  • どのURL群か（全体 / 特定ディレクトリ / 特定テンプレート）
  • どの端末か（モバイル / デスクトップ）
  • どの指標か（LCP / INP / CLS）
  • いつからか（デプロイ/設定変更と結びつけられる粒度）

ここが固まらないと「直したつもりで別の問題を触る」になりがちです。

2. “フィールド”か“ラボ”かを切り分け（5分）

CWVは原則フィールド（実ユーザー）ですが、調査にはラボ（診断）も使います。混ぜずに役割を分けます。

  • フィールド（実ユーザー）: Search ConsoleのCWVレポート、CrUX（Chrome UX Report）
  • ラボ（診断）: PageSpeed Insights / Lighthouse

まずはフィールド側で「悪化が本当に起きているか（ユーザー体験として悪化しているか）」を確認します。

3. 直近変更を“候補”に入れる（5分）

多くのCWV悪化は、直近変更と関係があります。最初の30分は“犯人探し”ではなく、候補を並べます。

  • 画像（ヒーロー画像の差し替え、サイズ未指定、形式変更）
  • フォント（Webフォント追加、preloadの追加/削除）
  • JS（分析/広告/チャットなどのサードパーティ追加）
  • レイアウト（ファーストビューの構造変更、骨格の読み込み順）
  • キャッシュ/配信（CDN設定、圧縮、HTMLキャッシュの当たり方）

「この変更は戻せるか（ロールバックできるか）」も一緒に確認します。

4. “まず戻す”が最速な条件（5分）

次の条件が揃っているなら、最適化より先に“戻す”が最速です。

  • 悪化の開始がデプロイ/設定変更と一致している
  • 悪化が広範囲（多数URL）で再現している
  • 直近変更が1〜2個に絞れている
  • 戻してもビジネス上の致命傷がない（表示崩れ/計測停止などを避けられる）

戻して改善するなら「原因がその変更に近い」ことが確定するので、次の1時間の作業が直線的になります。

5. “直すなら何から”の優先順位（10分）

最初の30分で、次の優先順位で“当たりやすい”ところから当てにいきます。

LCPが悪化しているとき

  • ファーストビュー画像のサイズ指定（width/height 相当）と圧縮/形式
  • 画像の読み込み優先度（必要なら先読み、不要なら遅延）
  • フォントの読み込み（表示ブロック/FOIT回避、無駄なウェイト削減）
  • サードパーティ（広告/計測/ウィジェット）を初期表示から外せないか

INPが悪化しているとき

  • 直近で入れたサードパーティJS（広告/分析/チャット）を疑う
  • クリック/入力に重い処理を載せていないか（初回のみ/毎回）
  • 初期表示のJS量が増えていないか（不要なクライアント化）

CLSが悪化しているとき

  • 画像/広告枠の予約（高さ未固定で後から押し下げていないか）
  • フォント切り替え（レイアウトが動く設定になっていないか）
  • 遅延読み込み要素がレイアウトを押していないか

6. 30分で出す“結論”の型

最初の30分で、次のどれかに分類して次の作業を固定します。

  1. 対象が明確（URL群/端末/指標/開始時点が固定できた）: 直近変更と照合し、ロールバック or 1点修正を最短で当てる。
  2. フィールドの悪化が不確か（計測/期間が曖昧）: まず計測の見方を整え、対象を固定する作業に戻る。
  3. 原因候補が多すぎる: 影響が大きい順に、可逆な変更から検証する（戻せるものを先に触る）。

この分類ができれば、次の1時間で“当たりやすい修正”だけに集中できます。

SiteOpsで“悪化の検知”を早める（再発防止）

CWVは悪化してから気づくと復旧が遅くなりがちです。次からは「悪化が始まったタイミング」をすぐ特定できるようにしておくと、手戻りが減ります。

  • 複数サイトの主要シグナル（Search Console / 収益 / 変更履歴）を“見る順番”で固定する
  • 直近変更（デプロイ・設定）と数字の急変を結び付けて見られるようにする

状況が複雑で切り分けが難しい場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

関連

  • /media/search-console-drop-first-30-minutes
  • /media/adsense-rpm-drop-checklist
  • /media/daily-10min-ops-routine

参考にした一次情報

  • web.dev: Core Web Vitals
  • Google Search Central: Core Web Vitals report
  • PageSpeed Insights
  • Chrome UX Report (CrUX)

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

毎朝10分の“見る順番”を固定して、運用を続ける運用改善更新: 2026-05-13Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事StripeのWebhookが届かないとき、最初の30分でやること次の記事毎朝10分の“見る順番”を固定して、運用を続ける

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ