The project is using Gatsby Cloud and Contentful. The key problems they have encountered are a) build times being painfully slow (+5 minutes per content change) and therefore b) the authoring/publishing experience is really poor as you can't easily see previews. These seem to be common complaints of static site generators (I'm also skipping over the general complexity required to get a website up and running with so many moving parts)
In order to tackle this problem, Gatsby offers a rendering feature called "DSG" (Deferred Static Generation) [2]. When enabled, instead of building all of your content up-front (the entire point of a statically generated site), only your core pages are generated at build-time. The rest of your "long tail" pages are only generated when someone first access them. To use this feature, you need to put a server in-front of your static site.
What?! It seems that the build times with statically generated sites have gotten so bad that the work-around is to literally go full-circle and re-create a dynamic website. The two big benefits of statically generated sites are apparently performance and server-less infrastructure, yet to deal with the downsides of generating pages up-front you need to introduce ... dynamically generated pages ... via a server.
I don't understand who this is for? Any company that requires the touted performance gains that statically generated sites offer will surely also need quick builds and a good authoring experience? But to get those build times down you have to re-introduce infrastructure and dynamically generated pages?
Are there teams out there that are happy with their statically generated sites? Am I going mad?
[1] https://jamstack.org/ [2] https://www.gatsbyjs.com/docs/how-to/rendering-options/using-deferred-static-generation/
There's also a cache feature in Gatsby that might be able to help reduce the 5 minute build time.
- api for creating pages from remote data
- developer experience
- build speed
But if you plan on using a headless CMS, your must prioritize decoupling the authoring from build times.Your marketing team needs instant feedback, your options are now:
- use client side rendering for page previews. (i.e. use a js-based framework)
- containerize your project & run the framework's dev mode as a preview server (i.e. you might as well have not used a SSG)
True, for a hobbyist updating a blog a couple times per month, it works great.
No Wordpress nightmares to wake you up at night, no databases going down and taking your site offline. And, should I mention performance? Once the site is built and deployed, that is.
Also, no limits as to how you can configure your site. With a bit of coding, you can usually make the static site generator do your bidding.
Personally, I use Eleventy [1]. My site has 200+ pages and the build time is not an issue.
Now, I am authoring manually in Markdown using VS Code. That's probably not the right tooling for the editors at some content shop.
Many static generators do have hooks into CMS's. Eleventy, for example, has a plugin that interacts with the Ghost CMS API [2]. I haven't tried it but if I read it right, it can suck content out of Ghost and publish it as static HTML.
That might be a way to get the best of both worlds: a comfortable authoring experience AND the performance of a static site.
My argument for why the content shops should give the JAM stack a try is based on a recent experience.
I was helping out a team developing a large content website with hundreds if not thousands of articles and many updates throughout the day.
I was there mostly for backend work and DevOps. And boy, did I have my hands busy!
We hosted on a PaaS with maxed-out specs for both the application server and the database (Postgres). The bills must have been in the four figures monthly just for the servers. And yet, it took us months to get the performance to a level that was even acceptable: not great but okay-ish.
I would not recommend a database-backed CMS for a popular content website if we could avoid it at all, and if budget was a thing. Rather, I'd explore how to make a JAM stack-based solution work for the client.
With that said, I concede that yes, of course the static site generators have their own issues. The right answer depends on which tradeoffs you are willing or able to make.
[1] https://www.11ty.dev/ [2] https://www.npmjs.com/package/eleventy-plugin-ghost
Other people I've seen use them to great effect are photographers who have static sites generating based exclusively of images that they upload. As there's no real text content, they don't end up doing many "changes" as they generally upload images in bulk.