Can a checkout be cached at all?

Whole pages usually not, individual components yes. Shipping zones, country lists, tax rates and fixed text blocks change rarely and can sit in the application cache. What stays uncacheable is the cart content, account-specific prices, shipping costs per cart and everything coming back from the payment step. In our experience, moving out the unchanging components alone brings noticeable response time without touching the purchase mechanics.

Which metric matters most in the checkout?

That depends on the step. In cart, shipping and confirmation, server response time dominates, because those steps compute and write. In the address and payment steps, interaction latency dominates, because those steps are typed and clicked. A single overall value for the checkout blurs both. As a rule, a budget per step leads to a result faster than one grade for the whole stretch.

How many form fields are appropriate?

The benchmark names 8 fields as the requirement for most shops, against an observed average of 11.3 fields (Baymard Institute). That is a guide value, not a rule: orders with a cost centre, a differing delivery address or an approval step typically need more. It helps to test every field against a simple question - does the order fail without this field, or does it merely get less convenient.

Is measuring the checkout in the lab enough?

The lab is well suited to finding causes, less so to assessment. Lab measurements run without a real session, without a filled cart and without the network conditions of your customers. Field data at the 75th percentile on mobile devices shows what visitors actually experience. As a rule a checkout project needs both: the field for prioritisation, the lab for the cause.

What can be changed about the payment provider's frame?

Little about the external code itself, a lot about its surroundings. Loading it late after the payment method is chosen, a fixed height against layout shifts, an early connection and a tidy main thread all take effect even when the frame stays unchanged. In our experience a good part of the perceived waiting time in the last step sits there.

When during the year is the rebuild worthwhile?

Before the high-revenue phase, not during it. Retail generates 18.5 percent of its annual revenue in November and December (HDE); changes to the purchase process during those weeks carry a risk that can be avoided in quieter months. A workable sequence is: measure in late summer, rebuild in early autumn, and from November onwards only observe and hold the values against the budget.

Checkout Speed: Winning the Final Seconds of a Sale

For a new customer, the path from the shopping cart to the order review runs to 5.1 steps on average; the Baymard Institute measured that figure at large retailers. Anyone signed in with a stored address and payment method usually gets through in fewer steps. Unlike the home page, a category or a product page, this section cannot be cached as a whole: every one of those pages depends on a session, a cart, an address. This is where a filled cart either becomes an order or does not - and this is where, in our experience, the least measuring happens.

Key takeaways

The checkout runs without a page cache: cart, address, shipping costs and payment are produced per session and run through the full chain of application, database and payment interface.
Averaged across 50 studies, 70.22 percent of filled carts do not become orders (Baymard Institute) - more revenue potential sits behind the cart than in front of it.
On mobile, only 69 percent of secondary pages reach good INP scores, against 80 percent for home pages (Web Almanac 2025). The checkout belongs to the secondary pages, not to the entry pages.
A 0.1 second improvement in mobile load time coincided with 8.4 percent more conversions in the retail segment of the study - 15 brands with 20.5 million mobile sessions (Deloitte Ireland 2020).
Set a separate budget per checkout step for server response time, interaction latency and field count, and measure in the field at the 75th percentile on mobile rather than in the lab at your desk.
Plan the work before the high-revenue phase: 18.5 percent of annual retail revenue in Germany falls into November and December (HDE).

Why the checkout knows no cache

Category and product pages can largely be prepared in advance. A page cache serves the same HTML to thousands of visitors, an upstream cache pushes it to the edge of the network, and the application does not see the request at all. From the cart onwards that model ends. The content depends on the session: which items are in it, which price applies to this account, which shipping zone applies, which tax rate. Every one of those answers is produced fresh, through the full chain of application, database and payment interface. Anyone who has so far measured their shop's load time on the home page has not yet seen the section the order actually depends on. Server response time work acts directly on every single step here, because no cache is left in between to hide a slow call.

The effect is visible in the field data of the web. Home pages reach good INP scores on mobile in 80 percent of cases, secondary pages in only 69 percent (Web Almanac 2025) - an eleven percentage point gap that did not exist in this form a year earlier. As an explanation the report points to exactly the components a checkout is built from: filters, carousels and form validation, plus scripts that only start deeper in the user journey. Across all pages, 77 percent were in the good range on mobile (Web Almanac 2025); it is the secondary pages that pull that average down, not the entry pages. How the value can be collected cleanly in the first place, and which interactions it summarises, is covered in the article on Interaction to Next Paint.

Why this matters right now

Retail in Germany generates 18.5 percent of its annual revenue in the last two months of the year (HDE). For the 2025 season the association expected 126.2 billion euros across November and December, of which 22.2 billion euros online at a nominal increase of 3.3 percent (HDE, forecast of 5 November 2025). Figures for the coming season are not yet published; the 18.5 percent share does, however, describe the order of magnitude at stake in the fourth quarter.

