SSR vs SSG
Las dos entregan HTML completo al navegador, que es lo que importa para SEO y para la primera pintura. La diferencia está en cuándo se genera ese HTML — y esa decisión determina el coste y la frescura.
El HTML se genera en el servidor en cada petición
El HTML se genera una vez al compilar
Con SSG el HTML se construye al compilar y se sirve como un fichero: no hay servidor pensando, solo un CDN entregando bytes. Con SSR se construye en cada petición, lo que permite contenido personalizado o siempre actualizado a cambio de tiempo de servidor en cada visita. Casi todo lo que parece necesitar SSR es en realidad estático con un poco de JavaScript encima.
| Dimensión | SSR | SSG |
|---|---|---|
| Cuándo se genera el HTML | En cada petición | Una vez, al compilar |
| TTFB | Depende del servidor | Mínimo: es un fichero en un CDN |
| Frescura del contenido | Siempre al día | La del último despliegue |
| Contenido personalizado | Sí | No, salvo desde el cliente |
| Coste de infraestructura | Servidor siempre encendido | Alojamiento estático, casi gratis |
| Aguante ante un pico de tráfico | Limitado por el servidor | Prácticamente ilimitado |
| Superficie de ataque | Mayor: hay código ejecutándose | Mínima: no hay servidor que atacar |
Cuando cada visitante ve algo distinto —un panel, un carrito, precios negociados— o cuando el dato cambia por minutos y no puede esperar a un despliegue.
Para contenido igual para todos: web corporativa, blog, documentación, diccionario. Es más rápido, más barato, más seguro y más difícil de tirar.
Montar SSR «por si acaso» en un sitio que no personaliza nada. Se paga un servidor, se asume mantenimiento y se pierde la resistencia a picos de un CDN, todo para regenerar en cada visita un HTML que es idéntico para todo el mundo. La regla útil: si dos visitantes distintos ven exactamente lo mismo, no hace falta SSR.