Works / Project
Web不具合診断 3つの症状を、原因と再発防止まで追う
公開サイトで起きた3件の修正履歴をもとに、いきなり本番を触らず、再現条件と安全な変更範囲を決める診断の流れを紹介します。
Diagnosis
症状を再現し、直せる範囲を決めてから触る
- 01 Case 01 初回表示が遅い 演出時間とLCPを切り分け 確認済み
- 02 Case 02 左右の余白が消える 共通クラスの競合を特定 確認済み
- 03 Case 03 文字とエラーが崩れる フォント配信とCSPを確認 確認済み
30 Second Brief
30秒でわかる要点
表示が遅い、余白が消えた、文字が崩れたという3つの症状を、再現条件、原因、影響、修正、再発防止の順で記録しました。原因を決めつけず、修正できる範囲が分かってから小さく直す流れを確認できます。
Challenge
扱った課題
- 同じ症状でも、画面、回線、訪問回数によって再現したりしなかったりする状態だった。
- 見た目を直す変更が、速度やセキュリティの別の問題を生まない範囲を決める必要があった。
Approach
進め方と判断
- 本番と同じ条件で症状を再現し、測定値、画面記録、ブラウザーのエラーを先に残した。
- 変更候補を一つずつ切り分け、原因と関係しない場所を触らないようにした。
- 修正後に同じ条件で再確認し、テスト、共通ルール、設定値の正本化で再発を検知できるようにした。
Artifacts
完成後に残るもの
- 01
再現条件・原因候補・影響・修正可否をまとめた診断記録
- 02
安全な範囲に絞ったコード差分
- 03
同じ症状を検知する確認手順またはテスト
Evidence
確認できる証拠
数字だけに寄せず、実際の成果物と確認結果を記録しています。
イントロが画面を塞ぐ時間を実測して短縮
5回計測で原因となる要素の不安定化を確認
フォントのdata URI化とCSPの不一致を修正
Record
詳しい記録
共通の診断手順
- 発生した画面、端末、操作、時刻を揃えて症状を再現する
- 直前の変更、ブラウザーの記録、計測値から原因候補を絞る
- 影響する範囲と、元に戻せる方法を確認する
- 原因に関係する最小の場所だけを変更する
- 同じ条件で再確認し、次回の検知方法を残す
Case 01：初回表示が遅い
初回訪問時だけ、画面が約3.9秒間操作できない状態になっていた。表示演出の時間がコードへ直接書かれ、設計上の2.5秒以内というルールとずれていたことが原因だった。設定値を一箇所へまとめ、画面が使えるまでの時間を2.3〜2.4秒へ短縮した。
その後も計測値が1.3〜4.8秒の間で揺れたため、5回計測して要素を比較した。後から表示される大きな文字がLCPとして選ばれていたため、その文字を最初から表示し、計測対象が実行ごとに変わらないようにした。
Case 02：左右の余白が消える
スマートフォンでは内容が画面端へ付き、デスクトップでは本文幅が意図より狭くなっていた。共通の .container という名前がTailwindの同名ルールと競合し、後から読み込まれた設定で上書きされていた。
読み込み順に偶然勝つ修正ではなく、共通レイアウトのルールを後段へ置き、意図しない最大幅を打ち消した。主要画面幅のスクリーンショットを再確認し、同じ競合を見つけられるようにした。
Case 03：文字表示とエラーが崩れる
フォントがdata URIとしてHTMLへ埋め込まれ、セキュリティ設定と一致せず、ブラウザーの記録へ56件のエラーが出ていた。フォントを通常のファイルとして配信し、許可する取得元と実際の配信方法を揃えた。
見た目だけを直すのではなく、セキュリティ設定を保ったまま文字表示を直すことを条件にした。
Scope
担当した範囲
- 症状の再現
- 原因の切り分け
- 影響範囲の確認
- 小修正
- 再発防止テスト
Tools
使用した技術・道具
- Astro
- TypeScript
- CSS
- Lighthouse
- Content Security Policy
Related Service
90分診断から始める、3時間上限のWeb緊急小修正
症状を再現し、原因候補と安全な変更範囲を整理してから修正します。