Next.js 個人開発、公開直後 P1 監査で 11MB 画像・OGP 欠落 4 件 — ローカル Lighthouse perf 30 台、本番 90 台のズレを実測した

結論

Next.js 15 + Vercel で作ったデモページを公開した翌日、Lighthouse をローカルで計測したら perf が 32〜35 しか出なかった。

「画像最適化が足りないのか」「next/image の設定か」と焦って調べかけたが、試しに本番 URL で同じスクリプトを叩いたら 88〜94 だった。ローカルと本番で 3 倍近い差が出る。ローカルの perf 数値を修正の根拠にしていたら、何時間も溶かしていた。

同時に走らせた Playwright P1 監査では、友人 LINE 拡散前に 4 件の致命傷が見つかった。

この記事の前提

スタック: Next.js 15 + Supabase + Vercel（個人開発の工務店向け SaaS デモページ）
状況: demo-gallery を 2026-05-14 に公開、翌日に友人 LINE グループへ拡散予定
計測環境: Mac + ローカル dev サーバー / 本番 Vercel URL 直叩き
ツール: Playwright（E2E 自動監査）、lighthouse CLI、cwebp
計測ページ数: 11 ページ全体を対象

読者のよくある詰まり

「Lighthouse を入れたら perf 30 台が出た。Next.js の設定が間違っているのか。next/image を全部使い直すべきか……」

このパターンは、ローカル計測の calibration ズレを本番の問題と誤認している可能性が高い。ローカルで計測するたびに焦って設定を変え、本番の状態をむしろ壊してしまう、という逆効果のループに入る。

実際に起きたこと

Lighthouse ローカル vs 本番の実測差

公開直後に 11 ページを Lighthouse で計測した。

環境	perf スコア
ローカル（dev + prod ビルド同居の loopback）	32〜35
本番 Vercel URL（直接計測）	88〜94

同じコード、同じ Vercel デプロイに対して、計測環境を変えただけでこれだけ変わる。

ローカルで dev サーバーが動いている状態で Lighthouse を叩くと、HMR・ソースマップ・loopback のネットワーク条件が本番と根本的に違う。特に perf スコアはレンダリングタイミングとネットワーク遅延に敏感で、ローカルの数値は参考にならない。

結論を先に書く。perf の判定は本番 deploy 後に本番 URL で測る。ローカルの数値は perf に関して無視する。

P1 監査で 4 件が発覚

友人に「見てみて」と送る前日に Playwright スクリプトで P1 チェックを走らせた。結果、4 件が発覚した。

1. 画像 11MB（本番サーバーに PNG のまま上がっていた）

cwebp -q 82 -m 6 で WebP 変換したら 11MB が 940KB になった。92% 削減。PNG を public/ に直置きしてそのまま本番に出していた。

2. OGP + Twitter Card が完全欠落

curl -I https://demo-gallery.example.com | grep -i og を叩いたら何も返ってこなかった。LINE でシェアすると真っ白プレビューになる状態。画像とタイトルが出ないと、友人が「なんか怪しい URL」と思って踏んでくれない。

3. Placeholder が実画像 9 枚の上に被さっていた

画像のロード完了後も、ローディング中に表示していた placeholder が画像の上に残り続けていた。絶対配置の透明レイヤーが画像を覆っている状態で、実画像が「見えるが操作できない」という症状。

4. metadataBase 未設定

Next.js App Router で metadata.openGraph.images に相対パスを指定していた。metadataBase を設定しないと絶対 URL に変換されず、OGP 画像が正しく取得されない。layout.tsx に 1 行追加するだけで直る。

以上 4 件を Claude Code で 14 ターン使って全修正完了。スクリプトなしで手動チェックしていたら、友人拡散後に 1 件ずつ気づくことになっていた。

公開直前に友人に「URL 送るね」と言った後、念のため Playwright を走らせたら止まれた。「念のため」が 4 件の近未遂を防いだ。

原因分析

ローカル Lighthouse がずれる構造的な理由

Lighthouse の perf スコアは主に LCP（Largest Contentful Paint）・FID・CLS を元に計算する。これらはすべてネットワーク遅延とレンダリングタイミングに依存する。

ローカルで計測するとき：

localhost への通信は物理的なネットワークを通らない（loopback）
開発モードでは HMR・ソースマップ・デバッグコードが動いている
CPU 使用率がローカルの他のプロセス（Docker、エディタ等）に食われる

本番 Vercel で計測するとき：

CDN 経由の配信、エッジキャッシュ、HTTP/2 が効く
production ビルドのみ（開発用コードなし）
Lighthouse が想定している「典型的なユーザー環境」に近い

この構造的な差が 30 台 vs 90 台のズレになる。

OGP が欠落する典型パターン

Next.js App Router で layout.tsx に metadata を書いても、metadataBase がないと og:image の URL が https://yoursite.com/og.png にならず、相対パス /og.png のまま出力される。SNS クローラーは相対パスの画像を取得できない。

// ❌ metadataBase なし → og:image が相対パスになる
export const metadata: Metadata = {
  openGraph: {
    images: ['/og-image.png'],
  },
}

// ✅ metadataBase あり → 絶対 URL に変換される
export const metadata: Metadata = {
  metadataBase: new URL('https://yoursite.com'),
  openGraph: {
    images: ['/og-image.png'],  // → https://yoursite.com/og-image.png
  },
}

判断基準

公開前後でこの判断ルールにすると迷わない。

Lighthouse 計測の使い分け

計測対象	ローカル	本番
perf（LCP/FID/CLS）	使わない	本番 deploy 後に計測
a11y（アクセシビリティ）	先取り OK	最終確認
best-practices	先取り OK	最終確認
SEO（hreflang/canonicalなど）	先取り OK	最終確認

ローカルで a11y や SEO を先に通しておくと、本番計測での修正ラウンドが減る。perf だけは本番でしか意味のある数値が取れない。

公開前 P1 チェックリスト（最小版）

# 1. OGP 確認（画像・タイトルが返ってくるか）
curl -s https://yoursite.com | grep -i 'og:image\|og:title\|twitter:card'

# 2. 画像サイズ確認
ls -lh public/images/  # 1MB 超えがあれば変換対象

# 3. WebP 変換
cwebp -q 82 -m 6 input.png -o output.webp

# 4. metadataBase 確認（layout.tsx に入っているか）
grep -r "metadataBase" src/app/layout.tsx

今日やること（3 つ以内）

本番 URL で Lighthouse を計測する。ローカルの perf 数値で焦っているなら、まず本番で測り直す。90 台なら問題ない。
curl -s https://yoursite.com | grep og: を叩く。何も返ってこなければ OGP が欠落している。metadataBase の設定を確認する。
ls -lh public/ で 1MB 超の画像を探す。あれば cwebp -q 82 -m 6 input.png -o output.webp で変換する。