Same Store, Served as Files: 544 ms to 5 ms on a Cache Miss

The furniture shop from the WooCommerce stand next door, rebuilt as a static front on Astro 5. Same catalogue, same prices, same orders — 421 products per language pulled from the WooCommerce Store API and written to 983 HTML files that nginx hands out with no PHP, no Node and no database in the request. Both storefronts score 100 on mobile Lighthouse, and saying otherwise would be a lie: the theme is built well. The difference is what that 100 costs. On a microcache hit WordPress answers in 2 ms — faster than us. On a miss it spends 544 ms building the page, and a cache has to miss eventually: after a product edit, at expiry, on the first visit to a rare page. Static has nothing to miss — an address nobody has ever requested still answers in 5 ms, because there is nothing to build. The document is 4.3 KB against 12.7 KB, JavaScript 6 KB against 13 KB. The cart is a real cart: it lives in the shop through a Cart-Token, and an order placed here appears in the WooCommerce admin of the other stand with real Nova Poshta rates. A build log at /builds/ shows every rebuild with the products that changed and the number of files rewritten — usually 18 of 1428, because the deploy hardlinks the previous release and touches only what differs. What the stand does not do: no money moves, product images are drawings generated from dimensions rather than photographs, and the catalogue follows the neighbouring shop's 6-hour reset within 5 minutes.

• Press one button and your own browser times both storefronts on the same product
• 544 ms to 5 ms first byte on a cache miss — where the real difference lives
• An order placed on the static front lands in the WooCommerce admin next door
• Public build log: which products changed, which files were rewritten, how long it took
• Change one price and 11 of 1428 files are rebuilt — the product, its listings, its neighbours
• Ukrainian page loads 95 KB of fonts instead of 170 KB, in 6 files instead of 9