Short write‑ups of problems we hit running a real commerce operation and what we changed in the code because of them. No product announcements; just the reasoning.
Nobody on the team is an SEO specialist, and dozens of storefronts on one codebase rank anyway. That is because almost everything that matters is plumbing that a storefront engine either does for every shop or does for none — a computed canonical URL nobody types by hand, a 301 that follows a discontinued product to its family, a sitemap index regenerated nightly with a real lastmod, structured data that obeys the same price rules as the page. What we built, what we skipped on purpose, and the three things that bit us anyway.
After a flush, the first visitor to each storefront page pays for the render. We have written the thing that pre‑pays three times: a link‑following crawler from a package, a two‑pass seeder‑then‑deep crawl with concurrency rules, and — the one we kept — a list of the pages people actually visit, fetched in order of traffic, at a concurrency that can never outbid a live shopper. Why each version was wrong for the next stage, and the surge‑protection bug that made the warmer most aggressive exactly when it should have been gentlest.
Every storefront page sends one small request to our own endpoint — not to a third party. From it: visitors, sessions, page views, country, device, referrer, the traffic source that becomes attribution, registration and add‑to‑basket conversions, "who is on the site right now", product interest per customer, and the list of most‑visited pages that decides what the cache warmer warms. Why a beacon that fires on cached pages was the only design that could work, how bots are filtered, and what we deliberately do not collect.
Every storefront page is rendered once on the server — so crawlers and slow phones get full HTML — and once more in the browser, where it becomes an app. How Inertia server‑side rendering runs here (a Bun process under a supervisor, health‑checked on every deploy), what a 418 KB props payload taught us about where the second actually goes, the silent client‑side‑rendering incident, and the three levers we keep on the list.
226,000 images — product photos, family banners, logos, pallet photos, chat attachments — stored once and never resized by us. Every image on every page is a signed URL to an image proxy that resizes, crops and converts on the fly: AVIF and WebP with a fallback, a retina variant of each, the right width for the slot, cached at the edge. Why a proxy beat pre‑generated thumbnails, how the signature stops the proxy being a free resizer for the internet, and the "picture" element every card uses.
Why a trading company wrote its own CMS instead of bolting a shop onto a page builder, and how two front‑end engineers turned "we need a product page" into seventy‑odd web blocks, a workshop that edits the live site, snapshots you can publish and roll back, and a storefront that knows its own catalogue.