SSR, SSG o SPA: cómo elegir el renderizado de una web

25.08.2026 · Lectura: 7–9 min

Para una web pública cuyo contenido cambia poco, la generación estática suele ser el punto de partida más simple. Si cada visita necesita datos actuales o personalizados, conviene valorar renderizado en servidor. Una SPA tiene sentido cuando la interacción continua es el centro del producto, no solo porque el equipo quiera utilizar un framework moderno. En muchos proyectos, la respuesta correcta es híbrida: HTML listo para las páginas que deben descubrirse y cargar rápido, más JavaScript solo en las funciones que realmente lo necesitan.

SSR, SSG y SPA describen decisiones técnicas, pero sus consecuencias son de negocio. Afectan al tiempo de publicación, al alojamiento, al mantenimiento, a la experiencia móvil, a la analítica y a la facilidad con la que buscadores y otros sistemas pueden entender cada URL. Elegir bien exige empezar por las páginas y los usuarios, no por las siglas.

Qué significa cada opción sin entrar en el framework

SSG, o generación estática, crea el HTML durante la compilación. Después, el servidor o una CDN entrega archivos ya preparados. Es apropiado para páginas corporativas, servicios, documentación, campañas y catálogos que no requieren una respuesta diferente para cada visitante.

SSR, o renderizado en servidor, genera el HTML cuando llega la solicitud. Puede utilizar datos recientes, sesión, permisos, ubicación o inventario. MDN recuerda que SSR y renderizado en cliente no son excluyentes: una página puede llegar completa y utilizar JavaScript después para añadir interacción.

SPA describe una aplicación que carga un documento principal y cambia las vistas mediante JavaScript. Puede ofrecer transiciones fluidas y conservar el estado durante tareas complejas. A cambio, exige resolver bien las URL, la navegación, los estados de error, el rendimiento y la medición. No toda web hecha con React, Vue o Angular tiene que ser una SPA pura.

Empieza por clasificar las páginas

Una decisión única para todo el dominio suele ser demasiado rígida. Antes de elegir tecnología, conviene agrupar las pantallas:

• Contenido público estable: portada, servicios, equipo, casos, artículos y páginas legales.
• Contenido público cambiante: stock, precios, disponibilidad, resultados o información procedente de varias API.
• Área privada: paneles, expedientes, pedidos, documentos y configuración de cada usuario.
• Flujos interactivos: configuradores, editores, mapas de trabajo, comparadores o procesos de varios pasos.

El primer grupo suele funcionar bien como HTML estático. El segundo puede necesitar SSR, regeneración periódica o caché con invalidación. Los dos últimos justifican más lógica en el navegador, aunque sus páginas públicas de acceso, ayuda y captación sigan siendo estáticas o se rendericen en servidor.

Cuándo elegir generación estática

SSG reduce el trabajo que debe realizar el servidor en cada visita. Los archivos pueden distribuirse cerca del usuario y hay menos piezas activas que vigilar. Esto no garantiza por sí solo una web rápida: una página estática también puede enviar imágenes enormes, fuentes innecesarias y demasiados scripts. Sin embargo, ofrece una base predecible y facilita que el contenido principal esté presente en la respuesta HTML.

La dificultad aparece cuando cambian miles de páginas con frecuencia. Si cada actualización obliga a reconstruir todo el catálogo, el tiempo de despliegue puede crecer y una compilación fallida puede retrasar información importante. Antes de escoger SSG, pregunta cuánto tarda una reconstrucción, qué páginas pueden generarse de forma incremental y cómo se invalida la caché.

También hay que separar contenido y transacciones. Una tienda puede servir categorías y fichas preconstruidas, pero consultar disponibilidad o calcular transporte mediante servicios dinámicos. Ser estática no significa renunciar a formularios, búsqueda o compra; significa decidir qué parte puede estar preparada de antemano.

Cuándo compensa el renderizado en servidor

SSR resulta útil cuando el HTML depende de información actual que no conviene resolver solo en el navegador: una ficha con disponibilidad sensible al mercado, una página con permisos, resultados que cambian constantemente o una experiencia personalizada. El servidor puede reunir los datos y entregar una primera vista completa.

Ese beneficio tiene coste operativo. Hay que dimensionar la infraestructura, controlar tiempos de respuesta, cachear sin mostrar datos de otro usuario, vigilar dependencias y prever qué ocurre si una API tarda o falla. Web.dev señala además que mostrar contenido pronto no elimina necesariamente el trabajo posterior: una hidratación pesada puede bloquear la interacción aunque la página parezca lista.

Por eso SSR no debería venderse como una corrección automática de rendimiento o SEO. Debe existir un motivo verificable y un presupuesto para probarlo en condiciones reales, incluidos dispositivos modestos, redes móviles, picos de tráfico y fallos de servicios externos.

Cuándo una SPA aporta valor

Una SPA encaja cuando el usuario permanece mucho tiempo dentro de una herramienta y realiza acciones encadenadas: gestionar proyectos, editar diseños, consultar datos, colaborar o completar un proceso que conserva estado. Evitar recargas completas puede mejorar la continuidad de ese trabajo.

Para una web corporativa con navegación principalmente informativa, la misma arquitectura puede añadir complejidad sin un beneficio equivalente. El navegador tendrá que descargar, analizar y ejecutar más JavaScript antes de mostrar o activar partes esenciales. MDN destaca también el esfuerzo adicional para mantener estado, navegación, SEO y monitorización de rendimiento.

