ログイン機能追加後のLighthouse影響調査計画 - 100点スコアを維持できるのか
はじめに
Lighthouse全カテゴリ100点を達成した直後にログイン機能を追加したため、パフォーマンスへの影響を事前に測定する必要が生じました。測定対象・評価基準・実測・分析の4ステップで体系化した影響調査計画を事前に作ることで、機能追加後の劣化を「計画外の驚き」にせずに済みます。
機能追加でパフォーマンスが悪化した経験はありませんか？
Lighthouseで全カテゴリ100点を達成した。
CSS最適化で22 KiBを削減し、モバイルパフォーマンスも完璧だった。
しかし、ログイン機能を追加した瞬間、不安がよぎった。
「セッション管理のコード、認証チェックのロジック、ヘッダーのUI変更…これらは、あの完璧なスコアにどれだけ影響するのか？」
測定せずに進めば、気づいたときにはスコアが大幅に悪化しているかもしれない。
しかし、やみくもに測定しても、何を基準に判断すればいいのか分からない。
この記事をお勧めしない人
- パフォーマンス測定なんて時間の無駄だと考える人。
- 機能追加による影響を測定する必要性を感じない人。
- Lighthouseスコアは一度測れば十分で、継続的な監視は不要だと考える人。
もし一つでも当てはまらないなら、読み進める価値があるかもしれません。
盲目的な機能追加が招くパフォーマンスの崩壊
- 機能追加による影響を測定せずに進めると、サイトには「見えないパフォーマンス負債」が蓄積されていきます。
- ユーザーは遅いページ表示にストレスを感じ、離脱率が上昇し、ビジネスに直接的な損失をもたらす。
- 原因を特定しようとしても、どの変更が問題だったのか分からず、大規模なリファクタリングを強いられることになる。
数値に基づく確信ある開発
- この記事を読めば、機能追加後のパフォーマンス影響を体系的に測定し、早期に問題を発見する具体的な手法が手に入ります。
- 測定対象の選定、評価基準の設定、実測、分析までを網羅した完全な調査計画のテンプレートを確認できます。
- 本ブログ自身で実践するために設計され、再現可能な手順として体系化された手法を学べます。
- AIと協業しながら継続的にパフォーマンスを監視し、品質を維持するための具体的な基準が手に入ります。
私も同じでした
筆者も過去に、機能追加のたびにパフォーマンスが悪化し、原因特定に苦労した経験があります。
このブログを「AIによる実装」と「人間による設計」で作り上げる過程で、継続的な測定と影響評価の重要性を痛感しました。
この記事で、機能追加前後のパフォーマンス変化を可視化し、問題を早期に発見する方法を持ち帰れるように書きました。
背景：これまでのLighthouse改善の歴史
ログイン導入前の改善実績
このプロジェクトでは、ログイン機能を導入する前に、以下のLighthouse改善を実施していました：
1. モバイルスコア完全合格（2025-12-18）
達成 : 全カテゴリ100点
| カテゴリ | Before | After | 改善 |
|---|---|---|---|
| Performance | 85点 | 100点 | +15点 |
| Accessibility | 86点 | 100点 | +14点 |
| Best Practices | 100点 | 100点 | 維持 |
| SEO | 82点 | 100点 | +18点 |
主な施策 :
- メタタグの追加（description、OGP、canonical）
- 見出し階層の修正（h1の一意性、階層の論理性）
- コントラスト比の改善（WCAG AA準拠）
- フォント最適化（サブセット化、プリロード）
- Mermaidチャートの遅延読み込み
- 記事表示数の削減（10件 → 6件）
- Viteビルド最適化
成果 : クリティカルパス 478ms → 118ms（75%改善）
詳細: lighthouse-mobile-optimization-perfect-score.md
2. CSS最適化（2025-12-20）
達成 : 未使用CSS 22 KiB削減
手法 : layer2.cssを3ファイルに分割
common.css: 共通スタイルposts.css: 一覧ページ専用post-detail.css: 詳細ページ専用
成果 : CSSサイズ 40.92 kB → 33.02 kB（19.3%削減）
詳細: lighthouse-css-optimization-route-splitting.md
3. JavaScript最適化の壁（2025-12-19）
課題 : 未使用JavaScript 39 KiBは削減不可
理由 : Remix/Viteの共有バンドル戦略による制約
- 複数ルートで共通のコンポーネントを効率的にバンドル
- 個別ルートでの未使用JavaScript削減とトレードオフ
- 全体最適化のための設計思想
判断 : フレームワークの制約を受け入れ、他の最適化に注力
詳細: lighthouse-javascript-optimization-challenges.md
ログイン機能の追加内容
上記の改善を経て、以下のログイン機能を実装しました：
認証機能
- ユーザー登録・ログイン・ログアウト
- セッション管理（Cookie-based）
- パスワードハッシュ化（bcrypt）
UI変更
- ヘッダーにログインボタン追加
- 認証状態によるナビゲーション分岐
- ユーザー情報の表示
認証ページ
- プロフィールページ
- アカウント設定ページ
- 認証が必要なルートの保護
想定される影響
ログイン機能の追加により、以下の影響が想定されます：
JavaScriptサイズの増加
- セッション管理のロジック
- 認証チェックのコード
- フォームバリデーション
CSSサイズの増加
- ログインフォームのスタイル
- ボタンやリンクの追加スタイル
パフォーマンス指標への影響
- セッションチェックによる初期ロード時間の増加
- 認証APIコールのネットワークオーバーヘッド
しかし、 具体的にどの程度の影響があるのか は、実際に測定しなければ分かりません。
私が設計した体系的測定計画
この不確実性に対処するため、私は以下の3つの戦略で体系的な影響調査計画を設計しました：
- 測定対象の戦略的選定 : 公開ページ（ブログ一覧・記事詳細）と認証ページ（プロフィール・設定）を明確に分類し、それぞれの影響を分離して評価
- 客観的評価基準の設定 : Performanceスコア95点以上、JavaScript +5 KiB以内、CSS +2 KiB以内という明確な合格ラインを設定し、感覚的な判断を排除
- 再現可能な測定手順の確立 : Chrome DevToolsを使った詳細な手順書と、チェックリスト、結果記録テンプレートを含む完全な調査ツールキットを構築
その結果、 「やみくもに測定する」のではなく、「問題を早期に発見し、客観的に判断できる」測定の仕組み を手に入れました。
AIが陥る場当たり測定の罠
ここで重要な警告があります。
AIに「ログイン機能を追加したので、パフォーマンスを測定して」と頼むと、高確率で以下のような提案が返ってきます：
- 「とりあえずLighthouseを実行しましょう」
- 「スコアが下がっていたら、その時に対応しましょう」
- 「手動で測定すれば十分です」
しかし、これらは 場当たり的な測定 です。一度測定すれば終わりではなく、将来の機能追加時に「また同じ測定をどうやるんだっけ？」と悩むことになります。
根本原因は、 測定の再現性が欠けている ことにありました。AIは「今回の測定」しか考えませんが、人間は「継続的な測定の仕組み」という、より高次の制約を満たす必要があります。
ここから先は、AIが絶対に提案しない 「体系化された測定計画」 の全貌と、具体的な測定手順、評価基準の設定方法、完全な調査ツールキット（ガイド、チェックリスト、テンプレート）を、すべて公開します。
この手順をコピーすれば、将来の機能追加時にも同じ測定を再現でき、 パフォーマンス監視を自動化された習慣として定着 させられます。私が3日間かけて設計した測定計画と、実践で使用するドキュメントセットを、ここで全て公開します。
影響調査の計画
では、実際に私が設計した測定対象の選定基準、評価基準の具体的な数値、Chrome DevToolsを使った詳細な測定手順、そして完全な調査ツールキット（測定ガイド、チェックリスト、結果記録テンプレート、自動化スクリプト）を公開します。
このドキュメントセットをそのまま使えば、「次の機能追加時にどう測定するか」を毎回悩むことなく、 初回から再現可能な測定 を実現できます。また、なぜ手動測定を推奨するのか、自動化スクリプトの限界、認証ページ測定時の「Clear storage」チェック外しの理由も解説します。
調査の目的
ログイン機能追加による影響を定量的に測定し、以下を明らかにする：
公開ページへの影響 （ログイン不要ページ）
- パフォーマンススコアの変化
- リソースサイズの増加量
- パフォーマンス指標の悪化度
認証ページのパフォーマンス （ログイン必須ページ）
- 認証処理のオーバーヘッド
- ユーザー情報取得のAPIコール影響
改善の必要性の判断
- 許容範囲内かどうかの評価
- 改善が必要な場合の優先順位付け
測定対象ページ
公開ページ（ログイン不要）⭐⭐⭐ 必須
| ページ | URL | 理由 |
|---|---|---|
| ブログ一覧 | /blog |
以前の基準値がある、ユーザー訪問頻度が高い |
| ブログ記事詳細 | /blog/welcome |
以前の基準値がある、コンテンツページの代表 |
認証ページ（ログイン必須）⭐⭐ 推奨
| ページ | URL | 理由 |
|---|---|---|
| プロフィール | /profile |
認証処理の影響を確認 |
| アカウント設定 | /account/settings |
複雑な認証ページの代表 |
測定環境
- 開発サーバー : Wrangler (localhost:8788)
- 測定ツール : Chrome DevTools Lighthouse
- デバイス : Mobile（優先）、Desktop（推奨）
- 測定回数 : 各ページ3回測定して平均値を取る（理想）
評価基準
合格ライン
| 項目 | 目標値 | 判定基準 |
|---|---|---|
| Performanceスコア | ≥ 95点 | 95点以上なら合格 |
| Accessibilityスコア | = 100点 | 100点でなければ要対応 |
| Best Practicesスコア | = 100点 | 100点でなければ要対応 |
| SEOスコア | = 100点 | 100点でなければ要対応 |
| JavaScript増加 | ≤ +5 KiB | 超過時は原因調査 |
| CSS増加 | ≤ +2 KiB | 超過時は原因調査 |
| FCP/LCP悪化 | ≤ +0.5s | 超過時は要対応 |
要対応ライン
上記の基準を満たさない場合は、以下の対応を検討：
クリティカル （即座に対応）
- Performanceスコア 95点未満
- Accessibility/SEOスコア 100点未満
- LCP 2.5秒以上
重要 （近日中に対応）
- Performanceスコア 95-98点
- JavaScript/CSS増加が10%以上
改善検討 （余裕があれば）
- Performanceスコア 98-100点
- JavaScript/CSS増加が5-10%
測定手順
Phase 1: 事前準備
開発サーバーの起動
npm run dev:wranglerアクセス確認
ブラウザで
http://localhost:8788にアクセスして正常に表示されることを確認測定ガイドの確認
tests/lighthouse/MEASUREMENT_GUIDE.mdを開いて手順を確認
Phase 2: 公開ページの測定
各ページで以下の手順を実施：
URLにアクセス
- 例:
http://localhost:8788/blog
- 例:
DevToolsを開く
F12キーを押す- または右クリック → 「検証」を選択
Lighthouseタブを選択
- タブが見つからない場合は
>>アイコンから探す
- タブが見つからない場合は
測定設定
- Mode: Navigation
- Device: Mobile または Desktop を選択
- Categories: すべてにチェック
測定実行
- 「Analyze page load」ボタンをクリック
- 測定完了まで待機（30秒～1分程度）
レポートの保存
- 右上の「💾」アイコンをクリック
- HTMLレポートをダウンロード
tests/lighthouse/reports/に保存
結果の記録
tests/lighthouse/LIGHTHOUSE_RESULTS.mdに記入- スコア、パフォーマンス指標、リソースサイズを記録
Phase 3: 認証ページの測定
ログイン
- テストアカウントでログイン
DevToolsを開く
- ログイン状態を維持したままDevToolsを開く
Lighthouseタブで設定変更
- 重要 : 「Clear storage」のチェックを 外す
- これにより、ログイン状態が維持される
測定実行
- 公開ページと同じ手順で測定
Phase 4: 結果の分析
基準値との比較
- 各スコアの差分を計算
- リソースサイズの変化量を確認
影響評価
- 許容範囲内かどうかを判定
- 悪化している項目の原因を分析
改善計画の立案 （必要な場合）
- 優先順位の高い項目から対応
- 具体的な改善策を検討
成果物：完全な調査ツールキット
この調査計画を実行するため、以下のドキュメントセットを用意しました：
1. プロジェクト概要（README.md）
- 調査の背景と目的
- 測定対象ページの一覧
- 評価基準と期待される成果
- クイックスタートガイド
2. 測定ガイド（MEASUREMENT_GUIDE.md）
- Chrome DevToolsを使った詳細な測定手順
- 測定対象ページとURLの一覧
- トラブルシューティング
- 以前の基準値との比較方法
3. 測定チェックリスト（measurement-checklist.md）
- フェーズごとのチェック項目
- 必須/推奨/任意の優先順位付け
- 評価基準と判定方法
- メモ欄（気づき・改善アイデア・疑問点）
4. 結果記録テンプレート（LIGHTHOUSE_RESULTS.md）
- スコア記録表（基準値との比較）
- パフォーマンス指標記録表
- リソースサイズ記録表
- 次のステップのガイド
5. 自動測定スクリプト（measure-lighthouse.ts）
- 参考用のTypeScriptスクリプト
- Playwrightを使った測定の自動化
- 注意 : 環境によってはブラウザクラッシュの可能性があるため、手動測定を推奨
今回の学びと次のステップ
学んだこと
機能追加前の事前準備の重要性
機能を追加する前に、影響を測定する計画を立てることで、問題を早期に発見できる。
測定の体系化
やみくもに測定するのではなく、対象、基準、手順を明確にすることで、再現可能な調査ができる。
評価基準の設定
許容範囲を事前に定義することで、「改善が必要か」を客観的に判断できる。
ドキュメント化の価値
測定計画をドキュメント化することで、将来の機能追加時にも同じ手法を適用できる。
次のステップ
実際の測定を実施
作成した測定ガイドに従って、Lighthouseスコアを測定する。
結果の分析
測定結果を基準値と比較し、影響を定量的に評価する。
改善計画の立案 （必要な場合）
問題があれば、優先順位を付けて改善策を検討する。
結果のブログ記事化
測定結果と影響分析を次のブログ記事としてまとめる。
同じような課題で悩んだ方はいませんか？
機能追加のたびにパフォーマンスが悪化し、原因特定に苦労した経験はありませんか？
この調査計画が、あなたのプロジェクトでも役立つことを願っています。
もっと良い測定方法や、効率的な影響評価の手法があれば教えてください！
まとめ
ログイン機能追加後のLighthouse影響を調査するため、以下の計画を立案しました：
- 測定対象 : 公開ページ（ブログ一覧・記事詳細）と認証ページ（プロフィール等）
- 評価基準 : Performanceスコア95点以上、JavaScript +5 KiB以内、CSS +2 KiB以内
- 測定手順 : Chrome DevToolsを使った手動測定（3回平均推奨）
- 成果物 : 完全な調査ツールキット（ガイド、チェックリスト、テンプレート）
次は、実際に測定を実施し、結果を分析します。
その結果は、続編のブログ記事として公開予定です。
測定ツールキット : tests/lighthouse/ ディレクトリ
次回記事 : ログイン機能追加後のLighthouse測定結果と影響分析