SSR vs SSG: when to generate a page on the server or at build time

Published on 2026-10-20 by frfrand

Qué son SSR y SSG, diferencias en rendimiento, SEO, personalización, caché y cuándo elegir cada estrategia.

SSR means server-side rendering and SSG means static site generation. Both strategies can deliver HTML to the browser, but they differ in when that HTML is prepared and how it is updated.

If you are creating a website with Next.js or another modern framework, this choice affects speed, server costs, dynamic content, and maintenance.

The difference with a restaurant menu

Think of printing the restaurant menu every time a customer sits down, with the dishes available at that moment. That is similar to SSR: the server prepares the response when a request arrives.

Now imagine printing one hundred menus at the beginning of the day and handing them out when someone asks for one. That is similar to SSG: the HTML is generated beforehand, during the site build or publication.

The second option can be very fast, but you have to decide when to regenerate the menus if prices change.

What happens with SSR?

The browser requests a page; the server gets the data it needs and generates HTML for that request. It can include updated or personalized information, depending on the architecture.

But each request can involve additional work. A slow database query can delay the response. You can also add caching where it is safe, without delivering private information to another person.

SSR does not mean that all JavaScript disappears: a page may need client-side code for interactivity.

And with SSG?

The system builds the HTML before visitors arrive. It is especially useful for documentation, informational pages, articles, or catalogs where content changes in a controlled manner.

That HTML can be served from files or a CDN with little server logic per visit. If the content changes, it may be necessary to rebuild or invalidate a stored version.

Not all platforms generate static pages exactly the same way; some allow incremental regeneration strategies.

Which one ranks better on Google?

There is no rule saying "SSR wins" or "SSG wins". Both can deliver correctly indexable HTML. What matters is the actual content, links, metadata, accessibility, stability, and perceived performance.

If a page has excellent content and a clear structure, the rendering strategy is an implementation decision, not a ranking guarantee.

It is also advisable to avoid generating hundreds of empty or duplicate URLs just to increase the number of indexable pages.

An example with a tours website

The description of a tour of Copenhagen could be generated statically. Photos, itinerary, and frequently asked questions change little.

But the availability of slots for tomorrow depends on recent reservations. That part can query a backend or use a well-designed dynamic strategy.

A real application can combine strategies instead of choosing just one for the entire domain.

Is SSR the same as SPA?

No. SPA describes an application navigation and interaction pattern; SSR and SSG describe how HTML is obtained or generated. Many frameworks combine server-side rendering, static content, and browser interactivity.

A site can deliver HTML from the server and then hydrate interactive components. Knowing these concepts avoids discussions where each person compares things from different categories.

Mistakes worth avoiding

Creating private content as public static HTML. A customized page requires appropriate caching and access policies.

Querying dynamic data unnecessarily on every visit. If an article changes once a month, recalculating everything can waste resources.

Measuring only the first load. Subsequent navigation and real-user metrics matter.

Where does ArduMaker fit in?

In an ArduMaker Git deployment you can host a statically generated frontend or run the server of an SSR application, according to its requirements. The hosting platform does not replace the decision of how to render each route.

In one sentence: SSR prepares HTML when handling the request; SSG prepares it in advance. The choice depends on changes, personalization, and generation cost.

Sources: Web rendering on web.dev · Rendering in Next.js.