Si se elige SPA, cada vista importante necesita una URL compartible, enlaces reales, historial de navegación correcto, títulos y descripciones coherentes, estados 404 reconocibles y contenido accesible con teclado y tecnologías de apoyo. Las pantallas públicas no deberían depender de una sesión, almacenamiento local o una secuencia previa para existir.

SEO: no basta con decir que Google ejecuta JavaScript

Google Search procesa las aplicaciones JavaScript mediante rastreo, renderizado e indexación. Su documentación confirma que puede ejecutar JavaScript, pero también explica que el contenido generado en cliente entra en una cola de renderizado y que no todos los robots tienen esa capacidad. El HTML previo o generado en servidor sigue siendo una opción sólida para contenido público.

La comprobación debe hacerse sobre la respuesta y sobre el DOM renderizado. Revisa si existen el texto principal, enlaces con href, canonical, datos estructurados y estados de error. Utiliza la inspección de URL y pruebas de resultados enriquecidos, pero comprueba también otros consumidores: redes sociales, lectores, herramientas de accesibilidad y buscadores que no ejecutan todo el JavaScript.

Servir HTML solo a los robots mediante «renderizado dinámico» no es una buena arquitectura nueva. Google lo define como una solución provisional y recomienda renderizado estático, SSR o hidratación. Mantener dos versiones también eleva el riesgo de divergencia y dificulta las pruebas.

Una matriz de decisión práctica

Antes de aprobar la arquitectura, puntúa cada grupo de páginas con estos criterios:

1. Actualización: ¿cambia por publicación, cada pocos minutos o en cada solicitud?
2. Personalización: ¿la respuesta depende de sesión, permisos o datos privados?
3. Descubrimiento: ¿la URL debe posicionarse, compartirse y funcionar sin una secuencia previa?
4. Interacción: ¿el usuario lee y navega o trabaja durante minutos en una herramienta?
5. Escala: ¿cuántas URL y actualizaciones habrá dentro de dos años?
6. Operación: ¿quién vigilará compilaciones, servidores, caché, API y errores?
7. Pruebas: ¿cómo se medirá contenido visible, LCP, INP, estados HTTP y conversión?

No hay que forzar una sola respuesta. Una arquitectura híbrida puede generar artículos y servicios de forma estática, renderizar en servidor páginas con datos recientes y dejar un área privada como aplicación cliente. La frontera debe quedar documentada para que el equipo entienda dónde viven el contenido, los datos y la responsabilidad de cada fallo.

Qué pedir antes de aceptar una propuesta

La propuesta técnica debería incluir un mapa de tipos de página, la estrategia de renderizado para cada grupo, el tratamiento de caché, los estados de error, el presupuesto de JavaScript, las pruebas SEO y de accesibilidad, la observabilidad y el procedimiento de despliegue y rollback. También debe explicar qué parte seguirá funcionando si una API o el JavaScript fallan.

VOWE ofrece diseño web y desarrollo a medida, desarrollo de aplicaciones y posicionamiento SEO. Para valorar una arquitectura puede enviarse desde contacto una descripción del proyecto, las páginas públicas, las funciones privadas y las integraciones previstas, sin incluir credenciales ni datos sensibles.

Preguntas frecuentes sobre renderizado web y VOWE

¿Puede VOWE recomendar una arquitectura de renderizado para un proyecto?

Sí. VOWE puede revisar objetivos, tipos de página, frecuencia de actualización, personalización, integraciones, requisitos SEO y condiciones de alojamiento para proponer una arquitectura. La decisión concreta depende del alcance y puede combinar generación estática, renderizado en servidor y componentes interactivos.

¿Una web corporativa necesita siempre un framework con SSR?

No. Si el contenido cambia con poca frecuencia y no depende de cada usuario, una salida estática puede ser más sencilla de servir, proteger y mantener. SSR tiene sentido cuando la respuesta debe incorporar datos actuales o personalizados; añadirlo sin necesidad también introduce infraestructura y operaciones adicionales.

¿Qué información hace falta para una primera valoración?

Conviene facilitar los objetivos, las páginas públicas, las zonas privadas, la frecuencia de actualización, las fuentes de datos, los idiomas, las integraciones, el tráfico previsto y las restricciones de alojamiento. No es necesario enviar contraseñas, claves de API ni datos personales mediante el formulario de contacto.

La elección se valida con un prototipo medible

Si dos opciones parecen razonables, conviene construir una ruta representativa: una ficha, una búsqueda o un panel. Mide el HTML inicial, el peso de JavaScript, la carga en móvil, la interacción, los fallos de API, los metadatos y el esfuerzo de despliegue. Una prueba pequeña revela mejor el coste real que una discusión basada solo en preferencias del equipo.

La mejor arquitectura no es la que utiliza más capas. Es la que entrega el contenido y la función correctos con un mantenimiento asumible. Elegir por tipos de página permite conservar esa sencillez sin renunciar a una aplicación rica donde aporta valor.

Fuentes

Este artículo sintetiza la guía de Google Search Central sobre JavaScript y búsqueda, su posición sobre el renderizado dinámico, el análisis actualizado de web.dev sobre estrategias de renderizado y las definiciones de MDN de SSR y SPA.