In Frontity the HTML (markup) is pre-rendered dynamically by a node server or serverless and then it is served by a CDN. The only difference with static sites is that when the CDN considers the asset stale it will revisit the dynamic node/serverless service that would pre-render a new and updated HTML.
That is of course our recommended configuration. But it’s the same case for static site generators, they recommended to not serve the HTML directly from a static server (like AWS S3) but use a CDN on top.
Yes, static site generation is on our roadmap, but it’s not a top priority.
Actually, static site generation is not complex at all. All you need is a list of URLs, start the server locally in production mode, and save all the HTML files to disk. In the case of Frontity, we can extract the list of URLs from the REST API.
But even though generating static HTML files is nice for some use cases, it also introduces a lot of complexities like:
- The need for hooks to retrigger the build each time the content of the CMS changes.
- The need for incremental builds to reduce build times in medium/large sites.
- Even the need for a dynamic node/serverless service for generating previews for content editors!
At the end of the day, the gain you obtain by generating HTML on build time is really low:
It’s not faster: The static HTML is cached by the CDN, the same way that the dynamic HTML generated by Frontity is cached by the CDN, so Frontity is as fast as any SSG.
It’s not cheaper:
- For the sites that are small and do not change often the fact that a node/serverless server is not needed may seem great at first, but all those sites requirements fall into the “Free Tier” of the serverless hostings like AWS/Google-Functions/Azure/Now. Even Netlify has 125.000 free serverless requests per month. So both approaches are essentially free.
- For sites that are big and receive a lot of traffic, the bill will go to the CDN provider for the bandwitdh, not to the node/serverless server.
@403page did a load test with Frontity and the result was that 99.89% of the requests were cached, so they were served by the CDN instead of the serverless function.
- I did a calculation with a company who is currently migrating to Frontity and they pay several thousand euros per month for the hosting and have more than 100.000 pages indexed by Google and more than 15 millon pageviews per month. The cost of adding Frontity was only $50-100 per month (calculated using AWS Lambdas) which is ridiculous when compared to their other costs.
- As soon as you have any dynamic part in your pages, like forms or comments, or your content editors need to access the dashboard to publish new content, you cannot shut down your CMS. Or alternatively, if you still want to shut down your CMS, you have to search for additional external services for forms/comments that will complicate your stack and will incur in additional costs.
Security is another interesting matter to mention because HTML files can’t be hacked. The only way to hack it would be to gain access to your static server and substitute those files, which is the very same risk of a serverless service, because even if someone gains access to that serverless execution, the file system of a serverless execution will be removed and the next time that funciton would be executed the “hack” won’t be there anymore. So in that regard, Frontity with serverless is as unhackable as HTML files.
The real benefit of static sites in terms of security is to be able to shut down your CMS. But as I already mentioned that is not possible/practical for a medium/large site that needs their content editors to access the dashboard and publish content every day. To mitigate that risk, people can do things like add a firewall to reject traffic from IPs not belonging to their editors, but they need to bypass the dynamic parts like forms or comments. For Frontity, a bypass of the REST API (or GraphQL in the future) is also needed. That’s the only difference in terms of security of Frontity vs a SSG: public access to the REST API.
I reckon that static site generation got a lot of marketing and hype lately in the JS/React developer ecosystem, but so far they are being used mostly for small sites. Using static site generation for a big publisher site is another story. And even once SSG frameworks like Gatsby solve the problems of previews and incremental build times I mentioned earlier, they still won’t have much benefits over a serverless dynamic approach like the one of Frontity or Next as I explained.