Block checkout hosting where the cart runs in the browser.
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.
The page is a shell.
With block checkout the HTML is nearly static and everything that matters arrives afterwards over the Store API.
Store API responses excluded from caching
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.
A shell that can be cached hard
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.
Extensions that expect the classic checkout
Plugins hooking classic checkout fields do not appear in the block version. That is discovered at launch unless the extension list is checked first.
Fewer server renders, more API calls
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.
A fallback that is actually tested
If something is incompatible you may need the classic checkout back quickly, which means it has to work rather than being assumed to.
Cart state moved off the page.
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.
- Store API responses excluded from every cache layer
- Shell page cached aggressively
- Extension compatibility audited before launch
- Classic checkout fallback verified
One shell, several API calls.
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.
What we change for block checkout
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. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can I cache the block checkout page?
My checkout plugin's fields disappeared. Why?
Is block checkout faster?
Can I go back to the classic checkout?
Cache the page, never the cart.
Move the store across. Migration is free, extensions checked first.