Static export strategies, Stripe integration without a server, localStorage cart persistence, and code splitting—building fast e-commerce with no backend.
The Performance Paradox
E-commerce sites need to be fast. Every 100 milliseconds of latency costs conversions. But e-commerce also needs dynamic features: shopping carts, inventory checks, personalization.
The traditional solution is server-side rendering. Every page request hits a database, checks stock, renders HTML. It's flexible but slow. The server is in the critical path.
We explored a different architecture: 100% static product pages with client-side interactivity and Stripe handling all payment logic. The result is sub-50ms page loads globally with full checkout functionality.
Static Generation
Product pages are generated at build time. Every product becomes an HTML file, uploaded to a CDN. When a user visits, they receive cached static content from the edge location nearest them.
No server in the critical path means no server latency. CDN latency is typically 10-30 milliseconds globally. Traditional server rendering is 200-400 milliseconds on good days, worse under load.
The tradeoff is that content doesn't update automatically. Product changes require a rebuild. For catalogs that change infrequently, this is acceptable. For real-time inventory or pricing, it's not.
Client-Side Cart
The shopping cart lives entirely in the browser. Add-to-cart interactions update local state and persist to localStorage. No server round-trip needed.
This creates a snappy experience. Add an item, see immediate feedback. The cart persists across sessions without authentication. Users can browse, accumulate items, and check out when ready.
The limitation is cart data isn't synchronized across devices. A cart built on your phone doesn't appear on your laptop. For many use cases, this is acceptable—shopping sessions are typically short and single-device.
Stripe Checkout
Stripe Checkout handles payment without requiring a custom server. The user's browser redirects to Stripe's hosted checkout page, completes payment, and returns to a success page.
This offloads payment security, PCI compliance, and international payment methods to Stripe. The merchant never touches card data. The implementation complexity drops dramatically.
Products and prices must be created in Stripe ahead of time. A build-time script synchronizes the product catalog with Stripe's records. The static site references Stripe Price IDs rather than raw prices.
Inventory Without a Database
For simple inventory tracking, Stripe's product metadata works. Each product has a "stock" field in metadata. Purchases decrement the count via webhook.
This isn't real-time—the static page can't display current stock without an API call. But it handles the core requirement: preventing overselling by checking inventory at checkout time.
For real-time stock display, a lightweight API endpoint queries Stripe's product data. This adds a dynamic element but keeps it minimal—one API route rather than full server rendering.
The Webhook Handler
Stripe webhooks notify you when events occur: successful payments, failed charges, refunds. A single serverless function handles these events.
When a checkout completes, the webhook handler decrements inventory, sends confirmation emails, and performs any other post-purchase logic. This is the only server-side code in the entire system.
Serverless deployment means the handler scales automatically and costs nothing when idle. The architecture remains essentially static with a thin dynamic layer for post-purchase processing.
Performance Characteristics
The performance difference is dramatic. Time to first byte drops from hundreds of milliseconds to tens. Largest contentful paint improves proportionally. Lighthouse scores approach 100.
Hosting costs drop equally dramatically. CDN hosting for static files is nearly free at most traffic levels. No application servers to provision, scale, or maintain.
The architecture handles traffic spikes effortlessly. CDNs are designed for massive concurrent load. There's no database to bottleneck, no server to overload.
The Tradeoffs
Static e-commerce isn't universal. What you lose:
Real-time inventory display requires API calls. Dynamic pricing—sales, user-specific discounts—requires server logic. User accounts and order history need a database. Complex promotions need backend computation.
What you gain:
Sub-second page loads globally. Zero server maintenance. Infinite scalability. Lower hosting costs. Better SEO from faster pages.
When It Fits
This architecture suits catalogs under 10,000 products with relatively stable inventory. Product-focused businesses where the shopping experience is browse-heavy and checkout is straightforward.
It doesn't suit marketplaces with user-generated listings, businesses with complex pricing rules, or operations requiring real-time inventory accuracy.
The decision isn't static versus dynamic. It's understanding your requirements and choosing the architecture that serves them with minimal complexity.
The Design Philosophy
The insight behind static e-commerce is that most e-commerce complexity is unnecessary for most use cases. The long tail of online stores doesn't need enterprise features. They need fast pages, reliable checkout, and low operational burden.
By outsourcing payment to Stripe and outsourcing hosting to CDNs, the merchant focuses on products and customers rather than infrastructure. The technology becomes invisible—which is exactly what technology should be.