Lighthouse 99点で止めた理由 - 100点を追わないパフォーマンス最適化戦略
はじめに
Lighthouseで94点から99点へは改善できますが、100点を目指してCSSをインライン化すると初回は速くなっても2ページ目以降が遅くなります。
外部CDN依存の排除・レンダリングブロック解消・アセット分割の3施策で99点を達成し、意図的に100点追求を止めました。
（この94点は、ログイン機能追加によってスコアが92〜94点に低下した後の状態です。かつて全カテゴリ100点を達成した経緯はリンク先で読めます。）
こんな経験ありませんか？
Lighthouseで94点を取った。あと少しで100点満点。
調べると「CSSをインライン化しろ」「フォントをpreloadしろ」という情報が出てくる。
しかし、それを実装すると、 初回は速くなるが、2ページ目以降が遅くなった 。
この記事をお勧めしない人
- Lighthouseスコアが全てで、100点以外は失敗だと考える人
- 実際のユーザー体験より、測定ツールの数値を重視する人
- パフォーマンス最適化とアーキテクチャのトレードオフに興味がない人
もし一つでも当てはまらないなら、読み進める価値があるかもしれません。
100点への執着が招く構造的負債
- 「100点を取るためなら何でもする」という姿勢で最適化を続けると、 構造的負債 が静かに積み上がっていきます。特にAIは、この種の「測定ツールが喜ぶコード」を平気で生成します。
- やがて、CSSが散らばり、フォントが重複し、誰も触れないスパゲッティコードが完成するでしょう。そして、検索エンジンは実際のユーザー体験の悪さを見抜き、あなたのサイトの順位を下げ始めます。
- ついに、新機能の追加に数週間かかり、小さな変更でも全体が壊れる「レガシーシステム」と化し、ビジネスの生存戦略が崩壊します。
こんな未来が手に入ります
- この記事を読めば、 Lighthouseという指標の本質 を理解し、SEO・パフォーマンス・メンテナンス性を同時に最適化する戦略的判断が手に入ります。
- 具体的には、 測定ツールが評価する「初回訪問」と、実際のユーザーが体験する「2ページ目以降」のトレードオフ を理解し、ビジネスの生存に直結する意思決定の基準を学べます。
- この方法は、机上の空論ではありません。実際に94点から99点への改善を実証し、 AIが提案する100点のコードを制御した理由 を明確に記録しています。
- この情報は、単なるベストプラクティス集ではなく、 AIとの協調開発における統制の実例 という、他では得られない一次情報です。
私も同じでした
筆者も過去に「100点を取らなければ」という強迫観念に囚われ、AIが提案する最適化を無批判に受け入れた結果、アーキテクチャを犠牲にして後悔した経験があります。
しかし、このClaudeMixブログを「AIによる実装」と「人間による設計・統制」で作り上げる過程で、 AIをどう制御し、どこで止めるか という意思決定の重要性を学びました。
この記事で、測定ツールとAIの提案を正しく理解し、ビジネスの生存に直結する実用的な最適化戦略を持ち帰れるように書きました。
私が実行した3つの戦術
この「構造的不自然さ」を解消するために、以下の3つの戦術を実行しました。
- 外部依存の完全排除 : 外部CDNからのリソース読み込みを止め、ローカル制御下に置くことで大幅な遅延を短縮。
- レンダリング・ブロッキングの解消 : 競合していたリソース読み込み優先度を再定義し、描画遅延を84%削減。
- 配信資産の最適化 : 共通基盤と個別ロジックを分離し、キャッシュ効率を最大化。
その結果、Lighthouseで99点という、実用上の「完成形」に到達しました。
達成した成果
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| Performance | 94 | 99 | +5点 |
| LCP | 2.4-2.5s | 1.5-1.7s | -40% |
| Element Render Delay | 1,270-1,300ms | 210ms | -84% |
しかし、100点は目指しませんでした。なぜなら、測定ツールが評価する「初回訪問のパフォーマンス」を追求すると、実際のユーザーが体験する「2ページ目以降のパフォーマンス」が犠牲になるからです。
AIが陥る100点の罠
ここで重要な警告があります。
AIに「Lighthouseのスコアを100点にして」と頼むと、高確率で以下のような提案が返ってきます：
- 「全てのCSSをインライン化しましょう」
- 「フォントをpreloadしましょう」
- 「未使用JSを動的インポートで削減しましょう」
しかし、これらは 測定ツールのための最適化 です。初回訪問は速くなりますが、2ページ目以降のキャッシュ効率が犠牲になり、実際のユーザー体験は悪化します。
根本原因は、 Lighthouseが評価する指標と、SEO・ビジネスの生存に必要な指標が異なる ことにありました。AIは測定ツールが喜ぶコードを生成しますが、それがビジネス価値に直結するとは限りません。
ここから先は、AIが絶対に提案しない 「99点で止める戦略」 の全貌と、具体的な実装コード、CSSインライン化を却下した判断理由、そして実際のパフォーマンス測定結果を、すべて公開します。
この手順をコピーすれば、AIが提案する100点のコードを批判的に評価し、 実用的なパフォーマンスとアーキテクチャを両立 させられます。私が2週間かけて検証した技術選定と、AIの提案を却下した判断基準を、ここで全て公開します。
課題と解決策
では、実際にどのような技術選定と実装を行ったのか。具体的なコード、計測データ、そしてなぜ一般的な「CSSインライン化」が今回のアーキテクチャでは毒になったのか、すべて公開します。
さらに重要なのは、 AIが提案してきた100点のための施策を、どう評価し、どれを却下したか という意思決定プロセスです。この検証プロセスと判断基準を、AIコーダーが明日から使えるレベルで解説します。
この実装は、ClaudeMix本番環境で2ヶ月以上稼働している実証済みの構成です。同じ環境なら、このコードをコピーするだけで再現可能です。
開発の進捗
- Before: Performance 94点。LCP 2.4-2.5s、Element Render Delay 1,270-1,300ms。外部フォントCDN (750ms)、CSS preloadの競合、単一JSバンドル (257 kB) が課題。
- Current: Performance 99点達成。LCP 1.5-1.7s、Element Render Delay 210ms。Google Fontsセルフホスト化、CSS preload削除、JSバンドル分割により、84%の改善を実現。
- Next: 100点を目指さず、この状態を維持。理由は「100点のための施策は実用上マイナス」だから。
初回測定: 94点の壁
Lighthouseで94点を記録。主な課題:
- Google Fonts CDN: 750-780ms のブロッキング
- 複数CSS: layer2-common (470ms) + layer2-posts (470ms) + entry (310ms)
- Element Render Delay: 1,270-1,300ms
- 未使用JS: 82 kB中、45%が未使用
Lighthouseは「CSSをインライン化しろ」と提案。しかし、 17KBのCSSを全てインライン化すると、2ページ目以降が遅くなる 。
工夫したこと: 段階的最適化
4つの段階で最適化を実施:
第1弾: フォント最適化とJSバンドル分割
// Before: 外部CDN
<link href="https://fonts.googleapis.com/..." />
// After: セルフホスト
import "@fontsource/oswald/400.css";効果:
- フォント読み込み: -750ms
- JSバンドル: 257 kB → 260 kB に分割
- vendor-react: 201 kB
- vendor-remix: 51 kB
- vendor: 8 kB
第2弾: CSS preloadの削除
// Before: 手動preload
{ rel: "preload", href: "style.css", as: "style" }
{ rel: "stylesheet", href: "style.css" }
// After: stylesheet のみ
{ rel: "stylesheet", href: "style.css" }理由 : Remixは自動的にCSSを最適化。手動preloadは優先度の競合を引き起こす。
効果:
- Element Render Delay: 1,300ms → 210ms (-84%)
第3弾: クリティカルCSSの最小インライン化
<style>
*,*::before,*::after{box-sizing:border-box}
:root{
--color-background-primary:#111;
--color-text-primary:#E8E8E8;
}
</style>インライン化したもの:
- box-sizing, scroll-behavior (50バイト)
- 主要なCSS変数 (150バイト)
- 合計約200バイト
インライン化しなかったもの:
- 17 KB の layer CSS (外部ファイルのまま)
理由 : 初回は速くなるが、2ページ目以降で キャッシュが効かず遅くなる 。
ぶつかった壁: 100点か、実用性か
最も大きな壁は、 Lighthouseスコアと実用的なパフォーマンスのトレードオフ でした。
シミュレーション: CSSインライン化の影響
【現状: 99点】
初回訪問: LCP 1.5s
2ページ目: LCP 0.5s (CSS/フォントがキャッシュ)
【100点を目指す: CSSフルインライン化】
初回訪問: LCP 1.3s (-200ms)
2ページ目: LCP 0.8s (+300ms) ❌結論 : 100点を取っても、 実際のユーザー体験は悪化する 。
Lighthouseスコアの本質
Lighthouseは初回訪問のみを測定する
- 2ページ目以降のキャッシュ効果は評価されない
- 100点を目指すことで、実際のユーザー体験が犠牲になる場合がある
99点と100点の実用的な違い
実用的なパフォーマンス比較:
【現状: 99点】
初回訪問: 1.5s (非常に高速)
2ページ目: 0.5s (キャッシュが効く)
3ページ目: 0.5s (キャッシュが効く)
【もし100点を目指してCSSをインライン化していたら】
初回訪問: 1.3s (少し速い)
2ページ目: 0.8s (キャッシュが効かない)
3ページ目: 0.8s (キャッシュが効かない)総合的には99点のほうが速い。
やらなかったこと・その理由
AIとの協調開発における統制 : 以下は、Lighthouseが提案し、AIも「実装しましょう」と提案してきた施策です。しかし、私はこれらを 意図的に却下 しました。なぜなら、測定ツールが評価する指標と、実際のビジネス価値が一致しないからです。
1. CSSフルインライン化 (17 KB)
LighthouseとAIの提案 : 全CSSをHTML内に埋め込んで初回ロードを高速化
やらなかった理由:
- 初回: -200ms
- 2ページ目以降: +300ms (キャッシュ不可)
- HTMLサイズ: +17 KB (毎ページ送信)
- メンテナンス性: 大幅悪化
判断 : 実用上マイナス
2. font-display: optional + preload
Lighthouseの提案 : フォントをpreloadして高優先度でダウンロード
やらなかった理由:
- 効果: +0.5点程度
- リスク: フォントファイル名がビルド時に変わる (ハッシュ付き)
- 副作用: 他のリソースとの帯域競合
判断 : 99点で十分
3. 未使用JS削減 (27 KB, 40%)
Lighthouseの提案 : 未使用コードを動的インポートで削減
やらなかった理由:
- 複雑性: コード分割とエラーハンドリングの増加
- トレードオフ: 追加のHTTPリクエスト
- 効果: 限定的 (TBT 0ms を維持)
判断 : 優先度低
教訓・気づき
1. 測定ツールとSEO、そしてビジネスの生存戦略
最も重要な気づきは、 Lighthouseスコア ≠ SEO ≠ ビジネス価値 ということです。
Lighthouseが測定するもの:
- 初回訪問のパフォーマンスのみ
- 2ページ目以降のキャッシュ効果は評価されない
SEOが評価するもの（検索エンジンの本質）:
- 実際のユーザーが体験するページ速度（2ページ目以降含む）
- 直帰率、滞在時間、回遊率（これらは2ページ目以降の速度に依存）
ビジネスの生存に必要なもの:
- ユーザーが再訪したくなる体験（= 2ページ目以降の快適さ）
- 長期的に保守可能なコードベース
CSSインライン化の罠（AIが提案する典型例）:
- Lighthouse: 100点 （初回が速い）
- 実際のユーザー: 遅い ❌（キャッシュが効かない）
- SEO: 直帰率悪化 ❌（2ページ目が遅い）
- ビジネス: コスト増 ❌（メンテナンス不可）
2. 99点は実用上完璧
99点と100点の実用的な違い:
| スコア | 初回LCP | 2ページ目LCP | 総合評価 |
|---|---|---|---|
| 99点 | 1.5s | 0.5s | ⭐⭐⭐⭐⭐ |
| 100点 | 1.3s | 0.8s | ⭐⭐⭐⭐ |
結論 : 99点のほうがユーザー体験が良い。
3. AIとの協調開発における統制の3原則
AIが提案する最適化を制御するための判断基準:
測定ツールの本質を理解する
- Lighthouseは初回訪問のみを評価（AIはこれを知らない）
- SEOは2ページ目以降のユーザー体験も評価
- ビジネスの生存には長期的な保守性が必要
トレードオフを4軸で評価する
- 初回 vs 2ページ目以降（ユーザー体験）
- パフォーマンス vs メンテナンス性（コスト）
- 測定ツールのスコア vs SEO評価（検索順位）
- 短期的な数値 vs 長期的なビジネス価値（生存戦略）
AIを制御する（統制の実践）
- AIの提案を無批判に受け入れない
- 「なぜこの最適化が必要か？」を問い続ける
- ビジネス価値に直結しない施策は99点で止める
まとめ
達成したこと
- Performance 99点 : 実用上完璧
- Element Render Delay 84%削減 : 1,300ms → 210ms
- アーキテクチャ維持 : メンテナンス性保持
- トレードオフ理解 : 実用的な判断
学んだこと
- 測定ツール ≠ SEO ≠ ビジネス価値 : Lighthouseは初回訪問のみ。SEOとビジネスの生存には2ページ目以降の体験が重要
- AIの提案を統制する : AIは測定ツールが喜ぶコードを生成するが、それがビジネス価値に直結するとは限らない
- 99点で止める勇気 : 100点を追わず、実用的なパフォーマンスとアーキテクチャの両立を選ぶ
次のステップ（AIコーダーへの実践ガイド）
もしあなたが94点で悩んでいるなら、以下の優先順位で実装し、 AIの提案は批判的に評価してください ：
- 外部資産の完全自律化 (詳細は有料部分を参照)
- ブラウザ解釈プロセスの最適化 (詳細は有料部分を参照)
- 配信資産の最適化 (詳細は有料部分を参照)
- クリティカルな記述の最小限化 (詳細は有料部分を参照)
そして、99点で止める。
AIが「100点にしましょう」と提案してきても、 ビジネス価値に直結しない施策は却下する勇気 を持つこと。
それが、AIとの協調開発における統制であり、持続可能なWeb開発の道です。