楽観的更新とは

楽観的更新とは、サーバーへのリクエスト結果を待たずに、成功すると仮定してUIを先に更新する手法です。

ユーザー操作 → APIリクエスト送信 → レスポンス受信 → UIを更新

ユーザーはレスポンスが返るまで待たされるため、ネットワーク遅延がそのまま体感速度に影響します。

ユーザー操作 → UIを即座に更新 → APIリクエスト送信
                                     ├─ 成功 → そのまま
                                     └─ 失敗 → UIをロールバック

サーバーの応答を"楽観的に"成功と見なして先にUIを反映し、万が一失敗した場合だけ元の状態に戻します。

メリット

なんと言ってもこれですね。
ボタンを押した瞬間に結果が反映されるため、まるでローカルアプリのような操作感を実現できます。
レスポンスが長いとそれだけでユーザーの満足度は下がり、離脱率の増加等に繋がりますので重要なポイントです。

ユーザーはレスポンスの到着を待つ必要がないため、次のアクションにすぐ移れます。
例えば、チャットアプリでメッセージを連続送信するとき、1通ごとにスピナーが出ていたら会話のテンポが崩れてしまいます。楽観的更新なら送信ボタンを押した瞬間にメッセージが表示され、自然な対話の流れを維持できます。

これが一番イメージしやすいと思います。
「押した瞬間に」ハートマーク等が点灯し、付随してバイブレーション機能などが反応したりしますね。
これが通常のフローだと、押してからUIに何らかの反応があるまで数秒程度ラグが発生するのでユーザー体験を大きく損ねることは間違いないでしょう。

ON/OFFを切り替えるスイッチです。
これも押した瞬間に切り替わらないと違和感がありますね。

ショッピングサイトで「カートに追加」ボタンを押した際、即カートに追加される（ように見える）と気持ちがいいです。

速いほうがいいから全部楽観的更新でやる！！というのは問題です。
以下のようなケースでは、従来どおりサーバーのレスポンスを待ってから UI を更新する方が安全です。

「購入完了」と表示した直後にロールバックが起きると、ユーザーに大きな混乱や不信感を与えます。お金が動く操作は、サーバーの確定応答を得てから結果を表示すべきです。

ユーザー名の重複チェック、在庫の確認、権限の検証など、クライアント側では成否を判断できない操作は楽観的に更新できません。「成功するだろう」という仮定が成り立たないためです。

メールの送信、外部 API への通知、データの物理削除など、一度実行すると元に戻せない操作は、ロールバックという前提自体が成立しません。

ネットワークが不安定な環境での大きなファイルアップロードや、レート制限に引っかかりやすい API 呼び出しなど、失敗が頻繁に起こりうる操作では、ロールバックが連発してかえって UX を損ないます。

迷ったときは、次の 2 つの問いで判断できます。

① この操作は高い確率で成功するか？
② 失敗してロールバックしても、ユーザーが混乱しないか？

両方「はい」なら楽観的更新の適用候補、どちらかが「いいえ」なら従来の更新フローを選ぶと良いでしょう。

ちなみに楽観的更新に対して、従来のフローは「悲観的更新」と呼ばれるそうです。
確かに言葉の意味としては間違いないのですが、何となく後ろ向きな印象を受けます