What abandonment at the cart costs

In online retail there is an unusually large body of data on cart abandonment. From 50 different studies the Baymard Institute calculates an average of 70.22 percent (Baymard Institute): a good seven out of ten filled carts do not turn into an order. The value averages across very different sectors, periods and measurement methods and is therefore not a target for any single shop - a specialist site with a configurator behaves differently from a subscription shop with three products. As an order of magnitude, though, it says clearly where the money sits: behind the cart, not in front of it. If you want that translated into euros, the calculation is in the article on load time, conversion rate and revenue.

Part of that abandonment has nothing to do with speed: comparing, parking, shipping costs, a missing payment method. A measurable part does. 17 percent of US online shoppers have abandoned an order in the institute's checkout research because the checkout was too long or too complicated (Baymard Institute). Length and complexity are not purely questions of design. An address check that takes 800 milliseconds after every keystroke makes the same form feel twice as long: the field count stays the same, the perceived effort doubles. Perceived complexity is therefore to a good extent a question of runtime in the browser and not only a question of layout.

How strongly speed works on its own is shown by a study covering 37 brands with around 30 million mobile sessions: the data was collected and analysed by Fifty-Five, commissioned by Google, and the report was prepared by Deloitte Ireland (Milliseconds Make Millions, 2020). The basis was a natural improvement in mobile load time of 0.1 seconds. In the retail segment - 15 brands with 20.5 million sessions - conversions rose by 8.4 percent and average order value by 9.2 percent (Deloitte Ireland 2020). The data was collected over four weeks and shows a correlation for the brands studied; it is not a formula that transfers to every shop. It does describe the direction very clearly: tenths of a second are not cosmetics in retail, they are an economic quantity.

Step	What the server has to do	Why no cache applies	Leading metric
Cart	Stock, tiered prices, account-specific discounts	Content depends on the session	Server response time
Address	Field validation, country rules, tax rate	Personal data entry	Interaction latency
Shipping	Costs by weight, zone and delivery date	Result differs per cart	Server response time
Payment	Authorisation, third-party frame, strong customer authentication	External window with its own runtime	Interaction latency and layout stability
Confirmation	Write the order, create the document, notify	A write operation, not a read	Server response time

The table explains why a speed project at the checkout runs differently from one on the home page. There it is about images, fonts and render-blocking resources; here about database queries, third-party frames and time on the main thread. Both ends need their own measurement points, and both belong in the same picture of front-end optimisation and server work, otherwise the saving happens in the wrong place. Where the server time actually goes is made visible by the article on Server-Timing - without that breakdown, a high response time stays a number without an address.

The five steps and their bottlenecks

For a new customer at a large retailer, the average checkout is 5.1 steps long, counted from the cart to the order review page (Baymard Institute). Technically these steps are very different animals: two of them compute mainly on the server, two mainly in the browser, one writes. Treating them as one and reporting a single load time for the checkout loses exactly the information that leads to a fix. For the server share, time to first byte is the appropriate leading metric; for the browser share it is the latency of interactions.

Recalculating the cart

Stock, tiered prices and discounts apply per account. Every call goes to the database. Here it pays to count the queries rather than the kilobytes.

Validating address fields

A check on every keystroke occupies the main thread permanently. A check when the field is left is usually enough and keeps typing fluid.

Determining shipping costs

Weight, zone and delivery date determine the result; it can hardly be prepared in advance. A separate measurement point per calculation makes the cost visible.

Authorising payment

Third-party frames bring their own JavaScript and their own fonts. They belong loaded late, with a fixed height and without a jump in the layout.

Including the error paths

Wrong postcode, declined payment, empty stock: these paths run rarely in tests and regularly in production. They need the same measurement as the success case.

Writing the order

The last step writes to several tables and triggers follow-up processes. Whatever runs synchronously there extends the wait right before the thank-you page.

Five of these six points can be addressed without rebuilding the purchase mechanics. The sixth usually requires a decision: what has to happen synchronously for the order to be valid, and what may go into a queue. Document generation, reconciliation with the inventory system and sending notifications do not, in our experience, belong in the click path but behind the confirmation page. In Shopware projects this is frequently the point at which the confirmation page drops from several seconds to a fraction of that, without a single field disappearing.

The order of work that has proven itself

First record the steps individually, then reduce the most expensive response time, then reduce the field count, then untangle the third-party frames. Starting with the last point moves load time around instead of removing it.

Form fields are the most expensive component

The average checkout contains 11.3 form fields, although according to the institute's research 8 fields would be enough for most shops (Baymard Institute). The value has fallen over the years - 11.8 fields in 2021, 12.7 in 2019 (Baymard Institute) - yet the gap to what is necessary has remained. Every additional field costs twice: once in attention while filling it in and once in runtime in the browser. The first cost is well known, the second is rarely quantified.

