Renderizado en el servidor (SSR): definición, pros y cuándo usarlo

¿Qué es el renderizado en el servidor (SSR)?

En el renderizado en el servidor (SSR, Server-Side Rendering), el servidor construye el HTML de la página cuando llega una petición y se lo envía al navegador listo para mostrar. El navegador puede pintar el contenido de inmediato; después se carga JavaScript y la página se vuelve interactiva. En el renderizado en el cliente (CSR), en cambio, el servidor envía una estructura casi vacía y el navegador construye la página con JavaScript.

Frameworks como Next.js, Nuxt, SvelteKit y Remix admiten SSR, y la mayoría permite elegir el modo de renderizado por ruta. El SSR encaja con páginas cuyo contenido depende de la petición: resultados de búsqueda, vistas de usuarios con sesión, inventario en vivo y páginas que deben poder indexarse.

Cómo funciona el SSR

1. El navegador solicita /products/42.
2. El servidor obtiene los datos, ejecuta el árbol de componentes y genera el HTML.
3. El servidor envía el HTML y el navegador lo muestra enseguida.
4. El navegador descarga el paquete de JavaScript.
5. El script hidrata la página: asocia los manejadores de eventos al HTML existente y la página pasa a ser interactiva.

Entre los pasos 3 y 5 la página es visible, pero puede que aún no responda a los clics.

SSR frente a otras estrategias de renderizado

El SSR también puede ejecutarse en el edge, cerca del usuario, lo que reduce la latencia de red pero limita el código que se puede ejecutar allí.

Un ejemplo mínimo

Sin ningún framework, el SSR es una función que devuelve una cadena de HTML. Esta ruta de Express renderiza un componente de React en el servidor:

import { renderToString } from 'react-dom/server';
import App from './App';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<!DOCTYPE html>
<html>
  <body>
    <div id="root">${html}</div>
    <script src="/client.js"></script>
  </body>
</html>`);
});

Después, el navegador carga client.js, que llama a hydrateRoot para engancharse al marcado. Los frameworks automatizan esta conexión, además del enrutado, la carga de datos y la división de código.

Cuándo encaja el SSR

• Páginas personalizadas. El HTML depende de quién lo pide.
• Datos que cambian a menudo. Precios, existencias, noticias.
• Páginas indexables con datos dinámicos. Fichas de producto y búsquedas que los rastreadores deben leer como HTML.
• Contenido por región. Moneda, idioma o textos legales según la petición.

Cuándo conviene otro enfoque

• Páginas de marketing y documentación. El SSG servido desde una CDN es más rápido y barato.
• Paneles con sesión sin necesidad de SEO. El CSR es más sencillo de alojar.
• Sitios mixtos. Páginas de aterrizaje estáticas, SSR para el catálogo y CSR para la aplicación.

El coste de la hidratación

La hidratación es el precio del SSR. El navegador descarga y vuelve a ejecutar los mismos componentes para asociar el comportamiento. Según la guía de web.dev sobre renderizado en la web, puede empeorar el Total Blocking Time y el Interaction to Next Paint aunque mejore el First Contentful Paint, de modo que la página parece lista antes de responder. El SSR con streaming (enviar el HTML por partes), los React Server Components y las arquitecturas de islas, como las de Astro, intentan reducir el JavaScript que hay que ejecutar.

Errores habituales con SSR

• Usar APIs del navegador en el servidor. window is not defined es el fallo clásico.
• Salida distinta en servidor y cliente. Una marca de tiempo o un ID aleatorio hace que la hidratación avise o falle.
• Obtener datos lentos durante el renderizado. El navegador no recibe nada hasta que termina la consulta más lenta.
• No usar caché. Cada petición recalcula la página. Cachee lo que no sea personal y marque las páginas personales con Cache-Control: private.
• Fugas de memoria. Un servidor de renderizado funciona durante días y una pequeña fuga por petición se acumula.
• Trabajo pesado en el middleware de autenticación. Retrasa todas las respuestas.

SSR y pruebas de rendimiento

El SSR traslada el trabajo de renderizado del dispositivo de cada visitante a su servidor, así que su capacidad pasa a determinar la velocidad de la página. El Time to First Byte es la cifra que vigilar: web.dev considera bueno un valor de 0,8 segundos o menos y malo uno superior a 1,8 segundos, y señala que una página renderizada en el servidor puede tener un TTFB más alto pero mejor First Contentful Paint y Largest Contentful Paint que una renderizada en el cliente.

Una sola petición dice poco. Haga una prueba de carga sobre sus rutas SSR principales con tráfico realista y observe cómo cambian el TTFB y la tasa de errores al subir los usuarios simultáneos. Después, siga los Core Web Vitals en el tiempo con la monitorización de velocidad de página. Sobre las aplicaciones de una sola página, consulte cómo hacer pruebas de carga a aplicaciones de una sola página, y para evitar regresiones, presupuestos de rendimiento para aplicaciones web.

Preguntas frecuentes: renderizado en el servidor

¿Es mejor el SSR que el SSG?

Ninguno es mejor en general. El SSG encaja con contenido que cambia poco, porque el HTML se genera una vez y se sirve desde una CDN. El SSR encaja con contenido que cambia por petición o por usuario. Muchos sitios usan ambos.

¿El SSR resuelve el SEO automáticamente?

Garantiza que los rastreadores reciban el HTML completo, pero siguen haciendo falta buenos títulos, metaetiquetas, datos estructurados, enlaces internos y unos Core Web Vitals aceptables.

¿Es el SSR más lento que el CSR?

Depende de la métrica. El servidor necesita tiempo para construir la página, por lo que el TTFB suele ser mayor. El primer pintado suele llegar antes porque el HTML llega listo para mostrar. La interactividad depende de cuánto JavaScript haya que hidratar.

¿Puedo combinar SSR y CSR en una misma aplicación?

Sí. Next.js, Nuxt y SvelteKit permiten elegir el modo de renderizado por ruta: las páginas públicas usan SSR y un panel con sesión puede seguir en el cliente.

¿Cómo reduzco el TTFB en un sitio con SSR?

Cachee páginas y datos que no sean personales, acelere o paralelice las consultas del renderizado, envíe la respuesta en streaming y valore renderizar en el edge. Vuelva a medir bajo carga tras cada cambio.

¿SSR es lo mismo que React Server Components?

No. El SSR genera HTML en el servidor en la primera carga y el código completo de los componentes se sigue enviando al navegador para hidratarlo. Los Server Components se ejecutan solo en el servidor y no envían código de componente para su parte del árbol. Suelen combinarse.