Progressive enhancement is not nostalgia
It is easy to treat JavaScript as guaranteed. In practice, scripts fail: a third-party tag throws, a corporate network blocks an asset, a low-end device runs out of memory or a browser extension interferes.
A storefront that only renders after a successful client bundle turns every one of those cases into a blank page and a lost sale.
What breaks when JavaScript fails
For an e-commerce build, we care about the full purchase path, not just the product page. The catalogue, product detail, cart and checkout should all have a server-rendered path that a browser can follow without a client-side router.
- Product listings and detail pages must render useful HTML.
- Adding to a cart should submit a real form and survive a reload.
- Checkout should not depend on a single client-side state tree.
- Validation and errors should be understandable without a script.
- Analytics should not be the only thing that loads.
The architecture that survives
We build the core journey with server-rendered routes and forms, then layer on client-side enhancements for speed and polish. In SvelteKit this means using form actions and progressive enhancement where possible, and treating the client bundle as an improvement rather than the product.
That architecture also makes the site easier to test. A request without JavaScript becomes a real acceptance test instead of an edge case nobody checks.
Measure the right thing
A fast Lighthouse score on a good connection is not enough. We test on a throttled mobile profile, with JavaScript disabled, and through the full checkout path. The goal is not a perfect score. The goal is a store that keeps working when the conditions are not perfect.