Project事例
Web不具合診断
3つの症状を、原因と再発防止まで追う
公開サイトで起きた3件の修正履歴をもとに、いきなり本番を触らず、再現条件と安全な変更範囲を決める診断の流れを紹介します。
自社の記録 事例一覧へ戻る
Summary 要点と証拠
最初に記録の要点を見る
表示が遅い、余白が消えた、文字が崩れたという3つの症状を、再現条件、原因、影響、修正、再発防止の順で記録しました。原因を決めつけず、修正できる範囲が分かってから小さく直す流れを確認できます。
秒数の記録
0〜5秒の同じ目盛り
| 記録 | 測ったもの | 値 | 時期と根拠 |
|---|---|---|---|
| 初回表示 | 操作できるまでの待ち時間 | 修正前 3.9秒、修正後 2.3〜2.4秒 | 演出時間の修正前後。修正前の3.9秒と、修正後の2.3〜2.4秒を比較 |
| LCPの揺れ | 最大コンテンツの表示時間 | 揺れた幅 1.3〜4.8秒、中央値 3.98秒 | 初回表示を直した後に計測。揺れた幅と、5回計測した中央値 |
フォントのdata URI化とCSPの不一致を修正
Method 課題と進め方
困りごとを分けて触る範囲を決める
扱った課題
- 同じ症状でも、画面、回線、訪問回数によって再現したりしなかったりする状態だった。
- 見た目を直す変更が、速度やセキュリティの別の問題を生まない範囲を決める必要があった。
進め方と判断
- 本番と同じ条件で症状を再現し、測定値、画面記録、ブラウザーのエラーを先に残した。
- 変更候補を一つずつ切り分け、原因と関係しない場所を触らないようにした。
- 修正後に同じ条件で再確認し、テスト、共通ルール、設定値の正本化で再発を検知できるようにした。
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件のエラーが出ていた。フォントを通常のファイルとして配信し、許可する取得元と実際の配信方法を揃えた。
見た目だけを直すのではなく、セキュリティ設定を保ったまま文字表示を直すことを条件にした。
Handover 残したもの
作業のあとに使える形を残す
完成後に残るもの
- 01
再現条件・原因候補・影響・修正可否をまとめた診断記録
- 02
安全な範囲に絞ったコード差分
- 03
同じ症状を検知する確認手順またはテスト
担当した範囲
- 症状の再現
- 原因の切り分け
- 影響範囲の確認
- 小修正
- 再発防止テスト
使用した技術と道具
- Astro
- TypeScript
- CSS
- Lighthouse
- Content Security Policy
Related 頼むなら
似た困りごとを相談するときに
同じ進め方がそのまま当てはまるとは限りません。今の状況を聞いて、必要な範囲から決めます。
