SSG vs SSR: What's the Difference?
SSG (static site generation) and SSR (server-side rendering) are two ways to produce a web page's HTML. With SSG, pages are built once ahead of time, at deploy, and served as ready-made files, so they load fast but show the same content until you rebuild. With SSR, the server builds each page fresh on every request, so content is always current but each visit does more work. SSG suits content that changes rarely, like marketing and blog pages; SSR suits pages that must reflect live, personalized, or frequently changing data.
- SSG
- HTML built ahead of time at deploy and served as static files
- SSR
- HTML built on the server fresh for each request
- SSG strength
- Fastest delivery and cheap to host; excellent for cacheable content
- SSR strength
- Always-fresh, personalized content on every request
- Both
- Send real HTML, which helps search engines index content (Google Search Central)
- Modern frameworks
- Next.js, Astro, Nuxt let you mix both per page (U.S. market, 2026)
What SSG and SSR each mean #
SSG and SSR both answer one question: when is your page's HTML created? Static site generation builds every page in advance, during a deploy step, and stores the finished HTML as plain files. When a visitor arrives, the server, or a CDN, simply hands over the pre-built file with no per-request work. Server-side rendering flips the timing: the server runs your page's code fresh each time someone requests it, assembling the HTML on the spot with the latest data before sending it. Both approaches deliver fully formed HTML to the browser, which distinguishes them from pure client-side rendering, where the browser receives a near-empty shell and builds the page itself. The choice between SSG and SSR shapes speed, hosting cost, content freshness, and how you manage updates. We weigh these trade-offs for every project in /services/web-app-development, matching the rendering strategy to what each type of page actually needs rather than applying one method everywhere.
How static generation works #
With SSG, page building happens once, at deploy time, not when users visit. A build process runs your templates, pulls in content from files, a CMS, or an API, and outputs a folder of finished HTML pages. Those files are then uploaded to hosting or a CDN, where serving them is trivial: read the file, send it. Because no code runs per request, static pages are blisteringly fast, cheap to host, and hard to break, there is no live server logic or database to fail under load. The catch is freshness. If your content changes, the site shows the old version until you run another build and redeploy. Modern static frameworks ease this with incremental builds and webhooks that trigger a rebuild when your CMS updates, so publishing feels quick. For marketing sites, documentation, and blogs, this model delivers outstanding performance, which is why we often pair SSG with the tuning in /services/speed-optimization for content-driven sites.
How server-side rendering works #
SSR builds the page on demand. When a request arrives, the server executes your page code, fetches current data, perhaps a logged-in user's dashboard, live prices, or personalized recommendations, and renders fresh HTML for that specific request before returning it. The visitor always sees up-to-date content without any rebuild. The cost is that real work happens on every single request: the server must run code and often hit a database, which uses more resources and can be slower than serving a static file, especially under heavy traffic. Good SSR mitigates this with caching layers so identical requests reuse recent output, blending freshness with speed. SSR shines for pages that genuinely differ per user or per moment: account pages, search results, checkout, real-time inventory. Running SSR reliably requires a proper application server and monitoring, which is why we host and maintain these apps under /services/managed-hosting rather than treating them like simple static files.
// SSG: built once at deploy time
export async function getStaticProps() {
const posts = await loadPosts();
return { props: { posts } };
}
// SSR: built fresh on every request
export async function getServerSideProps(ctx) {
const user = await getUser(ctx.req);
return { props: { user } };
}Speed and performance compared #
On raw delivery speed, SSG usually wins. A pre-built file served from a CDN edge reaches the browser with minimal Time to First Byte, the fastest possible start. SSR must run code and often query data before it can send anything, so its TTFB is typically higher, though caching narrows the gap for popular pages. Both approaches, however, send real HTML, so the browser can start rendering content immediately, which benefits Largest Contentful Paint far more than client-only rendering. For a small business, this means SSG is the natural choice for pages where every millisecond counts and content is stable, while SSR's slightly slower start is an acceptable trade for pages that must be current. The right answer is often a mix. We measure real-world results with /tools/website-grader after launch, because the theoretical speed advantage of SSG only matters if the whole page, images, scripts, fonts, is optimized alongside it. Rendering method sets the starting speed, but the rest of the page decides whether that head start survives all the way to a fully interactive screen.
Content freshness and updates #
The clearest divide between the two is how content stays current. SSR is always fresh: every request reflects the latest data, so a price change or new inventory count appears immediately with no extra step. SSG shows whatever existed at the last build, so updates require a rebuild and redeploy before visitors see them. For a blog that publishes weekly, that delay is a non-issue, and automation can rebuild within minutes of an edit. For a stock ticker or a personalized feed, waiting for a rebuild is unacceptable, and SSR, or client-side data fetching, is required. Many sites split the difference: static shell with live data loaded in the browser for the few dynamic pieces, or newer patterns like incremental static regeneration that rebuild individual pages on a schedule or on demand. Deciding which pages need live data and which can be static is a core part of planning we do in /services/web-app-development, aligning freshness needs with performance and cost.
SEO implications of each #
For search engine optimization, the crucial fact is that both SSG and SSR deliver complete HTML in the initial response, so crawlers see your content immediately without needing to run JavaScript (Google Search Central). This is a major advantage over pure client-side rendering, where search engines must execute scripts to find content, a slower and less reliable path. Between SSG and SSR themselves, SEO differences are minor and mostly about speed: SSG's faster load can marginally help Core Web Vitals, a ranking signal, while SSR's freshness helps content that must be indexed the moment it changes, like news or listings. Both support proper meta tags, structured data, and canonical URLs. The real SEO risk is choosing client-only rendering by accident and shipping empty HTML. When we plan a site's architecture alongside /services/seo-services, we make sure the rendering method delivers indexable HTML for every important page, whichever method fits that page best.
Hosting cost and complexity #
The two models have different operational profiles. SSG output is just files, so it can be hosted almost anywhere, often on inexpensive or free static hosting and CDNs, with little to maintain and almost nothing to attack. There is no live server logic to crash under a traffic spike; the same static file serves ten or ten million visitors. SSR needs a running application server that executes code for each request, which costs more, must scale with traffic, and requires monitoring, patching, and careful caching to stay fast and stable. This complexity is worth it when pages genuinely need it, but pointless when they do not. For budget-conscious small businesses, defaulting to static where possible keeps hosting cheap and reliable, reserving SSR for the pages that truly require it. We manage both models, and the hybrid in between, through /services/managed-hosting, sizing infrastructure to the site's real needs rather than over-provisioning. For many small businesses, that means static by default, with a small server added only where a page genuinely earns it.
Choosing the right approach #
For most small-business sites, the best answer is not one or the other but a deliberate mix, which modern frameworks like Next.js, Astro, and Nuxt make easy per page. Static-generate everything that can be: home, services, about, blog, and other stable marketing pages, for maximum speed and minimum cost. Server-render or client-fetch only the pages that must be live or personalized: account areas, real-time inventory, search, checkout. This hybrid gives you a site that feels instant where speed matters and stays accurate where freshness matters, without paying SSR's cost on every page. The verdict for a typical small business: lean static by default, add SSR surgically where the data demands it. We make these per-page decisions during architecture in /services/web-app-development, then optimize the whole result in /services/speed-optimization, so your rendering strategy serves both your visitors' experience and your hosting budget rather than forcing a single compromise across every page.
FAQ
Which is faster, SSG or SSR?
SSG is usually faster to deliver because pre-built files are served instantly, often from a CDN, with minimal Time to First Byte. SSR must run code and fetch data per request, adding delay, though caching helps. Both send real HTML, so both start rendering faster than client-only rendering.
Is SSG or SSR better for SEO?
Both are good, because each sends complete HTML that search engines can index without running JavaScript (Google Search Central). SSG's speed slightly helps Core Web Vitals; SSR's freshness helps pages that must be indexed the instant they change. The real SEO mistake is accidentally shipping empty client-rendered HTML instead.
Can I use both SSG and SSR on one site?
Yes, and most modern sites do. Frameworks like Next.js, Astro, and Nuxt let you choose the rendering method per page. Static-generate stable marketing pages for speed, and server-render only pages that need live or personalized data, giving you the best of both approaches.
Why does my SSG site show old content?
Because static pages are built at deploy time and only change when you rebuild. If content updates in your CMS but the site was not rebuilt, visitors see the previous version. Automated rebuilds triggered by content changes, or incremental regeneration, keep static content fresh.
Does SSR cost more to host?
Generally yes. SSR needs a running application server that executes code for every request and scales with traffic, which costs more than serving static files. SSG output can often be hosted cheaply or free on a CDN. Reserving SSR for pages that truly need it controls cost.
What about client-side rendering?
Client-side rendering sends a near-empty HTML shell and builds the page in the browser with JavaScript. It can feel app-like but risks slower first paint and weaker SEO if crawlers do not run scripts well. SSG and SSR both send real HTML upfront, which is usually safer for content pages.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?