このサイト自体を題材に、Core Web Vitals（CWV）を実測しながら改善した記録です。見た目は一切変えず、Lighthouse のモバイル Performance を 58 → 99、LCP を 8.6s → 2.3s まで改善しました。
まず計測する（推測しない）
改善は計測から始めます。本番URLに対して Lighthouse を回し、ラボ値を取りました。
- Performance: 58
- LCP: 8.6s（"poor"）
- FCP: 6.9s / Speed Index: 6.9s
- CLS: 0（良好）/ TBT: 80ms（良好）
最大の改善機会は render-blocking resources で約3,961ms。CLS と TBT は良好なので、ボトルネックは「最初の描画までの待ち」に集中していると分かります。
原因の特定：フォント
ネットワークを実測すると、犯人は Google Fonts でした。
- フォント宣言CSS（css2）だけで 約475KB
- 日本語の Noto Sans JP がサブセット分割で woff2 を約19ファイル取得
- これらが render-blocking で、最初の描画を大きく遅らせていた
日本語 Web フォントは、サブセットが unicode-range ごとに大量展開されるため、weight を増やすほど宣言CSSもダウンロードも膨らみます。
改善ステップ
1. 使っていないウェイト・ファミリーを削る
実使用を確認し、4ウェイト読み込んでいた Noto Sans JP を 2ウェイトに、ほぼ未使用だった Roboto Mono を撤廃。宣言CSSは 475KB → 238KB（▲49%） に。
2. 日本語はシステムフォントへ
表示の主役は欧文のディスプレイ書体だったため、日本語本文を OS 標準の高品質フォント（Hiragino / Yu Gothic / Meiryo 等）に切り替え。Noto Sans JP の Web フォント読み込みを撤廃しました。これで css2 は 10KB、woff2 リクエストは 約19 → 0。Performance は 81、LCP 4.3s まで改善。
3. 欧文は next/font で自己ホスト
最後に残った render-blocking は、欧文フォントの cross-origin な Google Fonts CSS でした。next/font/google で Inter / Space Grotesk を自己ホスト（同一オリジン配信・自動 preload・size-adjust フォールバック）に変更。フォント自体は同じなので見た目は不変です。
結果、render-blocking が消滅し、最終スコアは：
| 指標 | Before | After |
|---|---|---|
| Performance | 58 | 99 |
| LCP | 8.6s | 2.3s |
| FCP | 6.9s | 0.8s |
| Speed Index | 6.9s | 1.7s |
| TBT | 80ms | 20ms |
| CLS | 0 | 0 |
学び
- フォントは最大のレバーになりやすい。特に日本語 Web フォントは重い。
- 見た目を変えずに大幅改善できる余地は意外と大きい（自己ホスト化・不要ウェイト削減）。
- 数値で before/after を取ると、何が効いたか・どこで止めるべきかを判断できる。LCP が "良好"（<2.5s）に入った時点で、演出に手を入れるリスクを取る必要はないと判断しました。
パフォーマンスは「速くする」こと自体が目的ではなく、見てくれる人の体験を損なわないための土台です。計測 → 原因特定 → 最小の変更、のサイクルを回すのが結局いちばん近道でした。
ご相談はこちらからどうぞ。