Static Hoisting

In a previous post, "Static or not?", I mentioned that serving HTML from a CDN is a significant achievement. Let me clarify: serving assets like images, CSS, and JavaScript from a CDN is relatively simple and has been standard practice for years. An asset with a URL can easily be migrated to a CDN. Updates are managed by altering the URL (e.g., style.324535.css, style.css?v=345434), leveraging browser caching effectively. However, HTML presents a unique challenge. HTML URLs are our website's public-facing addresses, and these URLs remain constant.

Traditionally, this limitation was accepted. Web servers handled HTML delivery, with performance optimization as the primary focus. The Jamstack approach, however, revolutionizes this by enabling HTML delivery from a CDN.

Guillermo Rauch coined the term "hoisting," drawing a parallel to JavaScript's hoisting mechanism. Jamstack elevates static assets higher within the hosting infrastructure.

Jamstack architecture now allows hoisting the results of computation to the edge, closer to the user.

A fundamental Jamstack principle is pre-rendering (pre-computing) as much as possible, emphasizing static site generation. Computation, typically deferred until a request, is shifted to the build phase, executed once, and shared across all users.

Importantly, hoisting is automated; eligible content is hoisted automatically. Server-dependent processes (e.g., cloud functions and APIs) remain unaffected. Furthermore, as discussed with Brian Leroux, even the outputs of cloud function executions can be cached on a CDN.

The above is the detailed content of Static Hoisting. For more information, please follow other related articles on the PHP Chinese website!