SSR, SSG y sitio estático: diferencias al hospedar

Toda página web tiene que convertirse en HTML en algún momento. La diferencia entre SSR, SSG y sitio estático está en cuándo ocurre: en cada visita, una vez durante el build o dentro del navegador. Esa elección define qué tipo de hosting necesitas, cuánta RAM pagas y qué puedes poner en caché.

Los términos se mezclan porque SSG y "sitio estático" describen el mismo resultado visto desde ángulos distintos. Las secciones de abajo los separan, con una tabla y ejemplos.

¿Qué es un sitio estático?#

Es un conjunto de archivos HTML, CSS y JavaScript listos, entregados tal como están. MDN lo resume así: los sitios estáticos no tienen lógica en el servidor, así que todos los usuarios reciben el mismo contenido para una URL. El servidor solo lee el archivo y lo envía.

No hay código tuyo en ejecución en el hosting. Eso hace que el sitio sea barato, fácil de poner detrás de una CDN y difícil de tumbar por exceso de visitas. Para el paso a paso de publicar uno, mira qué es un sitio estático.

¿Qué es SSG (static site generation)?#

SSG es el proceso que produce el sitio estático: un comando de build ejecuta tu código una vez, busca los datos necesarios y escribe un HTML por ruta. Después publicas la carpeta generada.

En Next.js, el App Router renderiza los Server Components durante next build, como un generador de sitios tradicional. Esta configuración hace que el framework exporte todo como archivos:

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

module.exports = nextConfig

Después de next build, la carpeta out contiene los HTML, CSS y JS. Las rutas dinámicas como /blog/[id] solo funcionan en este modo si tienen generateStaticParams(), que indica qué páginas generar en el build.

El costo de SSG: el contenido solo cambia cuando haces un build nuevo. En un sitio con miles de páginas el build tarda más, y un precio actualizado solo aparece en el próximo deploy.

¿Qué es SSR (server-side rendering)?#

Con SSR el servidor arma el HTML en cada petición. Puede leer la cookie de sesión, consultar la base de datos y devolver una página distinta para cada visitante. Por eso necesita un proceso en ejecución todo el tiempo.

En Next.js, leer un dato que solo existe en la petición, como una cookie, vuelve dinámico ese fragmento:

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

async function Saludo() {
  const tema = (await cookies()).get('tema')?.value ?? 'claro'
  return <p>Tu tema: {tema}</p>
}

export default function Page() {
  return (
    <>
      <h1>Perfil</h1>
      <Suspense fallback={<p>Cargando...</p>}>
        <Saludo />
      </Suspense>
    </>
  )
}

Según la documentación de Next.js, con Cache Components activado (cacheComponents: true en next.config) el título (estático) y el fallback entran en un "static shell" generado en el build, y solo el fragmento que lee cookies se renderiza en la petición. Lo estático y lo dinámico conviven en la misma ruta.

El costo de SSR: cada visita consume CPU y RAM de un proceso siempre encendido (compáralo con serverless y contenedores), el tiempo de respuesta depende del código y de los datos, y una página lenta de armar deja al visitante esperando.

¿Y dónde entra el CSR?#

Con CSR (client-side rendering) el servidor envía un HTML casi vacío y el JavaScript arma la pantalla en el navegador. Una SPA en React puro funciona así. En el hosting se comporta como un sitio estático, porque lo que publicas son archivos listos. La diferencia aparece para los buscadores y para quien tiene internet lenta: el contenido solo existe después de que corre el JavaScript.

¿Cuál es la diferencia al hospedar?#

Dos consecuencias prácticas. Primero, el sitio estático acepta casi cualquier hosting: la documentación de Next.js dice que el resultado lo puede servir cualquier servidor web capaz de entregar HTML, CSS y JS. Segundo, al usar output: 'export' renuncias a funciones que dependen de un servidor Node.js: Server Actions, cookies, redirects, rewrites y headers de next.config, ISR y la optimización de imágenes por defecto, entre otras.

¿Cómo elegir el modelo de cada página?#

Pregunta, página por página, si el contenido cambia por visitante o por minuto:

• Blog, documentación, landing page, portafolio: SSG. El contenido cambia cuando publicas. Es el caso más barato y más rápido.
• Panel, perfil, carrito, página que depende de iniciar sesión: SSR, o una SPA que habla con una API. El contenido es distinto para cada persona.
• Catálogo con precios que cambian varias veces al día: SSG con regeneración (ISR) o SSR con caché. Puedes mantener páginas estáticas y actualizarlas a intervalos, pero eso exige un servidor Node.js y no funciona con output: 'export'.
• App con mucho JavaScript y poco SEO: una SPA estática suele bastar.

Una regla útil: empieza estático y agrega servidor solo donde un requisito lo pida. El punto medio más común es mantener el front-end estático y mover la parte dinámica a una API separada.

¿Cómo saber si mi sitio ya es estático?#

Ejecuta el build y mira el resultado. Si genera una carpeta solo con .html, .css y .js (como out, dist o build), puedes publicarla en cualquier servidor de archivos. Si el framework exige un comando como next start para arrancar (mira cómo hospedar una app Next.js), hay un proceso Node.js que tiene que quedar encendido, y el hosting tiene que ofrecerlo.

Cómo hacerlo en Square Cloud#

En Square Cloud, cada modelo tiene su camino. Para la parte estática, entre diversos runtimes hay uno de sitios estáticos: nginx está siempre en línea sirviendo la carpeta, y cada actualización queda en línea al instante. Envías la carpeta generada (out, dist) desde el panel en un ZIP, con la CLI, desde GitHub o con la extensión de VS Code. El archivo de configuración squarecloud.app es opcional: el panel lo genera en el deploy, o lo escribes en la raíz del proyecto.

Para SSR, usa el runtime de Node.js y ejecuta el servidor del framework, como next start. La plataforma no tiene etapa de build, así que ejecuta next build en un CI externo o en el comando de inicio. En el comando de inicio, las dependencias del build (como typescript) tienen que estar en dependencies, porque la instalación corre con NODE_ENV=production y omite las devDependencies.

Las aplicaciones corren en contenedores siempre encendidos, sin cold start ni modo de suspensión, con reinicio automático (activado por defecto en el deploy desde el panel) cuando el proceso termina con error. Una aplicación web necesita al menos 512 MB de la RAM de tu plan, que es un pool compartido entre tus aplicaciones. No hay autoscaling: tú ajustas la RAM de cada aplicación en la configuración.

Toda aplicación web recibe un subdominio *.squareweb.app con HTTPS, en cualquier plan. El dominio personalizado está disponible desde el plan Standard: creas los registros DNS en tu registrador, y el TLS es automático. El Hobby, desde R$12,49 al mes, sirve para sitios, y todos los planes incluyen CDN global y analytics web sin cookies. Los detalles están en la página de Sites.