What is SSG?

What Is SSG?

Introduction

Developers love acronyms. You've probably heard of SPA, SSR, SSG, JAMstack… and wondered:

What the heck are they talking about?
Does this affect me if I just want to build a website?

Today, we’ll focus on one of those acronyms: SSG.
We'll see what it is, what it's for, what problems it solves (and which ones it doesn’t), and how it can help you create faster, more secure, and easier-to-maintain websites.

TL;DR

SSG stands for Static Site Generation.

The idea? Instead of generating a web page every time someone visits, the site is pre-built at build time. While building the site, you use modern components, access data from APIs or HCMS, generate all possible page combinations, and the result is ready-to-deploy static files: HTML, CSS, and JS.

Advantages:
✅ Ultra-fast load times
✅ Perfect SEO
✅ Simpler security and maintenance
✅ Easy to deploy and scale

An Example to Understand It

Imagine you're tasked with building a corporate website. Requirements:

  • Good search engine ranking
  • Low resource usage
  • Fast loading
  • Easy to maintain
  • Non-technical people should be able to update content (news, events...)

Let’s look at possible solutions.

Option 1: Classic PHP

A valid option would be to use PHP, as has been done for years. Thousands of sites still run fine on PHP.

Same goes for ASP.NET MVC or other technologies that are multi-page applications (i.e., apps where the server generates a new HTML page for each route).

How does a classic PHP page work?

  • You have a file mixing:
    • HTML for structure and JavaScript for client-side interactions.
    • PHP for dynamic server-side logic (e.g., showing blog articles from a database, generating HTML on the fly).
  • When someone visits a page, the server executes the PHP code, generates the HTML, and sends it to the browser.

PHP Diagram

Here we have simplified the diagram. In addition to HTML, CSS and JS can also be served, but the important thing is that the HTML is generated on the server.

This means every page visit triggers PHP code execution, HTML generation, and response delivery. The returned HTML contains the full content.

Drawbacks:

  • Requires a configured server with PHP → adds maintenance and attack surface.
  • Each page is generated in real time on every visit → consumes CPU and memory (cache mechanisms help but aren’t perfect).
  • Load time depends on how fast the server builds and sends the page.

Still useful, but if you want speed, simplicity, and lower maintenance, there are modern alternatives.

Option 2: SPA (Single Page Application)

“What if we use React, Vue, or Angular?”

If you DON’T use a meta-framework like Next.js or Nuxt, you're working in Client Side Rendering (CSR) mode. That means: the server delivers a basic page, and all content is rendered in the browser using JavaScript.

How it works:

  • Server sends a basic HTML with a JavaScript script.
  • No server-side logic is executed.
  • The content is fetched and generated dynamically in the browser (e.g., using REST APIs).

react-diagram-en.jpg

Pros:

  • Delivered as static files.
  • Easy to deploy and scale.
  • Good experience after the app is loaded.

