Ventajas y desventajas del server-side rendering

Curso de Server Side Render o SSR con React.js

Contenido del curso

No sé dónde empezar

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:17

Ventajas y desventajas del server-side rendering

Curso de Server Side Render o SSR con React.js

Clase 5 de 17

Clase 5 / 17

Recursos

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.

Fundamentos de SSR

Por qué React necesita server-side rendering

Problemas reales de las SPAs con JavaScript

Creación y Funcionamiento de una SPA con Create React App

CSR vs SSR: cómo el servidor pinta primero

Ventajas y desventajas del server-side rendering

Crea tu primer app con SSR

Proyecto Helix Eye: de CSR a SSR

Webpack para servidor Node con TypeScript

Servidor Express con TypeScript desde cero

Función template HTML dinámica en TypeScript

renderToString y StaticRouter en el servidor

Hidratación de React con hydrateRoot en SSR

Prefetching de API en el servidor con Axios

Inyectando initialProps del servidor a React

Cómo inyectar estilos de SSR sin flickering

Bonus

Hot Module Replacement con Webpack y Express

Tu motor SSR vs Next.js en práctica

Helix Eye como proyecto de portafolio

Ventajas y desventajas del server-side rendering

Progreso del curso

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Recursos

Recursos