In typical shop themes a field brings several event handlers with it, often a check on every keystroke, sometimes a request to the server for address completion. With eleven fields that adds up to a permanent base load on the main thread - and that base load is precisely what interaction latency measures. Reducing the number of fields reduces both costs at once. Where fields cannot be removed because the business needs them, rebuilding the validation helps: from keystroke to leaving the field, and splitting long tasks as described in the article on long tasks and the scheduler interface.

checkout-budget.json

{
  "checkout_budget": [
    { "step": "cart",         "ttfb_ms": 400, "inp_ms": 150, "fields": 0 },
    { "step": "address",      "ttfb_ms": 400, "inp_ms": 150, "fields": 8 },
    { "step": "shipping",     "ttfb_ms": 500, "inp_ms": 150, "fields": 0 },
    { "step": "payment",      "ttfb_ms": 600, "inp_ms": 200, "fields": 0 },
    { "step": "confirmation", "ttfb_ms": 400, "inp_ms": 150, "fields": 0 }
  ],
  "measurement_window": "field data, 75th percentile, mobile",
  "error_paths": ["postcode_invalid", "payment_declined", "stock_empty"]
}

What a budget does not measure

A budget expressed in fields and milliseconds captures the smooth run. It says nothing about the path a customer takes after a wrong postcode or a declined payment. These paths run rarely in tests and regularly in production; they need the same measurement points as the success case, otherwise the most expensive part of the checkout stays unobserved. Include the error paths in the recording explicitly.

Measure interaction latency per step, not per page

Interaction latency reports the longest interaction of a page visit. In a checkout spread across several page loads, each step produces its own value; in the field data those values are then merged, and the individual step is no longer visible. For assessment that is correct, for debugging it is useless: you see that something is slow, but not where. A second, separate recording makes sense, holding the longest interaction per checkout step, collected in the browser and sent when the page is left. How much work accumulates on the main thread is shown by the lab measurement in the same report: at the 90th percentile, mobile users face over 7.5 seconds of blocking time before a page becomes fully interactive (Web Almanac 2025).

The snippet below works without any external library and uses only interfaces the browser already provides. It keeps the highest value per step and sends it to an endpoint in the same shop at the end. What has to be observed legally, and why a measurement without a personal identifier can in many cases work without consent, is covered in the article on performance measurement without consent.

checkout-measurement.js

// Keep the longest interaction per checkout step
const values = new Map();
const step = document.body.dataset.checkoutStep || 'cart';

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.interactionId) continue;
    const seen = values.get(step) || 0;
    if (entry.duration > seen) values.set(step, Math.round(entry.duration));
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 40 });

addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'hidden' || values.size === 0) return;
  const payload = JSON.stringify(Object.fromEntries(values));
  navigator.sendBeacon('/measurements/checkout', payload);
});

Payment, third-party frames and the last click

The payment step is typically the one in which external code runs inside your own purchase process. The embedded frame of the payment service brings its own JavaScript, loads its own fonts and does not measure itself. For the page that means three things: additional time on the main thread, additional connections and an element whose height is only known after loading. That is exactly where layout shifts right before paying come from - the order button slides down while the thumb is already on its way. How to avoid this is described in the article on layout shifts in a shop.

Load the third-party frame only once the customer has chosen a payment method, not when the step opens.
Give the frame a fixed height so the order button stays where it is while content loads.
Open the connection to the payment service early, but fetch the resources themselves late.
Trim your own scripts in the payment step to what is needed; every task saved benefits the external frame.
Disable the order button after the first click and show that state, so double orders and repeated requests do not occur.

The effort pays off because everything comes together in the payment step: external code, form logic and a server response that cannot be prepared. How much external code a shop carries in total is covered by the article on trimming third-party scripts; how the same checkout behaves under heavy load is shown by a load test before peak season. The two belong together, because a response time measured on a quiet night says little about a Friday evening in December.

A checkout does not become fast because the home page is fast. It becomes fast when each of its steps has its own budget and is measured on its own - including the paths that go wrong.

Project experience from performance work on shops and portals

In practice that means five measurement points instead of one, a budget per step and a recording that also captures the error paths. The rest is craft - consolidating queries, removing fields, untangling validation, taming third-party frames. Which Core Web Vitals describe which step, and how strongly CSS runtime in the browser interferes, is explored in the article on style recalculation. Looking at both together usually requires less rebuilding than expected.

This article is based on data from: Baymard Institute (Cart Abandonment Rate Statistics, Checkout Optimization), Milliseconds Make Millions (data: Fifty-Five, commissioned by Google, report: Deloitte Ireland), Handelsverband Deutschland HDE (Christmas trade forecast) and Web Almanac 2025 (Performance chapter).