PageSpeedモバイル94点達成までの最適化ログとSEO改善の記録

地域密着のサービス業サイトで、PageSpeed Insightsのモバイルスコアが低迷していた。Lighthouseのレポートを開くたびに赤いスコアが目に刺さる。5段階のフェーズに分けて最適化を積み重ね、最終的にモバイル94点まで押し上げた。途中、Codex（GPT-5.3）に2回相談したタイミングが転機になった。

PageSpeed最適化: 5フェーズの記録

Phase 1: 基本的なリソースヒント

初回計測でモバイルスコアが低い状態からスタート。まずLighthouseが指摘する基本項目を潰した。

• img 要素に width / height 属性を追加（CLSの改善）
• Cloudflare _headers ファイルでキャッシュ制御ヘッダーを設定

レイアウトシフトの警告が消えたが、スコアの伸びは小さかった。

Phase 2: レンダリングパスの最適化

• CSSクリティカルパスのインライン化
• 画像への loading="lazy" 追加

ファーストビュー外の画像読み込みが遅延され、LCPが少し改善した。

Phase 3: 動画の再エンコード

サイトのヒーロー動画が帯域を食い潰していた。FFmpegで再エンコードを実施。

poster画像の <link rel="preload"> も追加。動画のダウンロード完了前にファーストビューが表示されるようになった。

WebMへの変換も試みたが、逆にファイルサイズが大きくなったためMP4に戻した。コーデックとコンテンツの相性がある。

Phase 4: 外部リソースとCSS削減

• GA4遅延読み込み: window.onload 後にスクリプトタグを動的挿入。初期ロードからGA4のスクリプトが消えた
• CSS minify: 20.8KB → 13.5KB（35%削減）。未使用セレクタの除去とショートハンド化
• owner_pic WebP変換: PNGからWebPに変換し、画像サイズを削減

ここまでで80点台後半に到達。ただしモバイルでは90点の壁を超えられなかった。

Phase 5: Codexとの相談で壁を突破

90点の壁を前に手詰まりになり、Codex（GPT-5.3）に2回相談した。

1回目の相談 → Google Fontsの帯域競合を指摘された。 Noto Sans JPのWebフォント読み込みが、他のリソースと帯域を奪い合っていた。システムフォントに切り替えたところ、フォントのダウンロードが消えてTTFBからLCPまでの時間が縮んだ。

2回目の相談 → モバイル動画の遅延読み込み方針。 autoplayを維持しつつ帯域を節約する方法として、IntersectionObserver でビューポート進入時に src を設定するアプローチを採用した。ファーストビュー外の動画がスクロールするまで読み込まれなくなった。

最終結果: モバイル94点を達成。

SEO改善

PageSpeed最適化と並行して、SEOの基盤を整備した。

実施内容

• SEO監査レポート作成: memo/2026-03-04/seo-audit-report.md に現状の問題点と対策を整理
• OG画像の専用作成: 1200x630px、ImageMagickで生成。鍵アイコン・電話番号・対応エリアを配置
• robots.txt / sitemap.xml: 新規作成してクローラーのアクセスを整理
• 構造化データ: JSON-LD（LocalBusiness）を追加。Googleのリッチリザルトテストで検証
• canonicalタグ追加: 重複コンテンツ問題の予防
• titleタグ最適化: 33文字 → 43文字に拡張し、地域名とサービス内容を含めた

GA4イベント計測

• phone_call イベントの計測を addEventListener 方式で実装。電話リンクのクリックをGA4に送信
• GA4管理画面で内部トラフィック除外を設定（自分のアクセスをフィルタリング）
• キーイベント設定の手順をマークダウンで記録し、再現可能な状態にした

振り返り

5フェーズを通じて、スコアの伸びが鈍化するポイントが2回あった。Phase 2→3の間と、Phase 4→5の間だ。どちらも「次に何を削るべきか」が見えなくなったタイミングで、Codexに相談して視点が切り替わった。

特にGoogle Fontsの帯域競合は、Lighthouseのレポートには直接出てこない。個別のリソースサイズは小さくても、同時ダウンロードの帯域争いがモバイル回線で効いてくる。Codexの指摘を受けてNetwork Waterfallを見直したら、フォントとヒーロー動画のダウンロードが重なっている箇所がはっきり見えた。

WebMが必ずしもMP4より小さくならない点も学びになった。コーデックの選択は「とりあえず新しい方」ではなく、実際にエンコードして比較するしかない。