Cons:

  • Slower first visual impact, since content is built after JS loads.
  • Limited SEO: Search engines may not index JavaScript-generated content properly (though it's improving).

SEO (Search Engine Optimization) is the process of improving a website so it appears among the top results in search engines like Google. These engines mainly read the HTML sent by the server, and in a SPA, that HTML is often nearly empty, making it hard for your site to rank well.

Great for highly interactive apps (dashboards, internal tools), but for informational or corporate websites, lacks in SEO and initial performance.

Option 3: SSR (Server Side Rendering)

With Server Side Rendering, content is generated on the server and sent already assembled to the browser.

Benefits:

  • Faster first load.
  • Better SEO (search engines see content directly).

Frameworks like Next.js let you mix SSR with CSR. Some enhancements include:

  • Hydration: Pre-rendered HTML enhanced with JavaScript.
  • Server Components: Some UI parts rendered on the server, others on the client.

How it works:

  • First request triggers server code execution, generates HTML, and sends it with content and additional info for JS hydration.
  • Subsequent requests can be partial (data only), with the browser handling the HTML structure (like SPA mode).

SSR Diagram

It’s a blend of multi-page and single-page applications.

Pros:

  • Effective SEO.
  • Better performance than pure SPA.
  • Dynamic content with more control.

Cons:

  • Requires server infrastructure and logic.
  • Must manage scalability, caching, security, and updates.
  • Higher operational costs.

Very useful when content changes constantly. For mostly static sites, it may be overkill.

Option 4: Pure HTML

“What if we hand-write HTML and CSS?”

Sure! That’s the most direct way to build a static website.

How it works:

  • You manually create HTML and CSS files.
  • Upload them to a server or CDN.
  • Each page visit serves the static HTML file as-is—no extra processing.

Static Diagram

Pros:

  • Excellent performance: served instantly from any server or CDN.
  • Scales perfectly: can handle millions of visits.

But...

  • Maintaining content is painful. Any change means editing files manually.
  • No reuse: if you change a footer used in 10 pages, you update all 10 manually.
  • No components or structure. Projects grow messy quickly.

Scales well in traffic, not in maintenance. Not viable for medium or large projects.

Enter SSG 🦸‍♂️

Here’s where Static Site Generation shines.

With SSG you can:

  • Use modern components and logic.
  • Fetch data from HCMS, APIs, databases...
  • Generate pages once at build time.
  • Deploy a static, optimized site from anywhere.

How it works:

  • During build, the framework reads the data (from HCMS, API, etc.), generates the HTML for each page, and saves them as static files. This happens once, not on every visit.
  • When someone visits the site, the server simply serves those pre-generated HTML files.
  • No server logic at runtime; everything is precomputed.
  • To make changes, just rebuild and deploy the new files.

SSG Diagram

Note: the diagram uses Astro, but this applies to any SSG-capable framework: Next.js, Nuxt, Gatsby, Angular, etc.

What Does SSG Offer?

✅ Speed: files are pre-generated, served instantly.
✅ Impeccable SEO: content is in the HTML.
✅ Security: no server logic = smaller attack surface.
✅ Simple deployment: Netlify, Vercel, GitHub Pages, FTP—anything works.
✅ Maintainability: use components, layouts, and modern tools.
✅ Scalability: static = no traffic concerns.
✅ Content editing: connect a Headless CMS for non-developers.

Let’s Talk Performance

Here’s a conceptual performance chart comparing the options:

Note: This is a high-level conceptual graph. Real-world performance varies by project, but it helps illustrate the differences.

Terms:

  • TTFB (Time To First Byte): Time until server responds to the initial request.
  • FCP (First Contentful Paint): Time until first visible content appears.

Highlights:

  • PHP has heavy server load. High traffic can overwhelm the server (TTFB-heavy).
  • SPA has low TTFB but high FCP due to JS execution and data fetching.
  • SSR has lower TTFB than PHP thanks to modern frameworks with caching, but higher FCP due to JS hydration.
  • SSG has very low TTFB (HTML is already generated), and fast FCP, slightly higher than pure HTML due to boilerplate JS.
  • Pure HTML has the lowest TTFB and fastest FCP—no JS needed for rendering.

Performance Graph

So, with SSG you get performance close to pure HTML, plus components, logic, and CMS support.

What If...?

💡 What If I Need to Update Content?

Use a Headless CMS. These are content managers without a visual layer, providing content via API.

Example: Content Island, lets you create and edit content without coding, then fetch it in your SSG-built site.

When someone updates content, you can set up a webhook to trigger a new build and deploy the updated site. Fully automated.

💡 What If I Need Dynamic Content?

SSG isn’t a dead end.

Modern frameworks let you:

  • Insert interactive islands (dynamic components in static pages).
  • Work in hybrid mode—use SSG where possible, SSR where needed.
  • Use Incremental Static Regeneration (ISR): HTML is built at runtime when cache expires, but users still see old content until the new version is ready.

What is ISR? ISR (Incremental Static Regeneration) is a technique that combines the best of static and dynamic content. It allows static pages to be generated on the first visit or in the background, without needing to rebuild the entire site each time.

You can have the best of each approach.

When NOT to Use SSG

SSG isn’t a one-size-fits-all.

Avoid it if:

  • You need real-time updates (e.g., live prices, chats).
  • Data changes constantly and rebuilding is too costly.
  • You need lots of runtime logic.

In those cases, SPA, SSR, or hybrid solutions may be better.

A good example would be a real-time dashboard, such as order tracking or fleet management. In this type of application, data changes constantly, regenerating pages would be costly and inefficient, and the business logic is usually complex and requires a lot of user interaction.

Conclusion

SSG is a powerful, modern technique to build fast, secure, easy-to-deploy and maintain sites with excellent SEO.

Great for:

  • Corporate websites
  • Blogs
  • Portfolios
  • Documentation
  • Landing pages

And if you use a Headless CMS, you can forget about manual content updates. Everything fits like a glove.

Other types of cases vary a lot—for example, a product catalog on an e-commerce site. If there are few products and they don’t change frequently, SSG or a hybrid approach can be a good option. But if those conditions aren’t met, it’s not the right choice.

As you can see, there are cases where SSG is clearly the best option, others where it depends on the specific needs of the project, and some where it simply doesn't apply. That’s when it makes sense to talk about SSG, SSR, SPA, and other solutions. There’s no silver bullet—you have to choose the right tool for the specific problem.

Coming Soon...

In upcoming posts:

  • What JAMstack is and how it relates to SSG.
  • How a Headless CMS works internally.
  • Why Astro is one of the best frameworks for SSG.
  • How to build a full content publishing workflow without touching code.