サーバ側を改善し、応答時間の数値も良くなった。それでも「遅い」と言われることがあります。この食い違いは、測っている対象と人が感じているものが違うことから生まれます。
人が感じる速さは、完了までの時間ではなく、待たされ方で決まります。この回はその差を扱います。
1. 完了時刻を見ても体感は説明できない
同じ「3秒で完了」でも、次の2つはまったく違う体験です。
| 経過 | パターンA | パターンB |
|---|---|---|
| 0.0秒 | 真っ白 | 枠組みが表示される |
| 0.5秒 | 真っ白 | 主要な内容が読める |
| 1.5秒 | 真っ白 | 画像が順次入る |
| 3.0秒 | 一気に全部表示 | 完了 |
| 体感 | 遅い | 速い |
A は3秒間なにも起きません。利用者は壊れているのか判断できず、その不確かさが遅さとして記憶されます。B は0.5秒で読み始められるので、残りの1.5秒は意識されません。
つまり改善すべきは、多くの場合完了までの時間ではなく、最初に意味のあるものが出るまでの時間です。
2. 何を測るか
は、この観点を指標化したものです。表示の速さ・操作への反応・表示のずれという3つの軸で、体感に近いものを測ろうとしています。
- 主要な内容が表示されるまでの時間 — 上の表でいう「読み始められる」タイミング
- 操作に反応するまでの時間 — 押しても何も起きない時間があると、壊れて見える
- 表示のずれ — 読み込みの途中で位置が動くと、押し間違いが起きる
3番目は速さの指標ではありませんが、体感の悪さに直結します。表示された瞬間に押したボタンが、画像の読み込みでずれて別のものになる ── これは遅さ以上に強い不満を生みます。押し間違いは操作のやり直しを生むため、結果的に完了までの時間も伸びます。体感の問題が実測値にも跳ね返る、数少ない例です。
手元の計測は条件が良すぎます。回線が細い、端末が古い、データが多いという条件下での数字が、体感を決めています。EP.1 で扱った「手元と本番は別物」は、フロントでは端末差として現れます。
3. 早く出すための考え方
「最初に意味のあるものを早く出す」ための手段は、突き詰めると3つです。
| 手段 | 内容 | 注意点 |
|---|---|---|
| 分けて出す | 全部揃うのを待たず、揃った部分から表示する | 表示のずれに注意 |
| 後回しにする | すぐ必要でないものは、後から読み込む | 後で必要になったとき待たせない工夫が要る |
| 先に用意しておく | 次に必要になりそうなものを事前に取得する | 使われなければ無駄な通信になる |
「分けて出す」が基本になります。画面全体を1回で作ろうとせず、枠組み → 主要な内容 → 補助的な要素の順に出す。これだけで、上の表のAからBへ変わります。
// 悪い例: すべて揃うまで何も表示しないconst [user, orders, recommendations] = await Promise.all([ fetchUser(), fetchOrders(), fetchRecommendations(),]);render({ user, orders, recommendations });
// 良い例: 重要なものから順に表示していくconst user = await fetchUser();render({ user }); // まず本人の情報を出す
fetchOrders().then((orders) => render({ orders }));// おすすめは補助的なので、遅れて入っても構わないfetchRecommendations().then((r) => render({ recommendations: r }));重要なのは順序の設計です。「利用者が最初に見たいものは何か」を決めて、それを最優先で出す。技術的な依存関係ではなく、読む順序で決めます。
4. 待たせるなら、待っていると分かるように
どうしても時間がかかる処理はあります。その場合、進んでいることが分かるだけで体感は大きく変わります。
- 押した瞬間に反応する — 押せたことが分かれば、その後の待ちは許容されやすい
- 進み具合を出す — 終わりが見えると待てる。件数や割合が有効
- 場所を先に確保する — 表示のずれを防ぐ。読み込み中の枠を最終形と同じ大きさにする
- 操作をすぐ反映する — 通信の完了を待たず、先に画面へ反映して、失敗したら戻す
4番目は効果が大きい反面、失敗時の扱いを設計しないと危険です。反映したのに実は失敗していた、という状態は、遅いことより悪い。失敗したことが確実に伝わる設計とセットで使ってください。
/* 悪い例: 画像が読み込まれた瞬間に、下の要素が押し下げられる */.thumbnail { width: 100%; }
/* 良い例: 縦横比を宣言しておく。読み込み前から場所が確保される */.thumbnail { width: 100%; aspect-ratio: 16 / 9; /* 高さが先に決まるので、ずれない */ background: #eee; /* 読み込み前の見た目 */}画像の縦横比をあらかじめ宣言しておくだけで、読み込み前から高さが確定します。手間はほとんどかからないのに効果が明確な、費用対効果の高い対処です。読み込み中の表示を作り込む前に、まずここを確認してください。
読み込み中の表示と、完成後の表示で大きさが違うと、内容が入った瞬間に位置がずれます。待っている間に位置が動くのは、何も出さないより不快なことがあります。先に場所を確保するのが要点です。
5. 送る量を減らす
体感の話が中心ですが、そもそも送る量が多いという素朴な問題も現実には多い。特に回線が細い環境では、これが支配的になります。
- 1画像 — 表示サイズに合った大きさで送る。元画像をそのまま送っていないか
- 2使っていないコード — 実際には使わない機能まで読み込んでいないか
- 3APIの応答 — 画面で使わない項目まで返していないか（EP.3 の⑦と同じ話）
- 4フォント — 全字種を読み込む必要があるか
1番目が最も頻出し、かつ効果が大きい項目です。表示は小さいのに元のサイズのまま送っている画像は、思っている以上に多く見つかります。一覧に並ぶ小さな画像が、実は撮影したままの大きさだった ── というのは典型的な形です。
この種の無駄は、回線の速い環境では気づけません。手元では一瞬で終わるため、問題として認識されないまま残ります。EP.1 で扱った「手元と本番は別物」が、フロントでは端末と回線の差として最も強く出る領域です。実際の利用者の環境に近い条件で一度確認すると、優先順位の付け方が変わります。
6. 数値と体感の両方を見る
最後に立ち位置の整理です。体感が重要だと書きましたが、数値を見なくてよいという話ではありません。両方が要ります。
数値は改善を測る物差しとして、体感は何を改善すべきかの判断として使います。数値だけを見ると、体感に効かない改善に労力を使います。体感だけを頼りにすると、改善したかどうかが分からなくなります。
そして、この回で扱った改善の多くはサーバ側を1ミリ秒も速くしていません。表示の順序を変え、場所を先に確保し、送る量を減らしただけです。それでも体感は変わります。 を探すとき、利用者との境界から先の区間も対象に含めるという視点を持っておくと、打ち手の幅が広がります。
利用者は完了時刻を測っていない。待たされ方を覚えている。
体感は完了時刻ではなく待たされ方で決まる。改善すべきは多くの場合最初に意味のあるものが出るまでの時間。手段は分けて出す・後回しにする・先に用意するの3つ。待たせるなら進んでいることが分かるように、そして場所を先に確保して表示のずれを防ぐ。次回はメモリと を扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。