The block cart and checkout do not render on the server. They fetch state over an API, which moves every caching and compatibility question somewhere new.
With block checkout the HTML is nearly static and everything that matters arrives afterwards over the Store API.
Those responses carry the cart. Cached even briefly, one shopper receives another's basket and totals — which the near-static shell page makes easy to miss.
Because the markup no longer contains cart state, the page itself becomes cacheable in a way classic checkout never was. That is the upside, and it only holds if the API is excluded.
Plugins hooking classic checkout fields do not appear in the block version. That is discovered at launch unless the extension list is checked first.
The request pattern changes shape: fewer full page renders and many small API calls. Capacity is planned for that mix rather than the old one.
If something is incompatible you may need the classic checkout back quickly, which means it has to work rather than being assumed to.
Classic checkout put cart state in the HTML, so the rule was simply never to cache it. Block checkout puts it behind an API, and the page in front looks safe to cache because it is.
The gain is a cacheable checkout page. The cost is more small requests, and the measurement is how quickly the cart state arrives after the shell.
Cart state moving from the page to an API changes what may be cached and what must not be, in both directions.
| Setting | What we do | Why |
|---|---|---|
| Store API caching | Excluded from every layer without exception | Those responses carry the cart and totals, so a briefly cached one hands a shopper somebody else's basket — and the static-looking shell makes it easy to overlook. |
| Shell page caching | Cached aggressively now that it holds no cart state | The markup no longer contains anything per-customer, which makes the checkout page itself cacheable in a way classic checkout never was. |
| Extension audit | Checked against the block checkout before switching | Plugins that add fields via classic checkout hooks simply do not render, and the absence is noticed by a customer rather than by an error. |
| Capacity mix | Planned for many small API calls rather than full renders | The traffic shape changes, and capacity sized for page renders describes a pattern the store no longer produces. |
| Fallback path | Classic checkout kept verified as a way back | An incompatibility found at launch needs a reversal that works, not one that is assumed to. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the store across — migration is free, extensions checked first.