Qué es una SPA y qué gana (y pierde) tu sitio con ella
Publicado el 2026-09-12 por frfrand
Una sola página que se reescribe sola: qué problema resuelve, por qué rompió el botón de atrás durante años, qué pasa con el SEO y cuándo conviene no usarla.
SPA significa Single Page Application: aplicación de una sola página. El nombre describe el mecanismo, no la experiencia.
Hay un solo documento HTML. Cuando navegás, no se pide una página nueva: el JavaScript intercepta el clic, pide los datos que necesita y reescribe una parte de lo que ya está en pantalla.
Qué problema vino a resolver
En la web clásica, cada clic descarta todo y empieza de cero. Eso está perfecto para leer artículos y es incómodo para trabajar.
Si estás en un panel con un filtro aplicado, un panel lateral abierto y un formulario a medio llenar, cada navegación completa te borra todo ese contexto. Las SPA aparecieron para que la web se pareciera más a una aplicación de escritorio, donde el estado sobrevive.
Lo que se gana
Navegación sin parpadeo. Una vez cargada, cambiar de sección es instantáneo: sólo viaja un JSON chico, no un documento entero.
El estado sobrevive. Un reproductor que sigue sonando mientras navegás, un carrito que no se pierde, un filtro que queda aplicado.
El servidor manda menos. Devuelve datos, no HTML. Eso mismo sirve para la app móvil sin duplicar nada.
Lo que se paga
La primera carga. Hay que descargar el JavaScript y ejecutarlo antes de ver algo. En una conexión buena son milisegundos; en un teléfono viejo con red lenta pueden ser varios segundos de pantalla blanca.
Te hacés cargo del navegador. Todo lo que el navegador hacía gratis pasa a ser tu responsabilidad: el botón de atrás, el historial, el título de la pestaña, el desplazamiento al cambiar de pantalla, los estados de carga y de error.
Durante años las SPA tuvieron mala fama justamente por esto: rompían el botón de atrás. Hoy los enrutadores lo resuelven bien, pero sigue siendo algo que hay que hacer a propósito.
El contenido no está en el HTML. Esto afecta dos cosas distintas que se confunden:
- Buscadores: Google ejecuta JavaScript e indexa igual, aunque más lento. No es el desastre que era.
- Vistas previas al compartir: acá sí duele. Cuando pegás un link en un chat o una red social, lo que genera la tarjeta casi nunca ejecuta JavaScript. Si tu título y tu descripción los pone el script, la vista previa sale vacía. Es el problema más común y el menos anticipado.
La solución que usa casi todo el mundo
Prerenderizar: generar, al momento de publicar, una versión HTML de cada ruta pública con su título, su descripción y su contenido.
Los visitantes reciben la SPA completa y siguen teniendo la navegación instantánea. Los buscadores y los generadores de vista previa reciben HTML real. No hay que elegir.
Es exactamente lo que hacemos en el sitio de ArduMaker: cada ruta pública se prerenderiza al compilar, y la aplicación se monta encima cuando el navegador termina de cargar.
Cuándo no conviene
Si tu sitio es contenido que se lee (un blog, una documentación, una landing), la SPA suma complejidad sin beneficio. Un sitio estático generado al publicar es más rápido, más barato y más difícil de romper.
La regla simple: si la gente lo lee, no hace falta una SPA. Si la gente trabaja adentro, probablemente sí.
