Speed is a notable characteristic of a JAMstack site. With a JAMstack setup, sites are served as static assets, and avoid the extra round trip to the origin server for content. Pre-rendering sites ahead of time means that the time it usually takes to build a site is significantly reduced, and content can be served immediately upon request. The cache plays a crucial role in making this possible. Caching greatly improves site load times by enabling access to resources that have either been fetched from a previous site visit or retrieved in advance.

It’s worth mentioning that the technique of leaning on the cache to speed up load times is not unique to the JAMstack. Monolithic, server side sites similarly depend on the cache to optimize server response time. Though the first request incurs a lengthy Time To First Byte (TTFB) (because of the need to travel to the origin server), subsequent requests can be served from the cache for quick and fairly consistent content delivery. Despite this, static sites still come up tops in terms of speed as opposed to monolithic sites. This is largely a result of how the cache is managed in either setup. As the popular adage goes, cache invalidation is one of the hardest problems in computer science. In a monolithic setup, the cache needs to be invalidated appropriately so content served to users is the most up to date. While there are solutions to handling this like Fastly’s Surrogate Key HTTP headers to categorize and tag cached assets, and the stale-while-revalidate header to keep stale content around while waiting for revalidation, crafting caching strategies takes a lot of time and effort. Not to mention, a poorly executed caching strategy can cause unexpected errors and redundant trips to the server that add time to page load. In the context of the JAMstack, the cache is automatically populated and persisted with every new site build. This means that developers can simply rely on the build process to handle cache invalidation and remain confident that their content is fast and never stale. The sole reliance on edge nodes for content delivery also means that sites are fast from being served as close to the user as possible.

If you’re keen on digging into numbers around how fast JAMstack sites really are and how the cache can be optimized for speedier, more reliable sites, check out these fantastic resources:

• CSS Tricks article on JAMstack speed by numbers

• JAMstack performance discussion on HTTP Archive

• Caching strategies for JAMstack sites on Netlify