Blog

投稿日:2025.10.11  最終更新日:2025.9.29
SEO対策

ページエクスペリエンス2025対応チェックシートで失点を防ぐ

ページエクスペリエンス2025対応チェックシートで失点を防ぐ

Page Experience 2025 アップデートとは

2025 年 3 月に実施された Google の Page Experience アップデートは、従来の Core Web Vitals(LCP・FID・CLS)に Interaction to Next Paint(INP) を正式採用し、モバイル重視の評価比率をさらに高めました。検索順位へのインパクトは限定的と言われますが、ユーザー体験の格差が広告 ROI やリード CVR に直結するため、放置は機会損失を招きます。本稿では、不動産サイトや中古車情報サイトのように「画像が多い・モバイルで警告が多い」環境で何から手を付けるべきか、経営層でも理解できる順序で解説します。

Core Web Vitals 新旧指標の整理

まずは評価項目の変遷を把握しましょう。

世代評価項目合格目安主な改善アプローチ
~2024LCP・FID・CLSLCP ≤ 2.5 s
FID ≤ 100 ms
CLS ≤ 0.1
画像遅延読み込み・不要 JS 削減
2025~LCP・INP・CLSLCP ≤ 2.5 s
INP ≤ 200 ms
CLS ≤ 0.1
重点:インタラクション最適化(JS 分割、UI 凝縮)

INP はページ読み込み後のクリック・入力体験を測る指標です。画像ギャラリーでスワイプするたびに遅延が起きるサイトは高リスクとなります。

失点しやすい要素別チェックリスト

画像・動画リソース

  • 1 ページ当たりの画像容量が 2 MB 超
  • srcset 未設定で端末ごとに適切解像度を出し分けていない
  • WebP 変換率が 70 % 未満

JSX・サードパーティスクリプト

  • 同期読み込みのタグマネージャが複数存在
  • SPA フレームワークでルーティングを区切らず巨大バンドルを配信

レイアウトシフト(CLS)

  • アスペクト比未指定の <img> が 25 %以上
  • 広告・アフィリエイトタグの高さ固定が未対応

ケーススタディ①:画像ギャラリー中心の不動産サイト

Lighthouse スコア 55、CLS 0.28 という典型例では、ヒーロー画像の読み込み待ちとカルーセルのアニメーションが主犯でした。優先すべきは「静的ファーストビュー+遅延読込」への設計転換です。

  1. サーバーサイドで WebP 生成
    • 既存 JPEG を 70 % 品質の WebP に。容量 35 % 削減。
  2. fetchpriority="high" の限定使用
    • ヒーロー画像 1 枚のみに付与し、残りは遅延ロード。
  3. カルーセルの自動再生停止
    • JavaScript アニメーションを削減し INP を 280 ms → 160 ms へ短縮。

こうした段階的な手当てで Lighthouse スコアは 55 → 81、CLS は 0.28 → 0.06 に収まりました。経営者にとっては「高速化=要素削除」と映りがちですが、表示順序とアスペクト比指定だけでも大幅な改善が可能です。

画像最適化フローの全体像

ステップツール例成果物工数目安
画像棚卸しScreaming Frog画像リスト (URL・容量)1 日
変換・圧縮Squoosh CLIWebP/AVIF 画像2~3 日
コード改修GitHub Actionssrcsetloading="lazy" 反映1 週間
検証PageSpeed Insightsスコア & ラボデータ0.5 日

※小規模サイトなら外注 20 万円~、社内対応なら 2 人日×3 週間が目安です。

計測ツールの使い分け

  • Lighthouse(ラボデータ):改修前後の差分確認に最適
  • PageSpeed Insights(フィールド+ラボ):実ユーザーの統計も確認
  • Search Console > Core Web Vitals:URL 単位で合否を一覧把握

重視すべきは フィールドデータが閾値を切るかどうか。ラボで良くても、通信品質が悪い地域ではフィールド評価が劣化するケースがあります。

ケーススタディ②:モバイル警告が出る中古車情報サイト

中古車情報サイト A 社は、Search Console で

  • 「テキストが小さすぎる」
  • 「タップ要素が近すぎる」
  • 「コンテンツ幅が画面を超えている」
    というモバイル UX 警告が集中し、スマホ流入の直帰率が 11 pt 悪化していました。ページ構成は「車両一覧(サムネイル+価格)→詳細ページ→問い合わせ」の 3 ステップ。主な原因と対策は以下のとおりです。
改善前の課題具体的症状主な対策効果指標
テーブルレイアウト固定一覧ページが width:960px 固定で横スクロールCSS を Grid に変更し minmax(160px, 1fr) で可変化CLS 0.18 → 0.05
リンク間隔不足車名リンクと価格リンクの間隔 4 pxgap:12pxline-height:1.6 でタップ領域拡張モバイル警告 65 → 0
フォントサイズ 12 px年式・走行距離を小さく表示14 px+rem 指定に統一直帰率 ▲6 pt
広告ラベル後読み込み画面外から広告が押し出し高さ予約+loading="lazy"CLS 0.05 → 0.01

実施結果

  • Lighthouse モバイルスコア 49 → 78
  • INP 420 ms → 190 ms
  • スマホ CVR +0.4 pt(1.8 % → 2.2 %)

改修総工数はデザイナー 2 人日+コーダー 3 人日。レイアウトをフルリニューアルせず 「CSS の可変化」と「タップ領域調整」 に絞った点が効率化の決め手でした。

改善アクション優先度の付け方

施策が多岐にわたる場合は Impact×Effort マトリクスで優先度を決定します。

