Inicio › Tecnología › Renderizado En El Lado Del Servidor
El renderizado en el lado del servidor (server-side rendering, SSR) es una técnica en la qué el servidor ejecuta la aplicación y genera el HTML completo de una página antes de enviarlo al navegador, en lugar de mandar un esqueleto vacío qué el JavaScript del cliente rellena después. Frameworks como Next.js, Nuxt.js o Remix ofrecen SSR de forma nativa: en cada petición, el servidor ejecuta los componentes, obtiene los datos necesarios y devuelve una respuesta ya renderizada, qué el navegador puede pintar de inmediato. Después, el proceso de hidratación adjunta los manejadores de eventos de JavaScript sobre ese HTML para qué la página se vuelva interactiva sin tener qué reconstruirla desde cero.
En vez de qué tu navegador tenga qué montar la página pieza a pieza con JavaScript, el servidor la deja ya construida y lista para mostrar. Así ves contenido casi al instante, aunque tu conexión sea lenta o tu móvil no sea muy potente, porque no dependes de qué se descargue y ejecute todo el código antes de ver algo en pantalla.
Una tienda online qué depende de qué Google indexe bien sus fichas de producto suele optar por SSR: los buscadores reciben HTML ya completo con el nombre, precio y descripción del producto, sin depender de ejecutar JavaScript para verlo. El coste a cambio es mayor carga en el servidor, porque cada visita implica generar la página de nuevo, algo qué se suele mitigar con caché en el borde (edge caching) o renderizado incremental.
No. El SSR genera el HTML en cada petición, con datos actualizados al momento; la generación estática (SSG) construye las páginas de antemano, durante el proceso de build, y las sirve tal cual desde un CDN. SSG es más rápido pero no sirve bien para contenido qué cambia constantemente.
Es el proceso por el qué React o Vue toman el HTML ya renderizado por el servidor y le añaden la interactividad en el navegador. Si el HTML generado en servidor no coincide exactamente con lo qué el cliente espera renderizar, aparecen errores de 'hydration mismatch' y partes de la interfaz pueden parpadear o comportarse de forma inesperada.
Puede hacerlo si cada visita dispara una renderización completa sin caché, porque el servidor consume CPU en cada petición. Por eso suele combinarse con estrategias como el renderizado incremental estático (ISR) o cachés de respuesta para evitar recalcular páginas qué no han cambiado.