SSR, SSG, ISR y renderizado en cliente: qué significa cada uno y cuándo usarlo

Cuando explicamos esto en una reunión, solemos recurrir a una panadería. Puedes hornear todo el pan antes de abrir y tenerlo en el mostrador: lo entregas al instante, pero si a media mañana cambias la receta, el pan de la vitrina sigue siendo el de antes. Puedes hornear cada barra cuando llega el cliente: siempre sale recién hecha, pero cada persona espera un rato y el horno no para. O puedes darle al cliente la masa y las instrucciones para que la hornee en su casa. Las tres funcionan; la pregunta es cuál conviene para cada producto.

Una web hace exactamente lo mismo con sus páginas. Alguien tiene que convertir los datos (textos, precios, fotos) y las plantillas en el HTML que ve el navegador. Eso se llama renderizar, y la gran decisión es dónde y cuándo ocurre: al publicar, en cada visita en el servidor o en el propio navegador del visitante.

De ahí salen las siglas que aparecen en cualquier conversación técnica: CSR, SSR, SSG e ISR. En esta guía las explicamos con la misma escena, para que veas qué cambia en cada una y puedas decidir con criterio, o al menos entender lo que te propone tu equipo.

01La misma visita, cuatro formas de servirla

Antes de cada definición, conviene fijar el recorrido básico. Alguien pide una página; el servidor responde; el navegador la pinta y la hace interactiva. Si quieres repasar las piezas de ese recorrido (DNS, servidor, navegador), las tienes en cómo funciona una web. Lo que cambia entre los tipos de renderizado es en qué punto se construye el HTML con el contenido real:

CSR  (cliente)    petición → HTML casi vacío + JS → el navegador descarga datos → pinta el contenido
SSR  (servidor)   petición → el servidor consulta datos y monta el HTML → llega completo → hidratación
SSG  (estático)   al publicar: se generan todas las páginas → petición → archivo ya hecho desde la CDN
ISR  (incremental) como SSG, pero cada página se regenera en segundo plano cuando caduca o cambia el contenido

Vamos una por una.

02Renderizado en cliente (CSR): la página se construye en el navegador

En el renderizado en cliente (Client-Side Rendering), el servidor envía un HTML mínimo, casi un esqueleto con un contenedor vacío, y un paquete de JavaScript. Ese JavaScript se descarga, se ejecuta, pide los datos a una API y, por fin, pinta el contenido.

Fue el modelo dominante de las aplicaciones de una sola página (SPA) hechas con React, Angular o Vue durante la década pasada, y sigue siendo perfecto para ciertas cosas.

Dónde brilla: paneles de gestión, áreas privadas de cliente, herramientas internas, configuradores y cualquier interfaz detrás de un inicio de sesión. Ahí el SEO no importa, la persona va a pasar un buen rato dentro y, una vez cargada, la aplicación responde con mucha agilidad.

Lo que pide a cambio: la primera carga es más lenta, sobre todo en móviles modestos, porque hasta que el JavaScript no termina no hay contenido. El LCP, el momento en que aparece el elemento principal, se retrasa. Y los buscadores tienen que ejecutar ese JavaScript para ver el contenido: Google lo hace en una segunda fase de renderizado; otros buscadores y muchos rastreadores de IA lo hacen peor o no lo hacen.

03Renderizado en servidor (SSR): la página se monta en cada visita

Con el renderizado en servidor (Server-Side Rendering), cada vez que alguien pide una página, el servidor consulta los datos, monta el HTML completo y lo envía. El navegador recibe una página con todo su contenido, que puede mostrar de inmediato.

Después llega un paso que conviene entender: la hidratación. El navegador descarga el JavaScript de los componentes interactivos y lo «conecta» al HTML que ya está en pantalla, para que los botones, menús y formularios funcionen. Durante ese intervalo la página se ve pero sus partes interactivas aún no responden. Por eso un SSR con mucho JavaScript puede verse rápido y, sin embargo, tardar en reaccionar al primer toque; lo contamos con detalle en JavaScript y rendimiento.

Dónde brilla: páginas cuyo contenido depende de cada visita o cambia a cada minuto: resultados de búsqueda con filtros, disponibilidad en tiempo real, precios personalizados, contenido según el usuario que ha iniciado sesión.

Lo que pide a cambio: el servidor trabaja en cada petición, así que el tiempo de respuesta depende de lo rápidas que sean sus consultas y de dónde esté ubicado. Y el coste de alojamiento crece con el tráfico.

El streaming, una mejora del SSR

Los frameworks actuales permiten que el servidor envíe la página por partes: primero la cabecera y el contenido principal, después los bloques más lentos (unas recomendaciones, unas reseñas) en cuanto estén listos. La persona empieza a leer antes y el tiempo de espera se reparte.

04Generación estática (SSG): las páginas se hornean al publicar

Con la generación estática (Static Site Generation), todas las páginas se construyen una vez, en el momento de publicar la web. El resultado son archivos HTML ya hechos que se suben a un servidor o, mejor, a una CDN repartida por el mundo. Cuando alguien pide una página, no hay nada que calcular: se entrega el archivo.

