Definición
SSR (Server-Side Rendering) significa que el HTML se genera en el servidor en el momento de la petición y llega al navegador ya montado, con su texto y sus datos dentro.
Es la respuesta al principal problema de una SPA: allí el navegador recibe un documento vacío y tiene que ejecutar JavaScript antes de que aparezca nada. Con SSR, el visitante ve contenido en cuanto llega el HTML, y los buscadores también.
Conviene decirlo: SSR no es nuevo. Cualquier web en PHP lleva haciéndolo treinta años. Lo que es nuevo es hacerlo con los mismos componentes de JavaScript que luego se ejecutan en el cliente.
Cómo funciona
- Llega la petición al servidor.
- El servidor ejecuta el código de la página: consulta la base de datos, llama a las APIs que haga falta.
- Genera el HTML completo y lo envía.
- El navegador lo pinta. Aquí ya se ve la página.
- Se descarga el JavaScript y se ejecuta un proceso llamado hidratación: el código se "engancha" al HTML existente y le añade el comportamiento.
Entre el paso 4 y el 5 hay una ventana en la que la página se ve pero no responde del todo. Si esa ventana es larga, el visitante pulsa y no pasa nada, que es peor que no poder pulsar.
SSR frente a SSG
- SSG genera el HTML una vez, al compilar. Sirve ficheros estáticos: lo más rápido y lo más barato.
- SSR lo genera en cada petición. Más lento y más caro, y a cambio siempre actualizado y personalizable por usuario.
La pregunta que decide entre uno y otro: ¿el contenido es el mismo para todo el mundo? Si lo es, SSG. Si cambia por usuario o cambia a cada minuto, SSR.
Ejemplo práctico
Esta web no usa SSR, y es una decisión consciente.
Los 101 términos del diccionario son iguales para todo el mundo y cambian cuando yo publico uno nuevo, no cada segundo. Generarlos en cada petición sería pagar un servidor encendido para producir siempre exactamente el mismo resultado.
Así que están generados al compilar, y el hosting solo sirve ficheros. Eso permite dos cosas: que la web viva en un alojamiento compartido barato, y que responda en milisegundos porque no hay nada que calcular.
Dónde sí haría falta SSR: en el portal de clientes de IMDICA. Ahí cada empresa ve sus pedidos, sus precios negociados y sus documentos. Eso no se puede generar por adelantado: no hay una versión de la página, hay una por cliente. Y por eso ese portal es dinámico, generado en el servidor con PHP en cada petición.
La regla que saco: contenido público y común, estático; contenido privado y personal, en servidor.
Errores comunes
- Usar SSR "porque es lo moderno". Si tu contenido no cambia por usuario, estás pagando un servidor para nada.
- Olvidar la caché. Aunque renderices en servidor, muchas páginas se pueden cachear unos segundos o minutos. Es la diferencia entre aguantar un pico y caerte.
- Errores de hidratación. Si el HTML que generó el servidor no coincide exactamente con lo que el cliente pinta, el navegador protesta y a veces repinta todo. La causa casi siempre es la misma: usar la fecha actual, un número aleatorio o algo del navegador durante el renderizado.
- Meter demasiado JavaScript. Con SSR el contenido aparece antes, pero si el paquete es enorme la página tarda en responder igual.
- No controlar el tiempo del servidor. Si tu página hace seis consultas encadenadas antes de responder, el visitante espera todas.
Cuándo usarlo
Sí cuando el contenido depende del usuario que ha entrado, cuando cambia constantemente, o cuando necesitas SEO en páginas que no se pueden generar por adelantado (un catálogo con filtros, resultados de búsqueda).
No cuando el contenido es el mismo para todos y cambia poco. Ahí SSG gana en velocidad, en coste y en simplicidad.
Y hay una vía intermedia que hoy usan casi todos los frameworks: generar estático y revalidar cada cierto tiempo. Sirves un fichero ya hecho y lo regeneras en segundo plano cada X minutos. Para catálogos que cambian a diario, suele ser la respuesta correcta.
