Comment by exiguus
8 days ago
Think about product stock that change or you have a website with a cms and 100 Editors that push changes every 5min. If you have 5k pages. Then its likely, that builds take longer then 5min. And if you want to have a up-to-date website, you have to build it every 5min. This is where ISR and SSR comes into play, to update the pre-rendering on the server.
5k pages in 5 minutes? That's only 16/second. If your generator/server is on the JVM I'd expect it to be capable of more like 5k/second at least (and if you have a sensible `last_updated` or `version` field, you could early return with a Not Modified for even better performance). If you're batch processing, you could do a lot better than that.
Why would you rebuild the site every time an editor updates a page? Just update the page that was edited. Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
That's a good suggestion, and it works well if you know which sites have changed before building.
> Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
This is essentially what Incremental Static Regeneration (ISR) does.
But, mostly you pre-render it, because else, the first user has to wait to long for the page. ISR is also re-rendering for the next user. The current user has the old version and the page is re-rendering in the background for the next user.
The JAMstack architecture is advantageous because it allows for the use of simple servers—essentially S3 buckets that can serve static files. This setup requires less security patching and reduces costs for server hardware. Additionally, the server essentially acts as your cache, allowing you to distribute it widely.
My website has about 700 pages. A full rebuild takes around 10 seconds.
That's nice, how many API requests in build-time do you have per page?
Zero. Sometimes one to generate pronunciation audio for glossary entries. Everything else is local content.