Blog お役立ちブログ
ページエクスペリエンス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 新旧指標の整理
まずは評価項目の変遷を把握しましょう。
世代 | 評価項目 | 合格目安 | 主な改善アプローチ |
---|---|---|---|
~2024 | LCP・FID・CLS | LCP ≤ 2.5 s FID ≤ 100 ms CLS ≤ 0.1 | 画像遅延読み込み・不要 JS 削減 |
2025~ | LCP・INP・CLS | LCP ≤ 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 という典型例では、ヒーロー画像の読み込み待ちとカルーセルのアニメーションが主犯でした。優先すべきは「静的ファーストビュー+遅延読込」への設計転換です。
- サーバーサイドで WebP 生成
- 既存 JPEG を 70 % 品質の WebP に。容量 35 % 削減。
fetchpriority="high"
の限定使用- ヒーロー画像 1 枚のみに付与し、残りは遅延ロード。
- カルーセルの自動再生停止
- JavaScript アニメーションを削減し INP を 280 ms → 160 ms へ短縮。
こうした段階的な手当てで Lighthouse スコアは 55 → 81、CLS は 0.28 → 0.06 に収まりました。経営者にとっては「高速化=要素削除」と映りがちですが、表示順序とアスペクト比指定だけでも大幅な改善が可能です。
画像最適化フローの全体像
ステップ | ツール例 | 成果物 | 工数目安 |
---|---|---|---|
画像棚卸し | Screaming Frog | 画像リスト (URL・容量) | 1 日 |
変換・圧縮 | Squoosh CLI | WebP/AVIF 画像 | 2~3 日 |
コード改修 | GitHub Actions | srcset ・loading="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 px | gap:12px ・line-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 ステップ
- KPI への寄与度:CVR・ページビュー・広告収益のどれに効くか
- ユーザーボリューム:該当 URL のアクセス割合
- 開発ボトルネック:既存フレームワークとの整合性、担当者の空き状況
これらをスコアリングして工数に対する 効果単価を算出すると、会議での合意形成がスムーズです。
実装後の検証フローと KPI 設定
改善施策が完了したら、「計測→判定→再計画」を 1 サイクル 4 週間で回します。推奨 KPI は以下のとおり。
KPI | 判定基準 | 計測ツール | 判定頻度 |
---|---|---|---|
LCP・INP・CLS | 75 パーセンタイル値が合格域 | 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 上に組み込み、プルリクごとに指標を採点するとリリース前の品質保証が容易になります。
- Lighthouse CI をプロジェクトに追加
lighthouseci
パッケージを devDependencies に追加し、lighthouserc.json
で閾値を設定。 - ワークフロー作成
push/pull_request トリガーでlhci autorun
を実行し、スコアが基準を下回った場合はビルドを失敗させる。 - 結果の可視化
データストアに保存し、Looker Studio でダッシュボード化。経営層向けには 月次 PDF レポート を自動送信する。
これにより開発者は「スコアを通すまでマージ不可」というルールで質を担保でき、経営層は レポート閲覧のみで状況把握 が可能になります。
運用体制と役割分担
役割 | 主担当 | 週次タスク | 月次タスク |
---|---|---|---|
プロダクトオーナー | 経営層 | KPI 進捗確認 | 投資判断 |
テックリード | 開発 | Lighthouse CI 管理 | 技術負債棚卸し |
デザイナー | 制作 | UI 改修計画 | アセット最適化 |
マーケ責任者 | マーケ部 | 流入分析・施策調整 | CVR・ROI 報告 |
サイト運用 | CS・外注 | 画像投稿ルール徹底 | コンテンツ軽量化 |
ポイントは「指標ごとの責任者を明確化」 すること。CLS が悪化した場合はデザイナーと運用がまず行動し、INP 悪化はテックリードが主導する、といった形で担当を固定します。
予算シミュレーション:中規模サイト(2,000 URL)の場合
項目 | 内製 | 外注 | 工期目安 |
---|---|---|---|
計測環境構築 | 0 円(既存 CI 利用) | 30 万円 | 2 週間 |
画像最適化 | 12 人日 ≒ 48 万円 | 50 万円 | 1 か月 |
JS 分割・CDN | 18 人日 ≒ 72 万円 | 90 万円 | 1.5 か月 |
モバイル UI 改修 | 15 人日 ≒ 60 万円 | 80 万円 | 1 か月 |
総額 | 180 万円 | 250 万円 | 2~3 か月 |
※人日単価 4 万円で算出。外注はディレクション・テスト込みの概算です。ROI を測定可能な KPI(CVR・広告収益)と紐付けて予算取得することで、経営層の合意を得やすくなります。
チェックリスト:公開前に確認すべき 10 項目
- LCP が 2.5 秒以下か
- INP が 200 ms 以下か
- CLS が 0.1 未満か
- モバイル警告 0 件か
- 画像形式が WebP/AVIF に統一されているか
srcset
とsizes
でレスポンシブ対応しているか- 主要 JS が分割され
defer
またはasync
設定か - タップ領域が 48 px 以上確保されているか
- 広告・埋め込み要素に高さ予約があるか
- Lighthouse CI がパスするか
上記を ローンチ判定ゲート として社内規定化すると再発を防げます。
まとめ:2025 年以降に備える運用体制
Page Experience 2025 の本質は「ユーザーの時間を奪わないサイト運営」です。
- 指標の合格はあくまで スタートライン
- 継続測定と優先度再設定の ループ運用 が不可欠
- 経営指標(CVR・ROI)と技術指標(LCP・INP)を 同一ダッシュボードで管理 する
これらを徹底することで、検索順位変動に左右されにくい 強い集客基盤 を構築できます。