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

Toda página web necesita convertir datos y plantillas en HTML. La pregunta es dónde ocurre esa conversión y en qué momento. Cuando el trabajo sucede en la máquina que atiende la petición, el navegador recibe un documento que ya contiene los textos, los enlaces y la estructura.

La alternativa opuesta es el renderizado en cliente. Ahí el servidor devuelve un HTML casi vacío junto con un paquete de JavaScript, y el navegador construye la interfaz después de descargar y ejecutar ese código. El usuario ve una pantalla en blanco hasta que el proceso termina, y cualquier robot que no ejecute JavaScript ve exactamente lo mismo.

Entre ambos extremos está el renderizado estático, también llamado prerenderizado. El HTML se genera una sola vez durante la compilación y se sirve idéntico a todas las visitas. La diferencia con el SSR no está en lo que llega al navegador, sino en el momento de la generación: el estático produce el HTML antes de que exista la petición, el SSR lo produce durante la petición. Por eso el estático encaja con catálogos y documentación que cambian poco, mientras que el SSR encaja con contenido que depende del usuario, del stock o de la hora.

En español conviven tres formas para lo mismo: renderizado en servidor, renderizado del lado del servidor y las siglas inglesas SSR.

El recorrido empieza con una petición HTTP. El servidor recibe la URL, resuelve la ruta, consulta las fuentes de datos que hagan falta y ejecuta el mismo código de componentes que ejecutaría el navegador. El resultado es una cadena de HTML que viaja como cuerpo de la respuesta.

El navegador puede pintar ese HTML en cuanto lo recibe, sin esperar al JavaScript. Después llega la segunda mitad del proceso: se descarga el paquete de cliente y se ejecuta la hidratación, que asocia el estado y los manejadores de eventos al HTML ya presente. Hasta que la hidratación termina, la página se ve completa pero no responde a los clics.

La diferencia en el documento que viaja por la red se aprecia comparando ambos casos:

<!-- Cliente: el HTML llega vacío -->
<div id="app"></div>
<script src="/bundle.js"></script>

<!-- SSR: el HTML ya trae contenido -->
<div id="app">
  <h1>Zapatillas de trail</h1>
  <p>Precio: 119 euros</p>
</div>
<script src="/bundle.js"></script>

Para los buscadores el recorrido es distinto. La documentación de Google describe tres fases encadenadas: rastreo, renderizado e indexación. Las páginas que responden con estado 200 entran en una cola de renderizado, un Chromium sin interfaz las procesa cuando hay recursos disponibles y el HTML resultante es el que se indexa. El propio texto advierte que la espera en esa cola suele durar unos segundos, aunque puede alargarse más. Con el HTML servido desde el origen, ese paso deja de ser el punto frágil, porque el contenido ya está en la primera respuesta.

Lo que se decide aquí es qué plantilla se genera dónde. La elección de framework es secundaria. Una ficha de producto con precio y disponibilidad variables, un buscador con filtros y una página de perfil no admiten la misma respuesta que un artículo de blog.

El primer efecto es de indexabilidad. Si el contenido principal solo aparece después de ejecutar JavaScript, su llegada al índice depende de que el renderizado se complete sin incidencias. Un script que falla, un recurso bloqueado en robots.txt o una llamada a una API que agota el tiempo dejan la página vacía a ojos del buscador. Con el HTML construido en el origen, ese riesgo desaparece.

El segundo efecto es de velocidad. Enviar contenido ya renderizado adelanta el primer pintado y suele mejorar el LCP, porque el elemento principal no espera a un paquete de JavaScript. A cambio, generar el HTML en cada petición consume tiempo de servidor y empeora el TTFB frente a una respuesta estática guardada de antemano.

Conviene decirlo sin rodeos: el SSR no es un factor de posicionamiento y no existe ninguna documentación que lo presente como tal. Lo que sí está documentado es su efecto sobre la indexabilidad y sobre las métricas de carga. Esas dos cosas condicionan el rendimiento de una página en resultados, y ese es el vínculo real.

• Decide la estrategia por plantilla y no para el sitio entero: lo que cambia en cada visita pide SSR, lo estable puede servirse ya generado.
• Coloca en el HTML inicial todo lo que deba indexarse: título, texto principal, enlaces internos, etiqueta canónica y directivas de robots.
• Compara el HTML de origen con el HTML renderizado en la herramienta de inspección de URLs de Search Console, y hazlo con una plantilla de cada tipo, no solo con la portada.
• No bloquees en robots.txt los archivos JavaScript y CSS que la página necesita para renderizarse.
• Pon una capa de caché delante del renderizado (CDN, caché de página o caché de datos) para contener el coste en TTFB.
• Vigila la hidratación midiendo el INP y reduciendo el JavaScript enviado, porque una página visible que no responde a los clics sigue siendo lenta para quien la usa.

• Dar por hecho que el buscador no ejecuta JavaScript. Sí lo ejecuta, pero en una fase posterior y sujeta a recursos disponibles, lo que convierte cada fallo de script en un riesgo de contenido ausente.
• Servir a los robots un HTML distinto del que recibe la persona. Si la diferencia es sustancial, deja de ser una decisión de renderizado y entra en el terreno del encubrimiento.
• Aplicar SSR a todas las rutas sin caché y descubrir el coste después, en la factura del servidor y en un TTFB que sube en las horas punta.
• Confundir «el HTML llega completo» con «la página está lista». La hidratación puede tardar y bloquear la interacción durante varios segundos.
• Dejar el renderizado dinámico instalado como solución permanente. Google lo describe como una solución alternativa y provisional que no recomienda, y propone en su lugar el renderizado en servidor, el estático o la hidratación.