Latency, perceived performance and checkout: a design argued from response-time research

1Context and motivation

A checkout is not one wait but several. The shopper waits for the page to render, for the shipping options and tax total to be computed, for a discount code to be checked, and for the payment to be authorised, sometimes with an extra authentication step from the card issuer. Each of these waits is short, and each depends on a different system: the storefront, a rates service, a tax service, a payment provider. A slow response in any one of them is visible to the shopper at a moment when they are deciding whether to commit money.

The working claim behind most performance engineering in commerce is that slower pages convert worse. That claim is plausible, and the research below supports parts of it, but the size of the effect for a given store, step and audience is an empirical question. Many of the numbers that circulate about it come from company talks and reports whose method cannot be checked. We therefore do two things in this paper. We set out what published research on response time does establish, and we derive from it a latency design for checkout that does not depend on any particular effect size. We then describe the experiment that would measure the effect for a given store. We report no measurements of our own.

2What response-time research establishes

2.1Acceptable delay depends on what the user is doing

The study of system response time is more than fifty years old, and from the start it rejected a single acceptable delay. Miller argued that the acceptable response time depends on the purpose of the action being answered¹. Card, Robertson and Mackinlay summarised human time constants that interface design has used since: about 0.1 second, within which a response feels like a direct result of the user's action; about 1 second, the limit for an immediate response in a dialogue; and about 10 seconds, the span of a unit task². A review of four decades of this work proposes a related split between control tasks, where responses must be immediate, and conversational tasks, where some delay is acceptable and even expected³.

For checkout this gives a useful separation. Typing into a field, toggling a shipping option or opening a summary panel are control actions: the response should arrive within the first time constant. Submitting an address or a payment is a conversational action: the shopper expects the system to do work, and a short delay is tolerated if the system shows that it is working.

2.2Delays change behaviour before users report them

Experimental work on web delays finds effects on what users do and think. In a controlled study with constant delays from 0 to 12 seconds, task performance, attitudes towards the site and intention to return all declined with delay; the decline in performance and intentions began to flatten at around 4 seconds, and in attitudes at around 8 seconds⁴. A study of tolerable waiting time for web pages found that users were willing to wait about 2 seconds for information retrieval, and that feedback during the wait extended that tolerance⁵.

Search engines have given the clearest evidence at sub-second scale. A controlled study found that added delays become noticeable once they pass a threshold, and that users of a fast system notice them more readily than users of a slow one; an analysis of a large query log found that, for result pages identical in content, users were more likely to click on the one served with lower latency⁶. A follow-up measured physiological responses and found effects of latency even at small increases, effects that self-reports captured less well⁷. The relevance for checkout is the direction, not the size: small delays can change behaviour without the user being able to say that the page was slow, so asking users is not a substitute for measuring them.

2.3Feedback during a wait changes how it is experienced

What the user sees during a wait matters as well as how long it lasts. Users prefer to have a progress indicator during a long operation⁸, and the way a progress bar moves changes how long the same process is perceived to take⁹. Feedback also extended tolerable waiting time in the study above⁵.

How a wait is remembered may matter for a return visit. In experiments on affective episodes, retrospective evaluations tracked a weighted average of moments in the experience and were largely insensitive to its duration¹⁰. Those experiments used film clips, not web sessions. We take from them only a design hypothesis: a single bad moment at the payment step may weigh more in how a session is remembered than the sum of small delays earlier in it. That hypothesis would need testing in a commerce setting before it informed any priority.

2.4In distributed services, the tail sets the response

A checkout step that calls several services finishes when the slowest call returns. In large services that fan out to many components, rare slow responses in any one component become common at the level of the whole request, so tail latency, not average latency, governs what users experience; techniques such as hedged requests and tolerance of slow components address this¹¹. For checkout, this means a payment or tax call with a good median and a poor 99th percentile will still make a noticeable share of checkouts slow.

3From the literature to a checkout latency design

We translate these findings into five design components. Table 1 maps each to the problem it addresses and the evidence for it.

Component	Problem it addresses	Evidence
Separate budgets for control and conversational actions	One latency target fits neither field input nor payment submission	2, 3
Instrument behaviour, not only satisfaction surveys	Small delays change behaviour before users report them	6, 7
Progress feedback for any step over the immediate-response limit	Unexplained waits shorten tolerance	5, 8, 9
Tail-latency policy on third-party calls (timeouts, hedging, fallbacks)	Rare slow calls make many checkouts slow	11
Slowdown experiment before setting targets by revenue	The cost of latency for a given store is unknown	12, 13

Source: Each row cites the work it rests on; the components are our design.

3.1Budgets by action type

Each checkout interaction is classed as control or conversational. Control actions (field validation, option toggles, panel expansion) are handled on the client wherever possible, so that their response does not depend on a network round trip. Conversational actions (address submission, shipping and tax recalculation, payment) have their own budget, set in the worked model below.

3.2Feedback policy

Any conversational step that can exceed the immediate-response limit shows feedback within that limit: a state change on the control the user pressed, then a progress indicator naming the work being done ("Checking the card with your bank"). The feedback is honest about what is happening and does not imitate progress that is not taking place. The payment step never leaves the user without a visible state, because an unexplained pause there invites a second submission.

