Static Hoisting
The other day in “Static or not?” I said:
[…] serving HTML from a CDN is some feat.
What I meant is that serving resources like images, CSS, and JavaScript from a CDN is fairly straightforward. The industry at large has been doing that for many years. An asset with a URL can be moved to a CDN and served from it. Changes to that asset are usually handled by changing the URL (e.g. style.324535.css, style.css?v=345434 or the like) so that we can take full advantage of browser cache. But HTML is a little different. The URLs to our HTML are the URLs of our public-facing websites and those URLs don’t change.
Historically, we’ve said “oh well” to this. Our web servers will serve our HTML and we’ll just do the best we can with performance there. But the Jamstack approach is changing that by saying, actually, we’ll serve that HTML from a CDN as well.
Guillermo Rauch calls that “hoisting” and likens it to how JavaScript hoists declarations higher in code. Jamstack hoists static assets higher in the hosting stack.
What Jamstack as a software architecture has now made possible, however, is to hoisting the results of computation to the edge, right next to where your visitors are.
A core tenet of Jamstack has been to pre-render (pre-compute) as much as possible, which has given prominence to static site generation. The key idea is that computation that would have happened later on, in the request’s timeline, has now been shifted to the build phase, performed once and made available for all users to share.
Hoisting, notably, happens automatically. What can be hoisted will be hoisted. But things that need servers to run (e.g. cloud functions and API stuff) can still do that. Getting even more complex, in our talk with Brian Leroux, Dave and I got into how even the results of cloud function execution can be put on a CDN and cached.
Direct Link to Article — Permalink
The post Static Hoisting appeared first on CSS-Tricks.
