ログイン機能追加後のLighthouse測定結果 - 92点という現実と予想外の改善
はじめに
ログイン機能を追加したらブログ一覧ページのLighthouse Performanceが100点から92点に低下しました。
原因はレンダリングブロックCSS（1,050ms）と強制リフロー。逆に未使用JavaScriptは3.1 KiB削減されるという予想外の結果も出ました。
完璧なスコアが崩れた瞬間、あなたなら何を考えますか？
Lighthouseで全カテゴリ100点を達成した。
CSS最適化で22 KiBを削減し、モバイルパフォーマンスも完璧だった。
次はログイン機能を追加して、さらに機能を充実させよう。
しかし、プレビュー環境でLighthouse測定を実施した瞬間、目を疑った。
ブログ一覧ページのPerformanceスコアが92点に低下している。
「ログイン機能を追加しただけなのに、なぜ？」
「JavaScriptが増えたから？CSSが増えたから？」
「それとも、認証チェックのオーバーヘッド？」
測定を進めるうちに、予想外の発見があった。
未使用JavaScriptが39 KiBから35.9 KiBへと、逆に3.1 KiB削減されていた。
しかし同時に、 レンダリングブロックCSSが1,050 msという深刻な数値 を示していた。
この記事をお勧めしない人
- Lighthouseのスコアなんて気にしない、動けばいいという人。
- 測定結果の数値を見ても、何も感じない人。
- 改善計画なんて後回しでいい、今すぐ新機能を実装したい人。
もし一つでも当てはまらないなら、読み進める価値があるかもしれません。
機能追加の裏で進行する体験の劣化
- 機能追加のたびにパフォーマンスが悪化することを放置すると、あなたのサイトには「見えないパフォーマンス負債」が蓄積されていきます。
- やがて、ユーザーは遅いページ表示にストレスを感じ、離脱率が上昇し、ビジネスに直接的な損失をもたらすでしょう。
- ついに、原因を特定しようとしても、どの機能追加が問題だったのか分からず、大規模なリファクタリングを強いられることになります。
継続的な測定がもたらす品質の安定
- この記事を読めば、機能追加後のパフォーマンス影響を定量的に測定し、問題を早期に発見する具体的な手法が手に入ります。
- 具体的には、ログイン機能追加による影響の実測データ、レンダリングブロックCSSという具体的な問題、そして予想外のJavaScript削減という発見を手に入れられます。
- この方法は、机上の空論ではありません。まさに このブログ自身で実践し、92点という現実と向き合った一次情報 です。
- この情報は、単なる測定結果ではなく、AIと協業しながら継続的にパフォーマンスを監視し、 問題を可視化して改善につなげる 未来の開発現場から得られた実践知です。
私も同じでした
筆者も過去に、機能追加のたびにパフォーマンスが悪化し、原因特定に苦労した経験があります。
このブログを「AIによる実装」と「人間による設計」で作り上げる過程で、継続的な測定と影響評価の重要性を痛感しました。
この記事で、機能追加前後のパフォーマンス変化を可視化し、問題を早期に発見する方法、そして 予想外の改善も含めた包括的な分析手法 を持ち帰れるように書きました。
さらに深掘りして、レンダリングブロックCSSの根本原因や、ページごとに異なるパフォーマンスが示す設計の課題を知りたい方は、その詳細な実装方法を確認できます。
背景：影響調査計画の策定
前回の記事「ログイン機能追加後のLighthouse影響調査計画」では、体系的な測定計画を立案しました：
- 測定対象 : ブログ一覧ページ、ブログ記事詳細ページ
- 評価基準 : Performance 95点以上、その他100点
- 測定環境 : Cloudflare Pages プレビュー環境
- 測定ツール : PageSpeed Insights
今回は、この計画に基づいて実際に測定を実施し、結果を分析します。
測定結果のハイライト
私はログイン機能追加後のLighthouse測定を実行し、以下の結果を得ました：
| 指標 | 測定結果 | 評価 |
|---|---|---|
| ブログ一覧ページ Performance | 92点 | ❌ 基準（95点）を3点下回る |
| ブログ記事詳細ページ Performance | 94点 | ❌ 基準（95点）を1点下回る |
| 未使用JavaScript | 35.9 KiB | -3.1 KiB改善（予想外） |
| レンダリングブロックCSS | 1,050 ms | ❌ 両ページ共通の課題 |
予想外の発見 : ログイン機能を追加したのに、JavaScriptが3.1 KiB削減されました。
最大の課題 : レンダリングブロックCSSが1,050 msという深刻な数値を示しています。
AIが見逃す測定の本質
ここで重要な警告があります。
AIに「ログイン機能を追加したら92点になった。改善して」と頼むと、高確率で以下のような提案が返ってきます：
- 「JavaScriptを削減しましょう」
- 「CSSを圧縮しましょう」
- 「画像を最適化しましょう」
しかし、これらは 測定データを見ずに提案する対症療法 です。実際には、JavaScriptは削減されており（-3.1 KiB）、問題はレンダリングブロックCSS（1,050 ms）という別の場所にあります。
根本原因は、 AIが表面的なスコアしか見ず、パフォーマンス指標の内訳を分析しない ことにありました。人間は「なぜ92点なのか」「どの指標が悪化したのか」を定量的に分析し、真の問題を特定する必要があります。
ここから先は、AIが絶対に教えてくれない 「測定データから問題を特定する分析手法」 の全貌と、具体的な測定データ、そしてレンダリングブロックCSSという真の原因を、すべて公開します。
この分析手法をコピーすれば、AIの表面的な提案を回避し、 データに基づいた的確な改善 を実現できます。私が2日間かけて検証した測定データと分析手法を、ここで全て公開します。
詳細な測定データと分析
では、実際にどのような測定を行い、どのようにデータを分析したのか。具体的な測定結果、ページごとの比較、そしてレンダリングブロックCSSという根本原因の特定プロセスを、すべて公開します。
この測定データは、ClaudeMix本番環境で実際に取得した一次情報です。同じ測定手法を使えば、あなたのプロジェクトでも再現可能です。
ブログ一覧ページ（Mobile）
測定日時 : 2026-01-13 22:21
URL: https://claude-lighthouse-impact-ass.claudemix.pages.dev/blog
ブログ一覧ページのスコア
| カテゴリ | 測定値 | 基準値 | 差分 | 評価 |
|---|---|---|---|---|
| Performance | 92点 | 100点 | -8点 | ❌ 要改善 |
| Accessibility | 100点 | 100点 | ±0点 | 維持 |
| Best Practices | 100点 | 100点 | ±0点 | 維持 |
| SEO | 100点 | 100点 | ±0点 | 維持 |
ブログ一覧ページのパフォーマンス指標
| 指標 | 測定値 |
|---|---|
| クリティカルパスの最大待ち時間 | 366 ms |
| レンダリングブロック合計 | 10.4 KiB、1,050 ms |
| 強制リフロー | 84 ms |
ブログ一覧ページの未使用リソース
| リソース | 測定値 | 基準値 | 変化量 | 評価 |
|---|---|---|---|---|
| 未使用JavaScript | 35.9 KiB | 39 KiB | -3.1 KiB | 改善！ |
ブログ記事詳細ページ（Mobile）
測定日時 : 2026-01-13 22:28（再測定）
URL: https://claude-lighthouse-impact-ass.claudemix.pages.dev/blog/welcome
ブログ記事詳細ページのスコア
| カテゴリ | 測定値 | 基準値 | 差分 | 評価 |
|---|---|---|---|---|
| Performance | 94点 | 100点 | -6点 | ⚠️ 要改善 |
| Accessibility | 100点 | 100点 | ±0点 | 維持 |
| Best Practices | 100点 | 100点 | ±0点 | 維持 |
| SEO | 100点 | 100点 | ±0点 | 維持 |
※ 初回測定（タイポURL /blog/welcom）でSEO 82点、Best Practices 96点だったが、正しいURLで再測定したところ両方とも100点に戻った
ブログ記事詳細ページのパフォーマンス指標
| 指標 | 測定値 | 評価 |
|---|---|---|
| FCP (First Contentful Paint) | 2.5秒 | ⚠️ 改善の余地 |
| LCP (Largest Contentful Paint) | 2.5秒 | ⚠️ 改善の余地 |
| TBT (Total Blocking Time) | 0ミリ秒 | 完璧 |
| CLS (Cumulative Layout Shift) | 0.001 | 優秀 |
| Speed Index | 2.7秒 | ⚠️ 改善の余地 |
レンダリングブロックCSS（ブログ一覧と同じ問題）
| URL | サイズ | 継続時間 |
|---|---|---|
| /assets/entry-CsOEOGy4.css | 6.3 KiB | 150 ms |
| /assets/blog-bXPeX5g8.css | 2.2 KiB | 450 ms |
| /assets/layer2-common-NqDfPqty.css | 1.9 KiB | 450 ms |
| 合計 | 10.4 KiB | 1,050 ms |
ブログ記事詳細ページの未使用リソース
| リソース | 測定値 | 基準値 | 変化量 | 評価 |
|---|---|---|---|---|
| 未使用JavaScript | 38.1 KiB | 39 KiB | -0.9 KiB | 改善 |
影響分析
ポジティブな影響
1. 予想外のJavaScript削減
39 KiB → 35.9 KiB（-3.1 KiB、約8%削減）驚くべき発見 : ログイン機能を追加したのに、JavaScriptが減少した。
推測される理由 :
- コード分割が改善された可能性
- Remix/Viteの共有バンドル戦略が最適化された
- 不要なコンポーネントの遅延読み込みが機能している
2. SEO、Best Practices、Accessibilityは100点を維持
- 両方のページでSEO 100点
- 両方のページでBest Practices 100点
- 両方のページでAccessibility 100点
- アクセシビリティの配慮が継続されている
⚠️ ネガティブな影響
1. 両方のページでPerformanceスコアが低下
ブログ一覧ページ :
100点 → 92点（-8点）
評価基準（95点以上）を3点下回る ❌ブログ記事詳細ページ :
100点 → 94点（-6点）
評価基準（95点以上）を1点下回る ❌2. レンダリングブロックCSS（最大の問題）
合計: 10.4 KiB、1,050 ms
詳細:
- /assets/blog-BlFJldfD.css: 2.2 KiB、450 ms
- /assets/layer2-common-NqDfPqty.css: 1.9 KiB、450 ms
- /assets/entry-CsOEOGy4.css: 6.3 KiB、150 ms分析 : CSSの読み込みで1秒以上ブロック。ログイン機能追加により、entry-CsOEOGy4.cssのサイズが増加した可能性。
3. 強制リフロー（84 ms）
- JavaScriptによるDOM操作が強制リフローを引き起こしている
- ログインボタンやナビゲーション分岐の実装が影響している可能性
興味深い発見
両方のページで共通する問題
| ページ | Performance | 共通問題 |
|---|---|---|
| ブログ一覧 | 92点 | レンダリングブロックCSS（1,050 ms）、強制リフロー（84 ms） |
| ブログ記事詳細 | 94点 | レンダリングブロックCSS（1,050 ms） |
重要な発見 : 両方のページで レンダリングブロックCSSが1,050 ms という同じ問題が発生している。
なぜスコアに2点の差があるのか？
強制リフローの有無
- ブログ一覧: 84 ms の強制リフロー（フィルター機能、Load Moreボタンの影響）
- ブログ記事詳細: 強制リフローなし
FCP/LCPの差
- ブログ一覧: データなし（測定時は良好と推測）
- ブログ記事詳細: FCP 2.5s、LCP 2.5s（改善の余地）
CSSファイルの構成は異なる
- ブログ一覧:
blog-BlFJldfD.css（2.2 KiB） - ブログ記事詳細:
blog-bXPeX5g8.css（2.2 KiB） - 共通:
entry-CsOEOGy4.css（6.3 KiB）、layer2-common-NqDfPqty.css（1.9 KiB）
- ブログ一覧:
未使用JavaScript削減の謎
予想 : ログイン機能追加でJavaScriptが増加するはず
現実 : 逆に3.1 KiB削減された
仮説 :
- Remix/Viteの自動最適化が効いている
- ログイン機能のコード分割が適切に行われている
- 以前のバンドルに含まれていた不要なコードが削除された
評価基準との照合
| 項目 | 目標値 | ブログ一覧 | ブログ記事詳細 | 判定 |
|---|---|---|---|---|
| Performanceスコア | ≥ 95点 | 92点 | 94点 | ❌ 両方とも不合格 |
| その他スコア | = 100点 | 100点 | 100点 | 両方とも合格 |
| JavaScript増加 | ≤ +5 KiB | -3.1 KiB | -0.9 KiB | 合格（むしろ改善） |
| CSS増加 | ≤ +2 KiB | 不明 | 不明 | - |
総合判定 : ⚠️ 両ページでPerformance改善が必要
共通課題 : レンダリングブロックCSS（1,050 ms）が両ページのパフォーマンス低下の主因
今後の改善計画
優先度1: 両ページのPerformance改善（レンダリングブロックCSS対策）
目標 :
- ブログ一覧ページ: 92点 → 95点以上
- ブログ記事詳細ページ: 94点 → 95点以上
共通問題 : レンダリングブロックCSS（1,050 ms）
改善策 :
クリティカルCSSのインライン化
- ファーストビューに必要な最小限のCSSをHTMLに埋め込む
- 残りのCSSは非同期読み込み
- 効果: 両ページで1秒以上の改善が見込まれる
CSSのプリロード設定
<link rel="preload">でCSSを事前読み込み- レンダリングをブロックしない
- Remixの
links関数で実装可能
強制リフローの最適化（ブログ一覧ページのみ）
- DOM操作のタイミングを最適化
- バッチ処理でレイアウト再計算を削減
- フィルター機能とLoad Moreボタンの処理を見直し
優先度2: セキュリティヘッダーの追加（将来的な改善）
現状 : SEO、Best Practices、Accessibilityは全て100点を維持
将来的な改善 : Cloudflare Pagesでセキュリティヘッダーを追加
- CSP（Content Security Policy）
- HSTS（HTTP Strict Transport Security）
- COOP（Cross-Origin-Opener-Policy）
- XFO（X-Frame-Options）
- Trusted Types
※ 現時点では緊急性は低いが、Best Practicesをさらに強化するための施策
今回の学びと感想
Lighthouse測定を通じて、最も重要だと感じたのは 「予想と現実のギャップから学ぶ」 という姿勢でした。
予想外の発見
ログイン機能を追加すれば、JavaScriptが増えてパフォーマンスが悪化すると予想していました。
しかし、実際には：
- JavaScriptが3.1 KiB削減された
- 両方のページでレンダリングブロックCSSが同じ問題を抱えている
- ブログ一覧92点、ブログ記事詳細94点の両方が基準（95点）を下回る
この「予想外の改善」は、Remix/Viteの自動最適化やコード分割が効いている証拠です。
レンダリングブロックCSSという共通の課題
同じログイン機能を追加したのに、両方のページで レンダリングブロックCSSが1,050 ms という共通の問題が発生している。
これは、 サイト全体のCSS配信戦略の見直しが必要 であることを示しています。
ページ個別の最適化ではなく、CSS配信の全体最適化が必要 という教訓を得ました。
レンダリングブロックCSSという壁
レンダリングブロックCSSは、以前の最適化では解決できなかった問題です。
CSSファイルを分割しても、読み込み順序や方法を最適化しなければ、パフォーマンスは改善しません。
今回の測定で、次の改善ターゲットが明確になりました。
継続的な測定の重要性
機能追加のたびに測定を実施することで、問題を早期に発見できます。
今回の測定では、以下を可視化できました：
- ブログ一覧ページのPerformanceが92点に低下
- レンダリングブロックCSSが1,050 ms
- 未使用JavaScriptが3.1 KiB削減
測定せずに進めていたら、これらの問題は見過ごされていたでしょう。
まとめ
ログイン機能追加後のLighthouse測定を実施し、以下の結果を得ました：
最終結果のサマリー
- ブログ一覧ページ : Performance 92点（-8点） ❌
- ブログ記事詳細ページ : Performance 94点（-6点） ❌
- 未使用JavaScript: 35.9 KiB（-3.1 KiB）
- レンダリングブロックCSS: 1,050 ms（両ページ共通） ❌
重要な発見事項
- 予想外の改善 : JavaScriptが3.1 KiB削減
- 両ページに共通の課題 : レンダリングブロックCSS 1,050 ms
- 明確な問題 : サイト全体のCSS配信戦略の見直しが必要
今後の対応
- レンダリングブロックCSS対策（クリティカルCSS、プリロード）
- 強制リフローの最適化
- SEOとBest Practicesの再確認
- 改善後の再測定
次回記事 : Lighthouse 99点で止めた理由 - 100点を追わないパフォーマンス最適化戦略
同じような課題で悩んだ方はいませんか？
もっと良い改善方法があれば教えてください！