Why your storefront should be static

A conventional shop builds every page on demand. A visitor arrives, the application boots, queries the database for the product, the price, the stock, the reviews, renders HTML and sends it. Do that a thousand times a minute and the database becomes the shop’s ceiling.

The irony is that almost none of it changes between requests. The product name is the same for every visitor. So is the description, the image, the category. Rebuilding it per person is work done to produce an identical answer.

Publish once, serve from the edge

Qwikr publishes your storefront as static files to a CDN. A visitor in Manchester is served from a node near Manchester, with no application and no database in the path. There is no origin to overwhelm, because there is no origin doing work.

The parts that genuinely change per visitor — cart, stock, checkout — are fetched separately by the page rather than blocking it. So the shop appears instantly and the live data arrives a moment later, which is the opposite of the usual arrangement where nothing appears until everything is ready.

Stock is live, not baked in

The obvious objection to static: surely the stock figure goes stale?

It would, if stock were part of the published HTML. It is not. Stock and price are published as small data files alongside the page and read when the page loads, so a sale that happens after publishing is reflected without republishing anything.

And when those files change, the CDN’s cached copy is invalidated deliberately. That matters more than it sounds: uploading to a CDN’s storage only updates the origin, and without an explicit purge the edge keeps serving its cached copy — for up to thirty days. A stock change that never reaches the edge is a shop selling things it does not have.

What you give up, honestly

Static is not free of trade-offs, and anyone claiming otherwise has not run one.

• Publishing takes time. A catalogue change is not instant on the storefront the way a database-backed page is — it is published, then propagated.
• Personalised pages need care. Anything genuinely per-visitor has to be fetched client-side rather than rendered, which is more moving parts.
• Preview matters more. You need to see a change before it is published, because publishing is a deliberate step rather than a side effect of saving.

What you get in exchange is a shop that does not slow down when it succeeds, and that cannot be taken down by a bad database query during your busiest hour.

It is also the honest answer for tenants who do not want a storefront

Plenty of merchants come to Qwikr already running Shopify or WooCommerce and have no intention of moving. For them, generating a storefront is not a feature — it is wasted work publishing a shop nobody visits.

So it is switchable per account. Set your primary storefront to Shopify or WooCommerce and Qwikr stops publishing one, while marketplace sync, stock handling and operations carry on exactly as before. That is usually why those merchants are here in the first place.

SEO, redirects and the boring essentials

A static storefront still needs the things search engines expect: a sitemap that reflects what is actually published, redirects for URLs that have moved, and structured data on product pages. These are generated as part of publishing rather than bolted on, because a redirect that only exists in an application is a redirect a static site cannot honour.