3.3Tail-latency policy

Every call to a third-party service (rates, tax, fraud screening, payment) has a timeout below the step budget, and the step has a defined behaviour when it fires. Where a cached or estimated value is safe, the step uses it and marks it as provisional: for example, a shipping estimate from the last successful quote for the same destination, recomputed before payment. Where no safe fallback exists, as with payment authorisation, the step waits but shows its state, and it never allows a duplicate charge from a repeated submission. Idempotent requests are what make a retry safe. Hedged requests, sending a second request when the first has not answered within a short time¹¹, are used only for read calls whose duplication has no side effect.

3.4Measuring in the field

Latency is recorded per step from the shopper's device, not only at the server, because the user's wait includes network and rendering time that the server cannot see. Each step records its 50th, 95th and 99th percentile latencies by device class and network type. Outcomes recorded for the same sessions are step completion, abandonment at the step, and repeated submissions.

4A worked latency budget

Table 2 is a worked model of a budget for the conversational steps of a checkout. The targets are inputs we chose for illustration, informed by the time constants above; they are not measurements and not recommendations for every store.

Step	Target (ms, input)	Feedback required (computed: target above 1,000 ms)
Address submission and validation	600	No
Shipping options and tax total	800	No
Discount code check	500	No
Payment authorisation, no issuer challenge	2,500	Yes
Order confirmation render	700	No
Sum of step targets	5,100	Computed: sum of the rows above

Source: Worked model; inputs in the table.

Two observations follow from the arithmetic. First, payment authorisation alone takes about half of the summed budget in this model, and it is the step least under the store's control, which is why the design gives it feedback rather than relying on speed. Second, the sum of step targets is not the 95th percentile of the whole checkout: the 95th percentile of a sum is not in general the sum of the 95th percentiles, and a checkout is also interrupted by the shopper's own typing and reading. The end-to-end figure has to be measured directly, and the budget is a planning device for each team that owns a step.

5Measuring what latency costs

The literature supports the direction of the effect; it cannot tell a store how much a given delay costs it. The method that can is a controlled slowdown experiment: randomly assign a small share of sessions to a deliberate, fixed added delay at one step, and compare outcomes against control. Experiments that knowingly degrade the user experience for a short time can be worth running for what they reveal¹², and the same experimentation framework (randomisation, guardrail metrics, sufficient sample size) applies to them as to any other change¹³.

The protocol we propose is as follows.

• One step, one delay at a time. Add a fixed delay (for example 100, 250 or 500 ms, as separate arms) at one checkout step. The delays are design inputs.
• Primary metric. Checkout completion per session that reaches the step.
• Guardrails. Repeated payment submissions, support contacts and error rates. The experiment stops if a guardrail is breached.
• Segments. Effects are reported by device class and network type, because a delay that is invisible on a fast device may add to an already long wait on a slow one.
• Duration and exposure. Exposure is kept small, and the duration is set from a power calculation on the store's own baseline completion rate.

The result is a slope, completion per added millisecond at one step, estimated for one store and audience. Only with such a slope could a team trade latency work against other work in units of revenue. Without it, the budget in Table 2 should be read as a usability target, not a revenue claim.

6Regional and device variation

Shoppers in different regions use different devices, networks and payment methods. A low-end phone on a variable mobile connection spends more time parsing and executing scripts and waiting on the network than a recent laptop on fixed broadband, and a local payment method may route through a different provider with its own latency. We draw two design consequences without assigning numbers to them. First, budgets and measurements are kept per device class and per network type, so that an average across regions does not hide a slow segment. Second, the script and page weight of the checkout is budgeted against the slowest device class the store serves, not the fastest. Which regions and segments are slower, and by how much, is a measurement for each store, not a constant we can supply.

7Limitations

• No measurements. We have not run the slowdown experiment or measured any store. Every benefit implied by the design is a hypothesis.
• Transfer from other settings. Several cited studies concern web search or general web browsing, often with student participants. Checkout differs: the shopper has committed effort and money is at stake. The direction of the findings may transfer; their thresholds may not.
• Memory effects are a hypothesis. The duration-neglect findings come from film clips. Whether a slow payment step dominates how a checkout is remembered is untested.
• Third parties set the floor. Payment authorisation and issuer authentication are outside the store's control. The design can make them visible and safe to retry; it cannot make them fast.
• Budgets are inputs. The values in Table 2 are illustrative. A store needs its own baseline before setting them.
• Experiment cost. A slowdown experiment deliberately degrades the experience for some shoppers and may need a large sample to detect small effects. It should run with small exposure and strict guardrails.

8Conclusion

Published response-time research gives a checkout design a firm basis without any borrowed effect sizes: separate budgets for control and conversational actions, feedback for any wait beyond the immediate-response limit, a policy for the tail latency of third-party calls, and field measurement by device and network. What the literature cannot give is the cost of a millisecond for a particular store. The next step is to run the slowdown protocol at one step, starting with shipping and tax recalculation, and report the slope that is measured.