Desarrollo de aplicaciones web: SPA, SSR o sitio estático

La nueva plataforma de clientes quedó rápida y ordenada. El equipo la construyó como una sola aplicación en Angular: entras, cargas una vez y después todo se mueve sin recargar. Tres meses más tarde, marketing pregunta por qué las páginas de producto no aparecen en Google. Al abrir el código fuente de una de ellas, lo único que hay es un <div> vacío y un par de scripts.

En el desarrollo de aplicaciones web, la decisión sobre dónde se genera el HTML se toma temprano y cuesta caro corregirla después. Puede armarse en el navegador (SPA), en el servidor en cada visita (SSR) o una sola vez al compilar (sitio estático). Las tres son válidas y ninguna es "la moderna". Cada una cambia el SEO, la velocidad percibida, lo que pagas de hosting y cuánta infraestructura tiene que mantener tu equipo. Si todavía estás evaluando si tu sitio necesita desarrollo a medida o le basta un CMS, parte por cuándo ya no basta un CMS. Este artículo sigue desde ahí: ya sabes que vas a desarrollar, y ahora toca elegir la arquitectura de aplicaciones web.

Qué significa cada opción

Una SPA (single page application) envía al navegador una página casi vacía y un paquete de JavaScript que dibuja todo lo demás. La primera carga pesa más, pero después cada pantalla aparece sin ir a buscar una página nueva al servidor.

Con SSR (server-side rendering), un servidor arma el HTML completo en cada solicitud y lo envía listo. El navegador muestra contenido de inmediato y luego el JavaScript "despierta" la página para que responda a clics, un proceso que se conoce como hidratación.

Un sitio estático genera todas las páginas al compilar. Lo que se publica son archivos HTML que cualquier CDN puede servir, sin un servidor de aplicación detrás.

Los frameworks actuales ya no obligan a elegir una sola. La documentación oficial de Angular describe tres modos: renderizado en el cliente (el comportamiento por defecto), en el servidor y prerenderizado al compilar. También permite combinarlos ruta por ruta, lo que llaman renderizado híbrido. Se activa con ng add @angular/ssr en un proyecto existente.

Comparación práctica

	SPA	SSR	Sitio estático
Dónde se genera el HTML	En el navegador	En el servidor, en cada visita	Al compilar, una vez
SEO de páginas públicas	Depende de que el buscador ejecute JavaScript	Bueno: el HTML llega completo	Bueno: el HTML llega completo
Primera carga	Más lenta	Rápida, si el servidor responde rápido	La más rápida
Navegación posterior	Muy fluida	Fluida después de hidratar	Recarga entre páginas, salvo que se combine con JS
Datos que cambian por usuario	Natural	Natural	Requiere llamadas a API desde el navegador
Hosting	Archivos estáticos + API	Servidor Node.js siempre encendido	Archivos estáticos (CDN)
Complejidad operativa	Media	Alta	Baja

Al cotizar, la fila de hosting se mira poco. Una SPA o un sitio estático se publican como archivos. En Azure, por ejemplo, Static Web Apps tiene un plan gratuito sin SLA y un plan Standard de US$9 por aplicación al mes, ambos con 100 GB de transferencia incluidos por suscripción (precios de lista consultados en noviembre de 2026). Con SSR necesitas además un proceso Node.js corriendo, con su monitoreo, escalamiento y parches. No es carísimo, pero es un componente más que alguien tiene que operar.

Qué pasa con Google y una SPA

Google sí ejecuta JavaScript. Según su guía de conceptos básicos de SEO con JavaScript, el proceso tiene tres fases: rastreo, renderizado e indexación. Las páginas quedan en una cola para renderizar que puede durar unos segundos "o más", hasta que un Chromium sin interfaz ejecuta el código. La misma guía dice que el renderizado en servidor o el prerenderizado "sigue siendo una gran idea", porque el sitio carga más rápido para usuarios y rastreadores, y porque no todos los bots ejecutan JavaScript.

Ese último punto se olvida seguido. Google no es el único que lee tu sitio. Las vistas previas al compartir un enlace en WhatsApp o LinkedIn también dependen de que el HTML traiga título, descripción e imagen.

Si ya tienes una SPA, la guía de Google deja algunos ajustes concretos:

