前回の可用性から、体感速度へ
前回のS-06では、可用性という「どれだけ動いていれば合格か」の目標値を学びました。動いていることは大前提として、利用者が次に気にするのは「速いかどうか」です。サーバーが正常に応答していても、画面の表示が遅ければ、利用者にとってはやはり遅いアプリです。この講義では、性能を利用者の体感の側から測る指標、Core Web Vitalsを扱います。
このスライドのポイント
- S-06では「どれだけ動いていれば合格か」の目標値（可用性・SLO）を学んだ
- 動いているのは大前提。次に利用者が気にするのは「速いかどうか」
- サーバーが正常に応答していても、画面表示が遅ければ利用者には遅いアプリ
- この講義は、性能を利用者の体感の側から測る指標を扱う
Core Web Vitalsとは
Core Web Vitalsとは、Webページの体験品質を測る標準指標群です。Googleが提唱しており、具体的な指標名や合格とされる閾値は今後更新されうるため、最新の基準は公式情報で確認してください。中身は3つの観点に整理できます。1つ目は読み込みの速さ、つまり主要な内容が画面に表示されるまでの時間です。2つ目は操作への反応で、押してから応答が返るまでの速さ、H-08で学んだフィードバックを数値で測るものです。3つ目は表示の安定で、読み込みの途中でレイアウトがガタつかないかです。D-09で見た表示の7段階が、体感の数値になったものと考えてください。
このスライドのポイント
- Core Web Vitals＝Webページの体験品質を測る標準指標群（提唱: Google）
- 具体的な指標名・閾値は更新されうる（volatile）。最新基準は公式情報で確認する
- 3観点: ①読み込みの速さ（主要な内容が表示されるまで）②操作への反応（押してから応答まで）③表示の安定（読み込み中にレイアウトがガタつかないか）
- D-09で見た表示の7段階が、体感の数値になったもの
なぜ3観点が必要か
この3観点を知らないと、「なんか遅い」という声を、どこの問題か切り分けられません。遅さの原因は、C-10で学んだ回線の3物差しかもしれず、S-04で見たサーバー区間かもしれず、あるいはブラウザ側のこの3観点かもしれません。どの域が原因かで、打つべき対策はまったく変わります。読み込みが遅いなら画像の圧縮、操作反応が鈍いなら処理の分割、表示が不安定ならレイアウトの予約、というように、観点ごとに対策が異なるからです。
このスライドのポイント
- 知らないと「なんか遅い」がどこの問題か切り分けられない
- 遅さの原因は3つの域のどれか: 回線（C-10の3物差し）／サーバー区間（S-04）／ブラウザ側（この3観点）
- どの域が原因かで対策はまったく変わる
- 読み込みが遅い→画像圧縮、操作反応が鈍い→処理の分割、表示が不安定→レイアウトの予約
遅さは3つの域のどこかで起きる
遅さは、回線・サーバー・ブラウザという3つの域のどこかで起きます。C-10は回線の域、S-04のトレースはサーバーの域、そしてCore Web Vitalsはブラウザの域を担当します。ブラウザの域はさらに3観点に分かれ、それぞれに体感の症状と主な原因、対策の方向が対応しています。この棲み分けが頭に入っていると、遅さの相談を受けたときに、まずどの域を疑うかを順に切り分けられます。
このスライドのポイント
- 遅さは回線・サーバー・ブラウザの3域のどこかで発生する
- C-10=回線の域／S-04のトレース=サーバーの域／Core Web Vitals=ブラウザの域
- ブラウザの域はさらに3観点に分かれる
- 各観点に「体感の症状／主な原因／対策の方向」が対応する
経費アプリの申請一覧で見る
公開した経費アプリの申請一覧画面を例に見てみます。開くと表示まで3秒かかりました。原因は領収書のサムネイル画像が重いことで、これは読み込みの観点の問題です。画像の圧縮と、画面に写った分だけ後から読む遅延読み込みで改善できます。一方、ボタンを押したときの反応は速く、操作の観点は問題ありません。ただし表示の途中で一覧がガタッとずれます。これは画像の高さが指定されておらず、後から読み込まれた画像が場所を押し広げるためで、あらかじめ表示領域を予約すれば解決します。観点別に診れば、対策はこのように具体的になります。
このスライドのポイント
- 経費アプリの申請一覧画面を例に3観点で診る
- 読み込み: 表示まで3秒。原因は領収書サムネイルが重い→圧縮と遅延読み込みで改善
- 操作反応: ボタンの反応は速い→問題なし
- 表示の安定: 表示中に一覧がガタつく。原因は画像の高さ未指定→表示領域の予約で解決
技術サンプル: 3観点の診断表
この講義の道具として、遅さを切り分ける診断表を用意しました。表は3観点それぞれについて、体感の症状、主な原因の層、対策の方向を1行にまとめています。読み方のコツは、まず利用者の訴えがどの症状に当たるかを探し、その行の原因層と対策へたどることです。計測自体はブラウザの開発ツールや公開の計測サービスで行えますが、その操作手順はこの講義では扱いません。AIには、この画面のCore Web Vitalsを改善したい、3観点のどれが悪いかの計測方法と観点別の対策を提案してほしい、と依頼すると、診断から対策まで具体化できます。
このスライドのポイント
- 種別: table
- 目的: 体感速度の遅さを3観点に切り分け、観点ごとの対策方向を決める
- サンプル本体:
混同しやすい: サーバーが速い vs 体感が速い
混同しやすいのが、サーバーが速いことと、体感が速いことの違いです。S-04のトレースで見たサーバー区間が200ミリ秒で応答していても、その先で10メガバイトの画像を送っていれば、利用者にとっては遅いアプリです。サーバーの速さはブラウザの域より手前の話で、体感速度はそこにブラウザ側の3観点が加わって決まります。だから、サーバーは速いのに遅いと言われる、という一見矛盾した状況が起こり得ます。
このスライドのポイント
- 「サーバーが速い（S-04の区間）」と「体感が速い（ブラウザ側の3観点込み）」は別
- サーバーが200ミリ秒で応答しても、画像が10メガバイトなら利用者には遅い
- 体感速度＝サーバーの速さ＋ブラウザ側の3観点
- だから「サーバーは速いのに遅いと言われる」が起こり得る
バイブコーディングでの確認点
バイブコーディングでは、画面をAIに作らせた後の確認が効きます。特に、画像のサイズ指定と圧縮、そして読み込み中のレイアウト予約はされていますか、と聞いてください。この3点は体感品質の大部分を左右する基本でありながら、指定しないと省かれがちだからです。AIは見た目が整ったコードを返せますが、体感速度まで気を配るとは限りません。だからこそ、観点の言葉で明示的に確認することが大切です。
このスライドのポイント
- 画面をAIに作らせたら、体感速度の基本3点を確認する
- 質問例: 「画像のサイズ指定と圧縮、読み込み中のレイアウト予約はされていますか」
- この3点は体感品質の大部分を左右するが、指定しないと省かれがち
- AIは見た目が整ったコードを返せても、体感速度まで気を配るとは限らない
まとめと次回
一問一答です。体感速度の3観点は何でしょうか。（間）答えは、読み込みの速さ、操作への反応、表示の安定の3つです。30秒まとめとして、Core Web Vitalsはブラウザの域で体感速度を測る指標群であり、どの観点が悪いかで対策が変わること、そして指標名や閾値は更新されうるので最新基準は公式で確認すること、この2点を押さえてください。次回のS-08では、速さと負荷を同時に改善するキャッシュとCDNへ進みます。関連資料は「UI改善プロンプト50」と「AIアプリの品質評価シート」です。
このスライドのポイント
- 一問一答: 体感速度の3観点は？ → 読み込みの速さ・操作への反応・表示の安定
- 30秒まとめ: Core Web Vitalsはブラウザの域で体感速度を測る指標群。どの観点が悪いかで対策が変わる。指標名・閾値は更新されうるので最新基準は公式で確認
- 次回: S-08 キャッシュとCDN（速さと負荷を同時に改善する仕組み）
- 関連資料: 「UI改善プロンプト50」「AIアプリの品質評価シート」
