Why HTML Is the Hard Part of CDN Caching
Serving static assets like images, CSS, and JavaScript from a CDN has been standard practice for years. Give an asset a URL, move it to a CDN, and handle changes by altering that URL — e.g. style.324535.css or style.css?v=345434 — so browser caches can be used aggressively. HTML is different. The URLs for HTML pages are the public-facing URLs of a website, and those URLs don't change. Historically, that meant accepting that HTML had to be served from origin servers, with performance tuned as best as possible there.
The Jamstack architecture changes that assumption. Instead of treating HTML as something that must be dynamically generated on each request, Jamstack treats it as a static artifact that can be served from a CDN alongside everything else.
Hoisting Computation to the Edge
Guillermo Rauch describes this as "hoisting," borrowing the term from JavaScript's behavior of moving declarations to the top of their scope. In the Jamstack context, static assets are hoisted higher in the hosting stack — moved to the edge, closer to visitors.
The key idea is to pre-render as much as possible during the build phase. Computation that would otherwise happen later in the request timeline is performed once, up front, and the result is shared by all users. The more that can be shifted to build time, the less work remains for the request path.
This hoisting happens automatically: whatever can be hoisted will be. Things that genuinely require server-side execution — cloud functions, API calls, dynamic logic — can still run. But the boundary is not fixed. In a discussion with Brian Leroux, Dave and I explored how even the results of cloud function execution can be cached and served from a CDN, pushing more of the request lifecycle toward the edge.