• No uses fragmentos (#/productos) para cargar contenido distinto. Las rutas tienen que ser URL reales.
• Devuelve códigos HTTP con sentido. Una SPA que responde 200 a cualquier ruta inexistente genera "soft 404"; Google sugiere redirigir a una URL que responda 404 o agregar noindex por JavaScript a la página de error.
• No dependas del renderizado dinámico (servir una versión prerenderizada solo a los bots). Google lo califica como una solución provisoria que no recomienda, por la complejidad y los recursos que agrega.

Cómo elegir según lo que vas a construir

Conviene preguntarse quién va a ver cada página y si alguien necesita encontrarla en un buscador.

Si todo el sistema vive detrás de un login (un portal de clientes, una intranet, un backoffice conectado al ERP), una SPA suele ser la opción más simple. Ningún buscador va a indexar esas pantallas, y la fluidez entre vistas vale más que la primera carga. Angular con una API en Node.js y hosting estático es una combinación sólida y barata de operar.

Si el contenido público cambia poco (sitio corporativo, documentación, landing pages, un blog que se actualiza unas veces por semana), lo estático gana en casi todo: velocidad, costo y superficie de ataque, porque no hay servidor que vulnerar. Generadores como Astro, Hugo o Eleventy, o el prerenderizado del propio Angular, resuelven esto bien.

Si las páginas públicas cambian seguido y además tienen que posicionar, como un catálogo con stock y precios que vienen del ERP, ahí SSR se justifica. También cuando el contenido depende de quién lo pide pero igual debe llegar armado, por ejemplo precios por región.

Lo más común en un proyecto empresarial es una mezcla: páginas públicas prerenderizadas o con SSR, y la zona privada como SPA. Con el renderizado híbrido de Angular esto se configura por ruta dentro del mismo proyecto. Si son dos aplicaciones separadas, también funciona y a veces es más fácil de mantener.

Una advertencia: SSR agrega trabajo de desarrollo que suele subestimarse. El código tiene que correr bien en el servidor y en el navegador, y lo que en una SPA es trivial (leer window, guardar algo en localStorage) ahí falla si no se protege. Tenlo presente al revisar una propuesta. En qué explica el costo de una aplicación a medida vemos cómo estas decisiones mueven el presupuesto.

Lo que conviene dejar escrito en el requerimiento

Antes de que alguien elija el framework, deja resuelto esto:

1. Qué páginas son públicas y necesitan posicionar, y cuáles están detrás de un login.
2. Cada cuánto cambia el contenido público y de dónde salen los datos.
3. Las metas de rendimiento, medidas con Core Web Vitals (umbrales y forma de medirlos en el artículo sobre desarrollo web a medida).
4. Dónde se va a alojar y quién lo va a operar después de la entrega.
5. Cómo se manejan las URL antiguas y las redirecciones si reemplazas un sitio existente.

Con esas respuestas, la arquitectura casi se decide sola, y cualquier proveedor que proponga algo distinto va a tener que explicar por qué.

Preguntas frecuentes

¿Una SPA es mala para el SEO?

No necesariamente. Google ejecuta JavaScript y puede indexar una SPA bien construida, con URL reales y códigos HTTP correctos. Pero el renderizado pasa por una cola, y otros bots no ejecutan JavaScript. Para páginas cuyo objetivo es posicionar, el HTML generado en servidor o al compilar es la apuesta más segura.

¿Se puede pasar una SPA en Angular a SSR sin reescribirla?

En muchos casos, sí. Angular agrega SSR a un proyecto existente con ng add @angular/ssr y permite definir por ruta qué se renderiza en servidor, qué se prerenderiza y qué queda en el cliente. El trabajo real está en revisar el código que asume que siempre corre en un navegador.

¿Un sitio estático sirve si tengo formularios o datos dinámicos?

Sí. Las páginas se generan al compilar, pero pueden llamar a una API para enviar formularios o mostrar datos puntuales. Lo que no conviene es usar un sitio estático cuando casi todo el contenido depende del usuario que está conectado.

Hablemos de tu proyecto

En Disrupsoft desarrollamos aplicaciones web a medida con Angular, Node.js, Azure y Power Platform, y partimos cada proyecto entendiendo tus requerimientos antes de elegir la tecnología. Si estás definiendo la arquitectura de una plataforma nueva o tu aplicación actual no aparece donde debería, conversemos sobre tu proyecto de desarrollo a medida.