SSR vs SSG: cuándo generar una página en el servidor o al construirla
Publicado el 2026-10-20 por frfrand
Qué son SSR y SSG, diferencias en rendimiento, SEO, personalización, caché y cuándo elegir cada estrategia.
SSR significa renderizado del lado del servidor y SSG significa generación estática de páginas. Las dos estrategias pueden entregar HTML al navegador, pero difieren en cuándo se prepara ese HTML y cómo se actualiza.
Si estás creando una web con Next.js u otro framework moderno, esta elección afecta a velocidad, costes de servidor, contenido dinámico y mantenimiento.
La diferencia con una carta de restaurante
Pensá en imprimir la carta del restaurante cada vez que un cliente se sienta, con los platos disponibles en ese instante. Eso se parece a SSR: el servidor prepara la respuesta cuando llega una solicitud.
Ahora imaginá que imprimís cien cartas al principio del día y las repartís cuando alguien las pide. Eso se parece a SSG: el HTML se genera antes, durante la construcción o publicación del sitio.
La segunda opción puede ser muy rápida, pero hay que decidir cuándo regenerar las cartas si cambian los precios.
¿Qué sucede con SSR?
El navegador solicita una página; el servidor obtiene los datos que necesita y genera HTML para esa petición. Puede incluir información actualizada o personalizada, según la arquitectura.
Pero cada solicitud puede implicar trabajo adicional. Una consulta lenta a la base de datos puede retrasar la respuesta. También se puede añadir caché donde sea seguro, sin entregar información privada a otra persona.
SSR no significa que todo el JavaScript desaparezca: una página puede necesitar código en el cliente para interactividad.
¿Y con SSG?
El sistema construye el HTML antes de que lleguen los visitantes. Es especialmente útil para documentación, páginas informativas, artículos o catálogos donde el contenido cambia de manera controlada.
Ese HTML puede servirse desde archivos o una CDN con poca lógica de servidor por visita. Si el contenido cambia, quizá sea necesario volver a construir o invalidar una versión almacenada.
No todas las plataformas generan las páginas estáticas exactamente igual; algunas permiten estrategias de regeneración incremental.
¿Cuál posiciona mejor en Google?
No existe una regla que diga «SSR gana» o «SSG gana». Ambos pueden entregar HTML indexable correctamente. Importan el contenido real, enlaces, metadatos, accesibilidad, estabilidad y rendimiento percibido.
Si una página tiene excelente contenido y una estructura clara, la estrategia de renderizado es una decisión de implementación, no una garantía de ranking.
También conviene evitar generar cientos de URLs vacías o duplicadas solo para aumentar el número de páginas indexables.
Un ejemplo con una web de tours
La descripción de un recorrido por Copenhague podría estar generada estáticamente. Fotografías, itinerario y preguntas frecuentes cambian poco.
Pero la disponibilidad de plazas para mañana depende de reservas recientes. Esa parte puede consultar un backend o utilizar una estrategia dinámica bien diseñada.
Una aplicación real puede combinar estrategias en lugar de elegir una sola para todo el dominio.
¿SSR es lo mismo que SPA?
No. SPA describe un patrón de navegación e interacción de la aplicación; SSR y SSG describen cómo se obtiene o genera el HTML. Muchos frameworks combinan renderizado de servidor, contenido estático e interactividad del navegador.
Un sitio puede entregar HTML desde el servidor y luego hidratar componentes interactivos. Conocer estos conceptos evita discusiones en las que cada persona compara cosas de categorías diferentes.
Errores que conviene evitar
Crear contenido privado como HTML estático público. Una página personalizada exige políticas de caché y acceso adecuadas.
Consultar datos dinámicos innecesariamente en cada visita. Si un artículo cambia una vez al mes, recalcular todo puede desperdiciar recursos.
Medir solamente la primera carga. La navegación posterior y las métricas de usuarios reales importan.
¿Dónde entra ArduMaker?
En un despliegue Git de ArduMaker podés alojar un frontend generado estáticamente o ejecutar el servidor de una aplicación SSR, según sus requisitos. La plataforma de alojamiento no reemplaza la decisión de cómo renderizar cada ruta.
En una frase: SSR prepara HTML al atender la solicitud; SSG lo prepara anticipadamente. La elección depende de cambios, personalización y coste de generación.
Fuentes: Renderizado web en web.dev · Rendering en Next.js.