Ventajas y desventajas del server-side rendering

El server-side rendering (SSR) mejora el SEO, acelera la carga inicial y permite usar el servidor como proxy, pero implica costos de infraestructura, riesgos de seguridad y problemas de compatibilidad con APIs del navegador. Si trabajas con React o frameworks similares, entender estas ventajas y desventajas te ayuda a decidir cuándo conviene renderizar desde el servidor.

¿Qué ventajas tiene el server-side rendering frente al client-side rendering?

La principal razón por la que muchos proyectos migran a SSR es el impacto directo en indexación, performance y accesibilidad.

Cuando el servidor entrega el HTML ya construido, los motores de búsqueda reciben en el primer vistazo el texto, los headings y las etiquetas importantes. Eso se traduce en una mejor indexación y SEO, algo que no obtienes con la misma facilidad en una Single Page Application tradicional.

La carga inicial también se siente más rápida. El navegador no espera a que JavaScript construya el DOM: ya lo recibe listo. Y como los elementos HTML llegan completos desde el principio, la accesibilidad mejora para lectores de pantalla y tecnologías asistivas.

¿Cómo funciona el SSR como proxy server y prefetching?

Una ventaja menos obvia es usar el servidor de SSR como intermediario entre tu cliente y APIs externas, por ejemplo la API de Rick y Morty o la de la NASA.

• Recibes la respuesta en el servidor.
• Limpias datos malformados o de difícil acceso.
• Se la entregas al cliente lista para usar.

Esto te da control sobre tu política de manejo de datos y habilita el prefetching: cargas información antes de que el cliente la pida. Si necesitas mostrar 1,000 usuarios, el servidor los trae y los entrega ya renderizados, sin una sola request desde el navegador. El usuario incluso puede ahorrar datos móviles. [2:05]

¿Qué es el prefetching en SSR? Es cargar los datos que tu aplicación necesita directamente desde el servidor, antes de enviar la respuesta al cliente, para que el navegador no tenga que hacer peticiones adicionales.

¿Cuáles son las desventajas del server-side rendering?

No todo es ganancia. Adoptar SSR implica cambios estructurales que cuestan dinero, tiempo y atención a la seguridad.

Primero, necesitas un servidor de Node corriendo en algún cloud provider como Amazon o Google. Ya no basta con subir archivos estáticos a Netlify, GitHub Pages o un Apache simple. Existen alternativas gratuitas, pero llegan con limitantes claras.

Segundo, abres un nuevo vector de ataque. Bajaste la dependencia del cliente con JavaScript, pero ahora tienes un servidor que puede ser atacado si no aplicas buenas prácticas de seguridad backend. [3:35]

Tercero, el routing se vuelve más lento. En una Single Page Application, una vez que el index.js con HTML y CSS llega al cliente, las rutas se resuelven localmente. Con SSR, el servidor decide qué vista mostrar en cada navegación, lo que añade latencia.

¿Por qué hay incompatibilidad con APIs del navegador en SSR?

Esta es, para muchos desarrolladores, la desventaja más dolorosa.

Cuando renderizas en el servidor un archivo JSX de React que intenta acceder a localStorage, a la API de caché, o a los objetos window o document, vas a recibir una excepción del tipo "esto no está definido". Y tiene sentido: en el contexto del servidor esas APIs simplemente no existen.

¿Por qué window no está definido en server-side rendering? Porque el primer render ocurre en Node, donde no existe el contexto del navegador. Las APIs como window, document o localStorage solo aparecen cuando el código llega al cliente.

Para resolverlo entra en juego la rehidratación. Piénsalo así: el primer HTML llega seco, solo con elementos del DOM y sin interactividad. Cuando React toma el control en el cliente, no reconstruye todo desde cero, sino que reutiliza el DOM existente y le agrega una pizquita de JavaScript para activar la interactividad.

¿Cuándo conviene usar SSR y dónde aprender más sobre rendering?

SSR brilla cuando el SEO, la velocidad de la primera carga y la accesibilidad son prioridad, y cuando puedes asumir el costo del servidor y la complejidad extra. Si tu aplicación es interna, vive detrás de un login o no depende de buscadores, quizá el client-side rendering te siga sirviendo mejor.

Para profundizar en cómo se mide el performance entre client-side y server-side, y entender la hidratación a nivel técnico, web.dev publica artículos escritos por expertos de Google, las mismas personas detrás de Lighthouse y las DevTools. Ahí encuentras explicaciones detalladas sobre core web vitals en cada estrategia de renderizado.

¿Tu próximo proyecto en React necesita SSR o puedes quedarte con una SPA? Cuéntame en los comentarios qué caso de uso estás evaluando.