Static generation is a caching strategy, not an architecture
Prerendering makes a site fast and cheap. It also quietly bakes every assumption your code makes about the request into the HTML you ship.
A static build is a promise that the output does not depend on who is asking. Most of the time that is true. The bugs live in the places where it quietly is not.
The request origin is not your domain
During prerender there is no real request. Helpers that read the request URL resolve against whatever origin the build server happens to use, which is usually localhost. If that value only feeds a fetch call, nothing breaks. If it is written into a canonical tag, a share link, or structured data, it is now in the HTML you deployed.
The fix is to read the configured public URL and treat the request origin as the fallback, not the source. It costs one helper and removes a class of bug that only appears in production, which is the worst place to find it.
Lazy data is not awaited
Lazy async data exists so a page can paint before every request settles. During prerender that is precisely wrong: the generator does not wait, so whatever the lazy call would have rendered is simply absent from the output. For anything that produces internal links — related posts, navigation, sitemaps — the blocking call is the correct one, even though it looks slower in dev.
Images are where the wins are
A prerendered page with a single fixed-width hero image hands a phone the same file it hands a desktop. A srcset with three widths is a handful of characters and routinely halves the largest contentful paint on mobile. Nothing else in a static build is that cheap for that much.
None of this argues against static generation. It argues for knowing which of your assumptions the build is allowed to freeze.
