When Should a Web App Wait for the Server Before Updating the Screen?

Key Takeaways

• Fast feedback does not always mean showing success immediately.
• High-stakes actions should wait for server confirmation.
• Pending updates need a clear and reliable recovery path.
• A timeout can leave an action’s outcome unknown.

I remember reading about a trick Instagram used to make photo uploads feel almost instantaneous. Instead of waiting until the user pressed Post to begin uploading the image, the app could start moving the media in the background while the user was still preparing the post. By the time they finally pressed Post, much of the expensive work had already happened.

This is a nice thing and, in many cases, very useful. However, imagine you don’t upload an image on Instagram but play a casino game. Well, it often involves money, and making decisions around a digital table usually doesn’t work well with latency. If you get a confirmation while the real processing is still happening in the background, and you decide to close the gaming page, you may lose track of whether your action was actually completed.

A Click Confirms Intent, Not Completion

For people who play casino table games, the distinction has a concrete meaning: selecting a stake and having that stake accepted are separate events. Casino table games for real money make a useful case study because acceptance relates to both the player’s funds, as the money is involved in the game, and participation in a particular round.

Consider a roulette interface. A player places a €10 chip on red and clicks Bet. The browser knows the selected amount and position. It can immediately highlight the selection and show “Submitting €10 on red.” That is accurate feedback about the request being sent.

What the server needs to confirm

Before showing “Bet accepted,” however, the application needs a server decision. In a design with timed betting rounds, that decision should account for:

• the round identifier
• whether betting remains open
• the permitted stake
• the funds available

A countdown on the player’s screen helps communicate timing, but it cannot establish whether the request reached the server before the cutoff. Confirmation should also identify:

• the accepted round
• the amount
• the selection

A generic success message tells the player less than a confirmed wager that remains visible in the round history.

Money changes what visual feedback means

This explains why the real-money element matters particularly. A temporary chip in a practice interface can represent a proposed move. With money involved, the same visual may be understood as confirmation that funds have been committed and the wager will participate in settlement.

The design can still feel responsive throughout. Chip selection, button feedback and pending indicators need no server permission. The point where the screen claims an accepted financial commitment does.

Choose Optimism According to What a Reversal Would Mean

Responsiveness does not require immediate success messages. Google’s web.dev guidance classifies an Interaction to Next Paint of 200 milliseconds or less as good. 

The decision to display an expected outcome should depend on what happens if that expectation is wrong.

Action	Immediate screen update	What should await confirmation
Reordering a personal list	Move the item to its proposed position	Confirmation that the order was saved
Sending a message	Show the message with “Sending” status	Confirmation that the service accepted it
Reserving a seat	Highlight the requested seat	Confirmation that the reservation exists
Changing account permissions	Display the proposed setting as pending	Confirmation that access has changed

A useful test is whether reversal would merely correct the display or disrupt something the user has already done. Restoring a list item may be manageable. Retracting a reservation after the user has arranged travel is a different problem.

Recovery also becomes harder when several edits overlap. Suppose a user changes a task’s title, then its due date. If saving the title fails, restoring a snapshot of the entire task could erase the newer date change.

React’s optimistic-state documentation describes recalculating pending updates against changing underlying state, illustrating why optimistic rendering needs more than a saved “before” picture. 

Google’s INP guidance treats interactions of 200 ms or less as good, while also separating the delay before input handling, processing time and the final presentation of the updated frame.

Source: Here

Keep track of each pending operation separately. Reconcile its result without discarding unrelated edits, and preserve user input when a request cannot be completed. Optimism works best when the application has a precise recovery path.

A Timeout Leaves the Outcome Unknown

Waiting for confirmation introduces another question: what should the interface show when confirmation never arrives?

As engineer Marc Brooker writes, “A timeout or failure doesn't necessarily mean that side effects haven't happened.” A server may complete an operation and then lose the connection before its response reaches the browser. 

For consequential actions, “We couldn’t confirm the result” can therefore be more accurate than “Failed.” The application should retain the operation’s identity and check its status when connectivity returns. Automatically restoring the previous display may imply that an already completed action never happened.

Most requests finish quickly, but a small number take much longer, showing why apps need to handle slow or uncertain responses.

Source: Here

Retries need the same care. Give each intended operation a unique request identifier, and reuse that identifier when retrying it. The server must recognise the repeated request and return the appropriate result without performing the action again. Generating a new identifier for every attempt defeats that protection. This approach is described in the Builders’ Library guidance on making retries safe. 

Repeated requests can also increase the wait. Brooker illustrates how five service layers, each making three attempts, can multiply one request into 243 database attempts. That is a worked example, not a measured industry failure rate. It explains why retry behaviour needs coordination across the application. 

Test the cases where the server succeeds but the response disappears

Before shipping, test the awkward sequence: the server commits the change, the response disappears, and the user reloads. Can the application recover the result? Does it preserve the same operation identifier? Can it distinguish a rejected request from an outcome it has not yet verified?

Update the screen as soon as you can truthfully acknowledge the action. Show completion when you have evidence that the promised result exists.