分類代表施策期待インパクト工数優先度
クイックウィンimgのアスペクト比指定、WebP 変換最優先
メジャー改修JavaScript 分割、Critical CSS 抽出
中期改善サードパーティ削減、CDN 最適化
投資案件SPA から MPA への移行最高低(要 ROI 試算)

最優先は「工数が低くインパクトが大きい」領域です。経営者にとっては ROI が見えやすく、着手判断が容易になります。

優先度決定の 3 ステップ

  1. KPI への寄与度:CVR・ページビュー・広告収益のどれに効くか
  2. ユーザーボリューム:該当 URL のアクセス割合
  3. 開発ボトルネック:既存フレームワークとの整合性、担当者の空き状況

これらをスコアリングして工数に対する 効果単価を算出すると、会議での合意形成がスムーズです。

実装後の検証フローと KPI 設定

改善施策が完了したら、「計測→判定→再計画」を 1 サイクル 4 週間で回します。推奨 KPI は以下のとおり。

KPI判定基準計測ツール判定頻度
LCP・INP・CLS75 パーセンタイル値が合格域Search Console週次
モバイル離脱率サイト平均比 ▲5 pt 以上GA4週次
コンバージョン率改修前後で +0.3 pt 以上GA4月次
ページ離脱位置ファーストビュー内離脱率 < 35 %ヒートマップ月次

ダッシュボード設計のポイント

  • 実測値とラボ値を分けて表示し、開発・運用の双方が理解できるようにする
  • 異常検知アラートを 24 時間以内に Slack 通知
  • グラフは「3 か月移動平均」と「週次スナップショット」を併記し、トレンドと短期変動を可視化

これにより、数値悪化を検知した段階で 再優先度付け → 次スプリント計画に即移行できます。

よくある Q&A とトラブルシュート

Q1. Search Console の「改善が必要」URL が減らない

  • フィールドデータ更新は最長 28 日かかる。施策反映後も 1 か月は様子を見る
  • キャッシュ削除後の URL 検査で 検証リクエストを送信し、更新を促す

Q2. INP 値が一時的に悪化した

  • GTM で新しいタグを追加していないか確認
  • クリティカルパスに影響する JS を defer へ切り替え

Q3. WebP 化で画像が荒く見える

  • 品質 80 % 以下で劣化が目立つ場合は AVIF + 品質 50 % をテスト
  • 不動産など視覚訴求が重要な業種では、一覧は圧縮率優先、詳細は品質優先と 用途で切り替え

ダッシュボード実装手順

改善効果を継続把握するには 計測の自動化 が肝となります。下記フローを GitHub Actions など CI 上に組み込み、プルリクごとに指標を採点するとリリース前の品質保証が容易になります。

  1. Lighthouse CI をプロジェクトに追加
    lighthouseci パッケージを devDependencies に追加し、lighthouserc.json で閾値を設定。
  2. ワークフロー作成
    push/pull_request トリガーで lhci autorun を実行し、スコアが基準を下回った場合はビルドを失敗させる。
  3. 結果の可視化
    データストアに保存し、Looker Studio でダッシュボード化。経営層向けには 月次 PDF レポート を自動送信する。

これにより開発者は「スコアを通すまでマージ不可」というルールで質を担保でき、経営層は レポート閲覧のみで状況把握 が可能になります。

運用体制と役割分担

役割主担当週次タスク月次タスク
プロダクトオーナー経営層KPI 進捗確認投資判断
テックリード開発Lighthouse CI 管理技術負債棚卸し
デザイナー制作UI 改修計画アセット最適化
マーケ責任者マーケ部流入分析・施策調整CVR・ROI 報告
サイト運用CS・外注画像投稿ルール徹底コンテンツ軽量化

ポイントは「指標ごとの責任者を明確化」 すること。CLS が悪化した場合はデザイナーと運用がまず行動し、INP 悪化はテックリードが主導する、といった形で担当を固定します。

予算シミュレーション:中規模サイト(2,000 URL)の場合

項目内製外注工期目安
計測環境構築0 円(既存 CI 利用)30 万円2 週間
画像最適化12 人日 ≒ 48 万円50 万円1 か月
JS 分割・CDN18 人日 ≒ 72 万円90 万円1.5 か月
モバイル UI 改修15 人日 ≒ 60 万円80 万円1 か月
総額180 万円250 万円2~3 か月

※人日単価 4 万円で算出。外注はディレクション・テスト込みの概算です。ROI を測定可能な KPI(CVR・広告収益)と紐付けて予算取得することで、経営層の合意を得やすくなります。

チェックリスト:公開前に確認すべき 10 項目

  1. LCP が 2.5 秒以下か
  2. INP が 200 ms 以下か
  3. CLS が 0.1 未満か
  4. モバイル警告 0 件か
  5. 画像形式が WebP/AVIF に統一されているか
  6. srcsetsizes でレスポンシブ対応しているか
  7. 主要 JS が分割され defer または async 設定か
  8. タップ領域が 48 px 以上確保されているか
  9. 広告・埋め込み要素に高さ予約があるか
  10. Lighthouse CI がパスするか

上記を ローンチ判定ゲート として社内規定化すると再発を防げます。

まとめ:2025 年以降に備える運用体制

Page Experience 2025 の本質は「ユーザーの時間を奪わないサイト運営」です。

  • 指標の合格はあくまで スタートライン
  • 継続測定と優先度再設定の ループ運用 が不可欠
  • 経営指標(CVR・ROI)と技術指標(LCP・INP)を 同一ダッシュボードで管理 する

これらを徹底することで、検索順位変動に左右されにくい 強い集客基盤 を構築できます。