Jamstack and the return of HTML

The premise was old but the timing was new in 2019. A product site that updates twice daily does not need to render HTML for every visitor request dynamically. It could pre-render pages at build time, then serve static HTML from a CDN. Latency would be better and cost would be lower.

The build pipeline was mature enough by 2019 to handle this approach reliably. Deploy took minutes, not hours. CDN edges were everywhere geographically. What was different was not the technology itself. It was that the economics finally worked for mid-size businesses and smaller teams.

The cost model inverts in this approach completely. Instead of paying for a server to be always-on, processing each request, you pay for computation when you deploy. Build servers are cheaper to run than request servers when traffic is uneven and hard to predict.

For catalogues with stable structure and product pages that do not change minute-to-minute, this approach wins completely. Fast performance, cheap operation, simple to understand. The risk moves from runtime availability to deployment pipeline correctness and speed.

The limit shows up when you need personalized content or when pages number in the thousands and changing requires rebuilding everything. That is the boundary where Jamstack approaches stop being practical. Stay below it and Jamstack is straightforward. Cross it and you are rebuilding the same server architecture, just with different timing.

We shipped several sites this way with strong results for clients. The clients who needed true personalization realized quickly that pre-rendering was not the answer. The ones who did not came out ahead on both cost and performance metrics.