Why it is fast
There is no database query and no template rendering at request time. A CDN serves a finished file from an edge location, which is roughly the cheapest and most reliable thing the web can do.
It also helps with AI visibility for a duller reason: the content is in the HTML. Anything rendered by client-side JavaScript after load may never be read by a crawler or a model, and content that is not read cannot be cited.
| SSG | SSR | Client-side | |
|---|---|---|---|
| Rendered | At build time | Per request | In the browser |
| Speed to first byte | Fastest | Moderate | Fast, then slow to paint |
| Content in the HTML | Yes | Yes | Often not |
| Readable by AI crawlers | Reliably | Reliably | Frequently not |
| Cost of a content change | A rebuild | None | None |
The trade-off
Content changes require a build. For a marketing site publishing a few times a week that is invisible, since builds run in seconds to minutes. For a site with thousands of pages updating constantly it becomes a real operational cost.
- Good fit: marketing sites, documentation, blogs, campaign pages
- Awkward fit: anything with per-user content or live inventory
- Middle ground: incremental or on-demand rendering, which rebuilds only affected pages
Where it sits next to a CMS
The pattern that suits B2B marketing is a headless CMS for editing plus a static build for delivery. Editors work in a familiar interface, a webhook triggers a rebuild, and the published site stays a set of files.
Why it matters for B2B marketing teams
The part that matters for B2B is not the speed, it is that your content exists in the HTML. Marketing sites built as client-rendered applications routinely find their best content is invisible to the AI crawlers deciding who gets cited.