“速く”より“速く感じる”を設計する — UX視点での体感速度の改善
■ はじめに
こんにちは。株式会社ペライチ のフロントエンドエンジニア藤田です。
Web アプリケーションの速度を語るとき、私たちはよく API レスポンスや描画速度といった「処理の速さ」に注目しがちです。しかし実際のところ、ユーザーが感じる"速さ"は、それらの指標だけでは測れません。
たとえばボタンを押したとき、処理が即時に始まっていたとしても、画面に何の変化もなければ「遅い」「反応していない」と感じてしまうこともあります。これは、処理時間そのものではなく、体感速度による UX の問題です。
今回は、社内で取り組んだ"体感速度"の改善と、それにまつわる UX 設計について紹介します。
■ クイズ:どれが一番“遅く”感じる?
以下の UI のうち、どれが一番「遅く感じる」でしょうか?
- ボタンを押すと「送信中...」と表示され、2 秒後に画面が切り替わる
- プログレスバーが表示されて 3 秒後に画面が切り替わる
- ボタンを押しても何も起きず、1.5 秒後に画面が突然切り替わる
答えは 3 番です。
実際には 1.5 秒と最も速い処理ですが、フィードバックがないため「ちゃんと動いているのか?」という不安が強く、UX 上は最も“遅く感じる”パターンになります。
Jakob Nielsen's UX ガイドラインでは、「100 ms 以内に反応があると即時と感じられ、それを超えると“待たされている”と感じやすくなる」とされています。
このように、ユーザーの感じる“速さ”は、処理のタイミングよりも反応の見せ方によって大きく変わります。
■ UX改善に向けたアプローチ
では、実際にどのような工夫をすれば「速く感じる体験」が作れるのでしょうか。
1. Optimistic UI の導入
API レスポンスを待たず、先に UI だけ反映してしまう手法です。
- 「いいね」ボタン:押した瞬間にハートが点灯する
// いいねボタン(Optimistic UI)
const liked = ref(false)
const handleLike = async () => {
liked.value = true // 即時反映
try {
await api.post("/likes", { itemId })
} catch (error) {
liked.value = false // エラー時にロールバック
}
}
- 「カートに追加」:即座にバッジ数が増える
これにより、ユーザーは"すぐ反応した"と感じ、安心感を得られます。
未来を信じて先に反応を見せることで、"ちゃんと動いている感"を感じられるのです。
もちろん、決済処理のようなクリティカルな領域では慎重さが必要です。
2. ローディングの見せ方を最適化
- スケルトン UI:読み込み中でも"何かが表示される予定"であることが視覚的に伝わる
- 部分ローディング:画面全体ではなく、必要な範囲だけをブロック
全画面ローディングは、ユーザーの操作権を奪ってしまい、かえって"止まっている"ように感じさせてしまうことがあります。部分的なフィードバックがあることで、ユーザーは"ちゃんと処理が進んでいる"と感じやすくなります。
3. Debounce によるリクエスト最適化
ユーザーの入力が止まったタイミングでだけ処理を送ることで、連続した操作による不要なリクエストをまとめることができます。検索フォームなどでの API 連携の際に有効です。
import { debounce } from 'lodash-es'
const searchQuery = ref('')
const debouncedSearch = debounce((query: string) => {
// 実行したい処理(サーバーへのリクエストなど)
fetchSearchResults(query)
}, 300)
watch(searchQuery, (newQuery) => {
debouncedSearch(newQuery)
})
連続した操作をまとめて、入力が止まったタイミングでだけ処理することで、無駄な負荷や遅さを感じさせず、滑らかな操作感を保てます。
■ トレンドとこれから
近年では、ChatGPT のような "AI UI" によって、処理そのものが重い場合でも、体感的に「考えてくれている感」を与える設計が求められています。
- タイピングアニメーション
- 一文字ずつの表示
また、SaaS やモバイルアプリにおいても、通信状況が不安定な中での即時フィードバックが UX に直結するため、体感速度の設計はますます重要になっています。
■ なぜエンジニアが考えるべきなのか
UX の見た目はデザイナーが設計してくれますが、“動き”や“フィードバック”の細部はエンジニアの実装次第で変わることがほとんどです。
- 処理中かどうかをどう見せるか?
- 失敗した時に何を表示するか?
- いつまで操作できるようにするか?
こうした実装レベルの判断によって、ユーザーが感じる速さ・安心感・納得感は大きく変わります。
“速さの体験”は、細部の見せ方や伝え方で作られます。そうした体験の質は、エンジニアの工夫で磨いていける領域です。
Discussion