Definición
Una SPA (Single Page Application) es una web que carga un solo documento HTML y, a partir de ahí, gestiona toda la navegación con JavaScript: cuando pulsas un enlace, no se pide una página nueva al servidor, sino que el código sustituye el contenido del DOM y cambia la dirección de la barra sin recargar.
La web tradicional funciona al revés: cada enlace es una petición nueva y el servidor devuelve un documento completo.
La ventaja evidente es la fluidez: no hay parpadeo blanco entre páginas y el estado de la aplicación —lo que llevas escrito, el carrito, la sesión— se conserva. La desventaja es que todo el peso se traslada al navegador del visitante.
Cómo funciona
- La primera petición devuelve un HTML casi vacío, muchas veces solo
<div id="root"></div>, más un paquete de JavaScript. - El JavaScript arranca y pinta la interfaz.
- Al navegar, un enrutador de cliente intercepta los clics, evita la recarga, cambia la dirección con la API de historial del navegador y pinta la vista nueva.
- Los datos se piden por API y llegan en JSON.
Ese punto 1 es el origen de casi todos los problemas: hasta que el JavaScript no se ejecuta, no hay contenido. Si tarda, el visitante ve una pantalla en blanco. Y si es un buscador el que entra, puede no ver nada en absoluto.
Ejemplo práctico
La web de IMDICA es una SPA, y eso condiciona el trabajo diario de una forma muy concreta.
El detalle que hay que conocer sí o sí: el enrutador intercepta todos los enlaces internos que empiezan por barra. Cuando quieres un botón que haga otra cosa —abrir un panel, disparar una acción—, no puedes usar un <a href="/algo">, porque el enrutador se lo lleva. Hay que usar un <button>. Es de esas cosas que cuestan una tarde la primera vez y cinco segundos a partir de la segunda.
El otro efecto, más serio, es al depurar: como el servidor devuelve el mismo documento para cualquier ruta, probar direcciones a mano engaña. Pedir /panel/ da un 200 aunque esa ruta no exista, y pedir /panel/algo.php da un 404 aunque la sección sí exista. Los códigos de estado dejan de decirte la verdad sobre qué hay y qué no.
Frente a eso, esta web personal no es una SPA: son 107 páginas HTML de verdad, generadas al compilar. Cada término del diccionario es un fichero real que existe en el servidor. Para contenido que tiene que posicionar en Google, es la decisión correcta.
Los problemas que hay que asumir
- SEO. Google ejecuta JavaScript, pero no siempre, no de inmediato y con presupuesto limitado. Otros buscadores y los previsualizadores de enlaces de WhatsApp o LinkedIn, mucho menos.
- Primera carga lenta. Descargar y ejecutar un paquete grande antes de ver nada penaliza el LCP, sobre todo en móvil.
- Accesibilidad. Al cambiar de vista sin recargar, un lector de pantalla no se entera. Hay que gestionar el foco y anunciar el cambio a mano.
- Memoria. Como la página nunca se recarga, los escuchadores de eventos que no se limpian se acumulan.
- El botón atrás. Funciona solo si el enrutador está bien hecho.
Alternativas
- SSR: el servidor devuelve el HTML ya montado y luego JavaScript lo "despierta". Une lo bueno de ambos.
- SSG: las páginas se generan al compilar. Lo más rápido y lo mejor para SEO.
- Web tradicional: recargar en cada navegación. Sigue siendo perfectamente válido para muchísimas cosas.
Cuándo usarla
Sí en aplicaciones detrás de un login, donde el SEO no importa y el usuario pasa mucho rato: paneles de gestión, editores, cuadros de mando, herramientas internas. Ahí la fluidez gana claramente.
No en webs de contenido, blogs, tiendas o cualquier cosa que tenga que salir en Google. Ahí el coste en posicionamiento y en primera carga no compensa.
La respuesta moderna suele ser mixta: la parte pública generada como HTML y la parte privada como aplicación. Es exactamente el reparto que uso entre esta web y el CRM de IMDICA.
