Web Rendering: SSR, CSR, SSG, ISR y Edge explicados

¿Qué es el renderizado web?

El renderizado web es el proceso que convierte el código de la aplicación y los datos en el HTML que muestra el navegador. Lo importante es dónde y cuándo ocurre: en el servidor en cada petición, en el navegador tras cargar JavaScript o por adelantado durante la compilación. Esa decisión condiciona la velocidad, el SEO, el coste de alojamiento y la frescura del contenido.

Las principales estrategias de renderizado

Cómo funciona cada estrategia

• SSG: un paso de compilación escribe un archivo HTML por URL y un CDN lo sirve. No se ejecuta nada por petición, así que es barato y aguanta bien los picos de tráfico, pero el contenido solo se actualiza tras una nueva compilación.
• SSR: el servidor construye el HTML de cada petición. El contenido siempre está al día y puede depender del usuario, pero cada visita consume tiempo de servidor y alarga el tiempo hasta el primer byte.
• CSR: el servidor envía una cáscara mínima y un paquete de JavaScript, y el navegador construye la página. La navegación dentro de la app es inmediata, pero la primera vista espera a que el paquete se descargue y se ejecute.
• ISR: páginas estáticas que se regeneran en segundo plano pasado un tiempo o cuando tú lo ordenas, con la velocidad de lo estático y una obsolescencia acotada.
• Renderizado en el edge: código SSR que se ejecuta en los puntos del CDN en vez de en una sola región de origen. Baja la latencia para usuarios lejanos, pero los entornos edge limitan las API y librerías disponibles.

Hidratación: donde se encuentran servidor y cliente

SSR y SSG envían HTML terminado, pero las partes interactivas siguen necesitando JavaScript. La hidratación es el paso en que ese JavaScript se engancha al HTML existente. En páginas grandes resulta costosa, por eso los frameworks ofrecen hidratación parcial, streaming y componentes de servidor para enviar menos JavaScript.

Ejemplo: elegir por página en una tienda online

• Portada y guías: SSG, porque son iguales para todos.
• Fichas de producto: ISR, para que un cambio de precio aparezca en minutos sin recompilar todo el catálogo.
• Carrito y pago: CSR o SSR, porque dependen del visitante y no necesitan posicionar.
• Banner por país: renderizado en el edge o un pequeño script en el cliente.

Errores comunes

• Usar CSR en páginas públicas que deben posicionar y sorprenderse de que las vistas previas y algunos rastreadores vean una página vacía.
• Usar SSR en páginas que nunca cambian: más coste de servidor y un primer byte más lento sin beneficio.
• Enviar un paquete de JavaScript enorme sobre HTML renderizado en el servidor, de modo que la página parece lista pero ignora los clics.
• Cachear en el CDN una salida SSR personalizada y servir la página de un usuario a otro.
• Elegir la estrategia por moda en lugar de medir páginas reales.

Renderizado, pruebas de rendimiento y monitorización

La estrategia de renderizado se refleja directamente en las métricas que importan. Las páginas estáticas y las renderizadas en el servidor suelen ayudar al Largest Contentful Paint, una hidratación pesada perjudica al Interaction to Next Paint, y el CSR traslada trabajo al dispositivo del visitante. Sigue las Core Web Vitals de forma periódica, por ejemplo con LoadFocus Page Speed Monitoring. La configuración está en el artículo cómo monitorizar Core Web Vitals con alertas e informes (en inglés).

El SSR también cambia la planificación de capacidad: cada petición ejecuta código, así que haz una prueba de carga antes de un lanzamiento para ver cuándo empiezan a subir los tiempos de respuesta. Un sitio servido de forma estática prueba sobre todo el CDN.

Preguntas frecuentes: renderizado web

¿SSR o SSG: cuál elegir?

SSG cuando la página es igual para todos y cambia poco. SSR cuando depende de la petición, por ejemplo de una cookie, la ubicación o datos al momento. Si necesitas ambas cosas, regenera páginas estáticas de forma programada o bajo demanda (ISR).

¿El renderizado en el cliente es malo para el SEO?

No necesariamente. Google puede ejecutar JavaScript, pero requiere un paso extra, y otros rastreadores o vistas previas de enlaces pueden ver una página vacía. Para páginas públicas que deben posicionar, sirve HTML real desde el servidor o desde la compilación.

¿Qué diferencia hay entre renderizado e hidratación?

El renderizado produce el HTML. La hidratación es el paso en que el JavaScript del navegador se engancha a ese HTML para que botones y formularios funcionen. Una página puede estar renderizada del todo y no responder a los clics hasta que termina la hidratación.

¿Puedo mezclar estrategias de renderizado en un mismo sitio?

Sí. La mayoría de los frameworks modernos eligen por ruta. Lo habitual es servir las páginas de marketing de forma estática, las fichas de producto con ISR y la aplicación con sesión iniciada con renderizado en el cliente.

¿Qué estrategia de renderizado es la más rápida?

Las páginas estáticas servidas desde un CDN suelen dar el menor tiempo hasta el primer byte, porque no se ejecuta código en cada petición. Aun así, la velocidad depende del peso de la página, las imágenes y el JavaScript: mide tus propias páginas en lugar de fiarte de la etiqueta.