SSR, SSG, ISR y CSR: dónde ocurre el trabajo
Las cuatro estrategias de render definidas por cuándo se genera el HTML y quién lo genera, qué se puede cachear en cada una, y las combinaciones que existen de verdad.
Las siglas se usan como si fueran bandos, y son otra cosa: respuestas a dos preguntas independientes. Cuándo se produce el HTML —en el build, en cada petición, o en el navegador— y quién se encarga de la interacción después. Separar esas dos preguntas convierte una discusión de tribus en una decisión por ruta, que es como se toma bien. Esta lección define las cuatro estrategias con precisión y establece qué se puede cachear en cada una, que es donde se decide casi todo el rendimiento.
- Definir SSR, SSG, ISR y CSR por el momento y el lugar en que se produce el HTML.
- Determinar qué parte de la respuesta es cacheable en cada estrategia y dónde.
- Reconocer que las dos preguntas —generación del HTML e interactividad— son independientes.
- Elegir estrategia por ruta y no por aplicación.
Las dos preguntas independientes
Pregunta uno: ¿cuándo existe el HTML con el contenido dentro? En el momento de compilar, en el momento de la petición, o nunca en el servidor porque lo construye el navegador.
Pregunta dos: ¿quién gestiona la interacción después de que la página se vea? El servidor, con navegaciones completas; o el cliente, con JavaScript que intercepta y actualiza.
Las siglas mezclan las dos respuestas y por eso confunden. Una web puede ser estática y a la vez muy interactiva. Una puede renderizarse en el servidor en cada petición y no tener nada de JavaScript. Puedes generar HTML en el build y navegar como una aplicación de una sola página. Las combinaciones son casi todas viables, y la decisión de rendimiento correcta se toma respondiendo a las dos preguntas por separado y por ruta.
Las cuatro estrategias
SSG, generación estática. El HTML se produce al compilar. Cada ruta es un fichero. La petición del usuario la sirve un servidor de ficheros o, mejor, un nodo de una red de distribución. El servidor no ejecuta nada: entrega bytes.
El tiempo hasta el primer byte es el mínimo físicamente posible, porque solo hay red. La página se puede cachear entera y para siempre. El coste está en el build: si tienes cien mil rutas, el build tarda, y cualquier cambio en el contenido exige recompilar y volver a desplegar.
Sirve para todo lo que no depende del usuario ni cambia por minuto: documentación, blogs, páginas de producto, landings, catálogos.
SSR, renderizado en el servidor por petición. El HTML se produce cuando llega la petición. El servidor consulta lo que haga falta, monta la página y la envía completa.
El primer byte tarda lo que tarde el servidor: consultas, plantillas, serialización. Es la estrategia que introduce el riesgo de rendimiento más grande, porque un problema en la base de datos se convierte directamente en un problema de LCP para el usuario. A cambio, el contenido siempre está al día y puede ser distinto para cada persona.
Sirve para lo personalizado y para lo que cambia constantemente: paneles, carritos, resultados de búsqueda, cualquier vista que muestre datos del usuario.
ISR, regeneración incremental. Es SSG con caducidad. Las páginas se generan y se guardan, se sirven desde caché, y pasado un tiempo la siguiente petición dispara una regeneración en segundo plano mientras se sigue sirviendo la versión guardada. Es exactamente la semántica de stale-while-revalidate aplicada a la generación de páginas.
Da el tiempo de respuesta del estático con una frescura acotada. El precio es que alguien va a ver contenido viejo, y hay que decidir cuánto es aceptable. Sirve para contenido que cambia pero no en tiempo real: catálogos con precios, listados, artículos que se editan.
CSR, renderizado en el cliente. El servidor envía un HTML mínimo —a menudo un div vacío— y un paquete de JavaScript. El navegador descarga, analiza, compila, ejecuta, pide los datos y construye el DOM.
El primer byte es rapidísimo y no significa nada, porque no hay contenido. Todo lo que el usuario percibe llega después de la cadena entera: red, análisis, ejecución, otra ida y vuelta a la API, y por fin pintado. En un móvil de gama media con red móvil real, esa cadena es de varios segundos con facilidad.
Sirve para aplicaciones detrás de un login donde la primera carga es una vez al día y lo que importa es la fluidez posterior. Y para poco más.
Qué se puede cachear en cada una
Esta tabla es la que decide, porque el rendimiento de una web es en gran medida una función de qué fracción de las peticiones se resuelve sin tocar el origen.
| Dónde se genera | HTML cacheable en CDN | Datos cacheables | Coste por petición | |
|---|---|---|---|---|
| SSG | Build | Sí, indefinidamente | Ya están dentro | Cero cómputo |
| ISR | Build y bajo demanda | Sí, con caducidad | Ya están dentro | Amortizado |
| SSR | Cada petición | Solo si no es personalizado | Sí, por separado | Cómputo y consultas |
| CSR | Navegador | El caparazón, sí | Sí, en API | Cómputo en el cliente |
Tres consecuencias que conviene extraer de la tabla.
El HTML personalizado no se cachea en el borde. En cuanto la respuesta depende de una cookie de sesión, la clave de caché tiene que incluir esa cookie, y con una clave por usuario no hay caché. La salida no es renunciar: es separar lo personalizado de lo que no lo es, servir el marco desde caché y traer la parte personal aparte. Cómo se hace exactamente, y con qué claves, es el contenido del nivel del edge.
El coste del build es real y limita. SSG con cien mil rutas significa builds de decenas de minutos y despliegues lentos, lo cual afecta a la velocidad del equipo y acaba afectando al producto. ISR existe precisamente para eso: generar bajo demanda solo las rutas que alguien pide.
CSR no elimina el trabajo, lo mueve al dispositivo más lento de la cadena. Renderizar en un servidor con núcleos rápidos cuesta milisegundos; renderizar lo mismo en un móvil de ciento cincuenta euros cuesta un orden de magnitud más. Ese desplazamiento es el hecho central de todo este nivel.
Las combinaciones que existen de verdad
En producción casi nadie usa una sola estrategia, y las mezclas tienen nombre.
Estático con islas interactivas. El HTML se genera al compilar y solo unos componentes concretos reciben JavaScript. Es lo que hace Astro, y es la combinación con mejor relación entre coste y resultado para sitios orientados a contenido. La arquitectura tiene su propia lección en islas.
Caparazón estático con huecos dinámicos. La parte de la página que no depende del usuario se genera y se cachea; los huecos personalizados se rellenan por streaming en la misma respuesta o se piden aparte. Es la idea detrás del prerenderizado parcial y de las islas de servidor, y resuelve el problema de “el noventa por ciento de mi página es cacheable y el diez por ciento no”.
SSR para la primera carga, CSR para las siguientes. El patrón dominante en los frameworks de aplicación: la primera visita llega renderizada y a partir de ahí la navegación la gestiona el cliente. Es el que introduce el coste de la hidratación, que es el asunto de el impuesto de la hidratación.
Estático por defecto con excepciones declaradas. Todas las rutas estáticas salvo las que declaran que necesitan datos por petición. Es la política por defecto correcta para la mayoría de los productos, porque hace que lo caro sea la excepción visible y no la norma invisible.
La discusión sobre estrategias de render está viciada porque se plantea al nivel equivocado. “¿Somos SSR o SSG?” es una pregunta sobre la aplicación, y la aplicación es una colección de rutas con requisitos completamente distintos. La portada, la página de precios y la documentación no cambian entre despliegues y las ve todo el mundo igual: son estáticas, y renderizarlas en cada petición es quemar cómputo y tiempo de respuesta a cambio de nada. La lista de productos cambia cada hora y la ven todos igual: es regeneración incremental. El panel de control muestra datos de una persona concreta: es servidor por petición o es cliente. El editor de documentos es una aplicación de verdad, donde la primera carga es irrelevante y lo que importa es la latencia de cada pulsación: puede ser cliente sin remordimiento. Son cuatro respuestas distintas dentro del mismo producto, y cualquier framework moderno permite las cuatro a la vez. Hay una consecuencia que va más allá de lo técnico. Cuando un equipo elige una estrategia para toda la aplicación, lo que suele estar optimizando no es el rendimiento sino la homogeneidad: una sola forma de hacer las cosas, una sola cadena de despliegue, una sola cosa que aprender. Es un objetivo legítimo y tiene valor real, sobre todo en equipos grandes. Pero conviene llamarlo por su nombre y contabilizar su precio, porque ese precio lo paga el usuario en las rutas donde la estrategia elegida no encajaba: la portada que tarda ochocientos milisegundos en responder porque el servidor la monta cada vez, o el panel que tarda cuatro segundos en mostrar un número porque todo se decidió renderizar en el cliente. La pregunta útil en una revisión de arquitectura no es “¿qué estrategia usamos?” sino “enséñame la lista de rutas con su estrategia y su justificación”. Si la lista tiene una sola fila, tienes una decisión de proceso disfrazada de decisión técnica.
- Haz la lista de las diez rutas más visitadas de tu producto y anota, para cada una, si su contenido depende del usuario y cada cuánto cambia.
- Asigna a cada una la estrategia que le corresponde según esas dos respuestas. Compara con la que tiene hoy.
- Para las rutas personalizadas, identifica qué fracción del HTML es realmente personal. Suele ser mucho menor de lo que parece.
- Mide el tiempo hasta el primer byte de una ruta estática y de una renderizada por petición en tu producción. Anota la diferencia.
- Estima el tiempo de build si convirtieras todas las rutas candidatas a generación estática. Decide si hace falta regeneración incremental.