SSR vs SSG vs static: what changes when you host

Every web page has to become HTML at some point. What separates SSR, SSG and static sites is when that happens: on every visit, once during the build, or inside the browser. That choice decides what kind of hosting you need, how much RAM you pay for and what you can cache.

The terms blur because SSG and "static site" describe the same result from different angles. The sections below pull them apart, with a table and examples.

What is a static site?#

It is a set of ready-made HTML, CSS and JavaScript files, delivered exactly as they are. MDN puts it this way: static sites have no server-side logic, so every user gets the same content for a given URL. The server just reads the file and sends it.

None of your code runs on the host. That makes the site cheap, easy to put behind a CDN and hard to take down with traffic spikes. For a step-by-step on publishing one, see what is a static site.

What is SSG (static site generation)?#

SSG is the process that produces the static site: a build command runs your code once, fetches the data it needs and writes one HTML file per route. Then you publish the generated folder.

In Next.js, the App Router renders Server Components during next build, like a traditional static site generator. This config makes the framework export everything as files:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
}

module.exports = nextConfig

After next build, the out folder holds the HTML, CSS and JS. Dynamic routes such as /blog/[id] only work in this mode if they define generateStaticParams(), which lists the pages to generate at build time.

The cost of SSG: content only changes when you build again. A site with thousands of pages takes longer to build, and an updated price only shows up on the next deploy.

What is SSR (server-side rendering)?#

With SSR the server builds the HTML on every request. It can read the session cookie, query the database and return a different page for each visitor. That is why it needs a process running all the time.

In Next.js, reading data that only exists at request time, such as a cookie, makes that part dynamic:

// app/profile/page.tsx
import { cookies } from 'next/headers'
import { Suspense } from 'react'

async function Greeting() {
  const theme = (await cookies()).get('theme')?.value ?? 'light'
  return <p>Your theme: {theme}</p>
}

export default function Page() {
  return (
    <>
      <h1>Profile</h1>
      <Suspense fallback={<p>Loading...</p>}>
        <Greeting />
      </Suspense>
    </>
  )
}

According to the Next.js docs, with Cache Components enabled (cacheComponents: true in next.config) the heading (static) and the fallback go into a "static shell" built at build time, and only the part that reads cookies is rendered per request. Static and dynamic live side by side in one route.

The cost of SSR: every visit uses CPU and RAM on a process that is always on (compare with serverless and containers), response time depends on your code and data, and a page that is slow to build keeps the visitor waiting.

Where does CSR fit in?#

With CSR (client-side rendering) the server sends an almost empty HTML file and JavaScript builds the screen in the browser. A plain React SPA works this way. For hosting it behaves like a static site, because what you publish is ready-made files. The difference shows up for crawlers and for slow connections: the content only exists after the JavaScript runs.

What changes in hosting?#

Two practical consequences. First, a static site fits almost any host: the Next.js docs say the output can be served by any web server that can deliver HTML, CSS and JS. Second, with output: 'export' you give up features that need a Node.js server: Server Actions, cookies, redirects, rewrites and headers in next.config, ISR and the default image optimization, among others.

How do you pick a model for each page?#

Ask, page by page, whether the content changes per visitor or per minute:

• Blog, docs, landing page, portfolio: SSG. Content changes when you publish. It is the cheapest and fastest case.
• Dashboard, profile, cart, anything behind a login: SSR, or an SPA talking to an API. The content is different for each person.
• Catalog with prices that change several times a day: SSG with regeneration (ISR) or SSR with caching. You can keep pages static and refresh them at intervals, but that needs a Node.js server and does not work with output: 'export'.
• JavaScript-heavy app with little SEO need: a static SPA is usually enough.

A useful rule: start static and add a server only where a requirement asks for one. The most common middle ground is a static front end with the dynamic part moved to a separate API.

How do you know if your site is already static?#

Run the build and look at the output. If it produces a folder with only .html, .css and .js files (such as out, dist or build), you can publish it on any file server. If the framework needs a command like next start to run (see how to host a Next.js app), there is a Node.js process that has to stay up, and your host must support that.

How to do this on Square Cloud#

On Square Cloud, each model has its own path. For the static part, among several runtimes there is one for static sites: nginx is always online serving the folder, and every update goes live right away. You upload the generated folder (out, dist) from the dashboard as a ZIP, with the CLI, through GitHub or with the VS Code extension. The squarecloud.app config file is optional: the dashboard generates it at deploy, or you can write it at the project root.

For SSR, use the Node.js runtime and run the framework's server, such as next start. The platform has no build step, so run next build in an external CI or in the start command. In the start command, the build's dependencies (such as typescript) must be in dependencies, because the install runs with NODE_ENV=production and skips devDependencies.

Applications run in always-on containers, with no cold start and no sleep mode, and automatic restart (on by default for dashboard deploys) when the process exits with an error. A web application needs at least 512 MB of your plan's RAM, which is a pool shared across your applications. There is no autoscaling: you adjust each application's RAM in its settings.

Every web application gets a *.squareweb.app subdomain with HTTPS on any plan. Custom domains are available from the Standard plan: you create the DNS records at your registrar, and TLS is automatic. Hobby, from R$12.49 per month, covers sites, and every plan includes a global CDN and cookieless web analytics. The details are on the Sites page.