The JAMstack is a robust way of building sites where the heavy lifting of content ingestion and site generation happens on build time. This approach eliminates the general back and forth between server and client and serves static assets upfront right from the CDN. Despite the many performance and security benefits that this brings, the JAMstack can seem like overkill for sites with hundreds, if not thousands of pages. With the regular build to deploy cycle, a single one-line change triggers the propagation of a fresh instance, which takes up a lot of time and bandwidth. In a competitive market where frequent content updates are critical—like in the case of a news website—the delay is a significant disadvantage. Thankfully, there are a number of ways to circumvent this problem. The simplest way to address long, hefty builds is to use a static site generator like Hugo that is built to handle large builds. Compared to many other static site generators (SSGs), Hugo can build a site with over 40,000 pages in a matter of minutes.
If migrating your site over to a different framework feels like too much work, try optimizing for the CDN cache. Often, CDNs derive much of their efficiency from files whose checksums have not changed between deploys. In a build that optimizes for the cache, only files that have been changed are re-uploaded and re-processed by the CDN. This means build times can be vastly reduced. Additionally, users benefit from faster site speeds since their browser doesn’t have to re-download files that they already have cached.
In addition to the aforementioned solutions, the JAMstack offers the ability to lean on serverless functions to serve content while waiting on a large build to finish. Rendering content via serverless functions is a great fallback for optimistic URL routing when the page for new content is not yet ready for preview. This concept is akin to server-side serverless rendering. It takes advantage of custom redirects where a 404 is redirected to a serverless function that populates a page with content. This is especially useful if content on a site is decoupled via a separate headless CMS system or database; Because you can easily pull realtime updated content with a serverless function and give users instant access to it.
All in all, a site no matter the size can benefit from a JAMstack approach. Making it work however, will require employing some nifty tricks to fully benefit from the speed, security and maintainability that the JAMstack provides. For more on the approaches mentioned above, check out these resources:
Top comments (1)
For me I think the bigger issue is how to build fast enough.
I have a svelte / sapper site with 30,000 pages, but we use multiple massive aws faregate instances to build fast enough, and push to a S3 bucket.
Personal question Divya, is there a way to deploy to netlify and benefit from the immutable deploys and CDN, but build elsewhere do the resource needs? Paying 1k for a large builder does not make sense when each build costs me 2 cents now.