Performance
Static site generation
Also called SSG.
Static site generation is building every page into plain HTML files at deploy time, then serving those files with no application code running per request. Visitors get a prebuilt document from a CDN.
How it is measured
Look at the build output folder: an `index.html` per route. Time the build, which can take seconds or hours for a large site, and read TTFB for a page. A CDN-served file often returns in 20 to 80 ms. Page count times build time per page is the scaling constraint.
To confirm a page is static, curl the URL twice with JavaScript irrelevant: the body should be identical, with cache headers set by your host. Content changes need a rebuild or an incremental regeneration.
Worked example
A conference site built with Astro has 340 pages of schedule, speakers, and sessions. A full build takes 41 s. Every page is served from a CDN with TTFB around 35 ms and LCP of 1.2 s on 4G. On the morning of the event a room changes; the editor fixes a Markdown file and the redeploy finishes in 1 minute 20 s.
A 40,000-page catalog at the same per-page rate would take about 80 minutes to build, which is where incremental regeneration or server rendering become attractive.
How it differs
SSG renders once at build, and SSR renders on every request. SSG cannot show per-user content or anything fresher than the last deploy. SSR can, but it costs server time on every hit and a server bill.
Common errors
Statically generating pages that need per-user data. Letting build times grow unnoticed. Forgetting to rebuild when the CMS changes. Shipping unoptimised images straight into the build. Assuming static means no JavaScript.
In practice
If most of your pages change less than daily, generate them statically and put them behind a CDN. Hook your CMS to a rebuild webhook. Time the build, and once it passes ten minutes, look at incremental regeneration for the long tail.