Dónde brilla: prácticamente cualquier página que sea igual para todos los visitantes y cambie poco: portada, servicios, quiénes somos, proyectos, artículos, guías, páginas legales. Es la opción más rápida, la más barata de alojar y la más fácil de proteger, porque no hay base de datos ni lógica expuesta en cada visita.

Lo que pide a cambio: cualquier cambio de contenido requiere volver a generar y publicar. Con veinte páginas es cuestión de segundos; con cincuenta mil fichas de producto, la publicación puede alargarse bastante.

05Regeneración incremental (ISR): lo estático que se refresca solo

La regeneración estática incremental (Incremental Static Regeneration) nació en Next.js para resolver justo esa limitación. Las páginas se sirven como estáticas, pero cada una puede regenerarse en segundo plano sin publicar la web entera, de dos maneras:

1. 01Por tiempo. Se indica que una página es válida, por ejemplo, durante una hora. El primer visitante que llega después recibe la versión guardada al instante, y eso dispara en segundo plano la generación de una nueva para los siguientes.
2. 02Bajo demanda. Cuando alguien cambia un contenido en el gestor, este avisa a la web y se regenera solo la página afectada. Es lo más habitual cuando la web está conectada a un CMS headless.

Dónde brilla: blogs y revistas, catálogos y fichas de producto, cartas de restaurante, listados de inmuebles, eventos. Contenido igual para todos que cambia con cierta frecuencia.

Lo que pide a cambio: un alojamiento que lo soporte (no sirve un hosting puramente estático) y entender que, en la revalidación por tiempo, alguien puede ver la versión anterior durante unos segundos.

06Comparativa rápida para decidir

07Cómo elegir para cada página de tu web

La idea más útil de esta guía es que la decisión se toma por página o por tipo de página, no para toda la web. Frameworks como Next.js, Nuxt, Astro o SvelteKit permiten mezclar modos en el mismo proyecto. Lo explicamos aplicado a un caso de negocio en Next.js explicado para negocios.

Estas preguntas, en este orden, resuelven casi todos los casos:

1. 01¿El contenido es igual para todos los visitantes? Si depende de quién lo mira (su cuenta, su carrito, sus permisos), esa parte va en servidor o en cliente.
2. 02¿Tiene que aparecer en buscadores? Si sí, necesita HTML completo en la primera respuesta: estático, incremental o servidor.
3. 03¿Cada cuánto cambia? Casi nunca: estático. Varias veces al día o cuando alguien lo edita: incremental. A cada minuto o en cada petición: servidor.
4. 04¿Cuántas páginas hay de ese tipo? Con miles de fichas, el incremental evita publicaciones eternas.
5. 05¿Qué parte es interactiva? Solo esa parte necesita JavaScript en el navegador. El resto puede llegar como HTML puro.

Lo que funciona al combinarlos

• →Empezar por lo estático y subir de nivel solo cuando una página lo justifique: es más fácil añadir dinamismo que quitarlo.
• →Aislar lo que cambia a cada momento (precio, stock, disponibilidad) en un bloque pequeño, en lugar de convertir toda la página en dinámica por un solo dato.
• →Medir el tiempo de respuesta del servidor (TTFB) en las páginas SSR; si pasa de unos 800 ms, que es la referencia que da web.dev para un TTFB bueno, conviene añadir caché o revisar las consultas.
• →Configurar la revalidación bajo demanda desde el gestor de contenidos, para que tu equipo vea sus cambios publicados en segundos.
• →Documentar en el proyecto qué modo usa cada tipo de página y por qué, para que cualquier persona que llegue después lo entienda.

08Tendencias que difuminan las fronteras

Las fronteras entre estos modos son cada vez más finas. Tres ideas que verás mencionadas:

• →Islas de interactividad. Popularizadas por Astro: la página es HTML estático y solo ciertos componentes (un carrusel, un formulario) se hidratan, cada uno por su cuenta. Muy poco JavaScript para webs de contenido.
• →Server Components. En React y Next.js, los componentes que no necesitan interactividad se ejecutan solo en el servidor y no envían su código al navegador. Se reduce mucho lo que hay que hidratar.
• →Prerenderizado parcial. Una misma página combina un esqueleto estático que llega al instante con huecos dinámicos que se rellenan en streaming. Es la versión más fina de la mezcla por página: mezcla dentro de la página.

Todas persiguen lo mismo: entregar HTML lo antes posible y enviar al navegador solo el JavaScript imprescindible.

Clave: la pregunta no es qué tipo de renderizado es mejor, sino qué necesita cada página para llegar rápido, completa y al día.

09Una decisión de arquitectura que se nota en la experiencia

Elegir bien el renderizado no es un detalle de programadores. Se nota en lo rápido que aparece tu web en un móvil, en lo fiable que es su posicionamiento, en lo que cuesta alojarla cada mes y en lo cómodo que es para tu equipo actualizar contenidos. Por eso en SIMA lo decidimos al principio del proyecto, con el mapa de páginas delante, junto con la estructura y el diseño.

Si estás planteando una web nueva o notas que la tuya va lenta y quieres saber si el problema está en cómo se construyen las páginas, en nuestro servicio de desarrollo web y apps lo analizamos contigo. Escríbenos y lo vemos.