Aplicación de una sola página (SPA): definición y compromisos

¿Qué es una aplicación de una sola página (SPA)?

Una aplicación de una sola página (SPA, por single page application) carga un único documento web y después actualiza su contenido con JavaScript, normalmente pidiendo datos a una API, en lugar de solicitar al servidor una página HTML nueva en cada clic. La barra de direcciones sigue cambiando y el botón de retroceso sigue funcionando, porque la propia aplicación gestiona la URL. MDN la define igual y señala los costes: el SEO, el estado, la navegación y la monitorización del rendimiento exigen más trabajo que en un sitio clásico de varias páginas.

Cómo funciona una SPA

1. El navegador pide la página y el servidor devuelve una pequeña estructura HTML con referencias a paquetes de JavaScript.
2. El navegador descarga y ejecuta los paquetes, y el framework dibuja la primera vista en el navegador. Es el renderizado en el cliente.
3. Un enrutador del lado del cliente intercepta el clic en un enlace, actualiza la URL con la History API y dibuja la siguiente vista sin pedir un documento nuevo.
4. Cada vista obtiene los datos que necesita de tu backend, normalmente JSON sobre HTTP.

Así, la primera carga paga la descarga y ejecución de la aplicación, y cada navegación posterior es solo una llamada a la API más un renderizado.

SPA frente a aplicación de varias páginas (MPA)

Hoy la frontera es difusa. Frameworks como Next.js renderizan primero en el servidor y luego se hidratan hasta convertirse en SPA en el navegador, de modo que un sitio puede tener ambas cosas.

SPA y SEO

Google renderiza JavaScript con un Chromium sin interfaz, pero lo hace en un paso aparte tras el rastreo, y solo puede seguir enlaces que sean elementos <a href> reales. Las nociones básicas de SEO con JavaScript de Google indican que el renderizado en el servidor o el prerrenderizado siguen siendo buena idea, porque es más rápido para los usuarios y no todos los rastreadores ejecutan JavaScript. Tres puntos prácticos de esa guía:

• Usa rutas reales con la History API, no rutas con #/fragmento.
• Una aplicación con enrutado en el cliente no puede enviar por sí sola un estado 404 real para una página inexistente. Redirige a una URL que devuelva 404 o añade una etiqueta robots noindex, para que las páginas inexistentes no se indexen como soft 404.
• No bloquees tus archivos JavaScript en robots.txt.

Ejemplo

Una herramienta de gestión de proyectos es una SPA típica. Tras iniciar sesión, el usuario abre un tablero, arrastra una tarjeta y edita un comentario, y cada acción llama a una API sin recargar la página. El sitio de marketing del mismo producto es un mal candidato para SPA: necesita un primer pintado rápido y texto rastreable, y encaja mejor como HTML estático o renderizado en el servidor.

Errores frecuentes

• Un único paquete enorme. Enviar todas las rutas de entrada retrasa la primera vista. Divide el código por rutas y carga los componentes pesados con carga diferida.
• Hacer las páginas de marketing como SPA pura. Los rastreadores y los dispositivos lentos reciben primero una estructura vacía.
• Historial roto. Las vistas sin URL propia rompen el botón de retroceso, los marcadores y el compartir.
• Sin estados de carga ni de error. Una pantalla en blanco mientras cargan los datos parece rota. Usa esqueletos y límites de error para que un componente que falla no tumbe la aplicación.
• Medir solo la primera carga. En una SPA la mayor parte de la experiencia ocurre tras navegar, algo que una prueba de página puntual no muestra.

Probar y monitorizar una SPA

Una SPA traslada trabajo al navegador y convierte tu backend en una API, así que conviene probar ambas mitades.

• Velocidad de renderizado: sigue el Largest Contentful Paint y el resto de Core Web Vitals. La monitorización de velocidad de página de LoadFocus ejecuta Lighthouse desde ubicaciones en la nube de forma programada, y la monitorización de usuarios reales muestra lo que viven los visitantes en las navegaciones del lado del cliente.
• Capacidad de la API: cada vista es una llamada a la API, así que un pico de tráfico cae sobre tu backend. Las pruebas de carga de LoadFocus ejecutan scripts de JMeter y k6 desde más de 25 regiones en la nube. Estas herramientas trabajan a nivel de protocolo y no ejecutan el JavaScript de tu frontend, así que miden las API que llama la SPA, no el renderizado en el navegador.

Para un enfoque paso a paso, lee cómo optimizar las pruebas de carga para aplicaciones de una sola página (en inglés).

Preguntas frecuentes: aplicación de una sola página

¿Son malas las SPA para el SEO?

No por definición, pero una SPA renderizada solo en el cliente entrega a los rastreadores una estructura vacía hasta que se ejecuta JavaScript. El renderizado en el servidor o el prerrenderizado, las URL reales y los códigos de estado correctos eliminan casi todo el riesgo.

¿Indexa Google las SPA?

Sí. Google ejecuta JavaScript con un Chromium sin interfaz antes de indexar. El renderizado es un paso aparte, así que el contenido que debe indexarse pronto está más seguro en el HTML inicial.

¿Qué diferencia hay entre una SPA y el renderizado en el cliente?

El renderizado en el cliente describe cómo se dibuja el contenido: en el navegador, con JavaScript. Una SPA es un estilo de aplicación con un documento y navegación en el cliente. La mayoría de las SPA usan renderizado en el cliente, pero una aplicación que se renderiza primero en el servidor y luego asume la navegación en el navegador también es una SPA.

¿Qué diferencia hay entre una SPA y una PWA?

Una aplicación web progresiva añade a una aplicación web la posibilidad de instalarla, funcionar sin conexión y usar service workers. Muchas PWA son SPA, pero una SPA no es automáticamente una PWA.

¿Cuándo no conviene construir una SPA?

En sitios centrados en contenido, como blogs, documentación y páginas de marketing, donde importan sobre todo el primer pintado rápido y la visibilidad en buscadores. Ahí encajan mejor las páginas estáticas o renderizadas en el servidor.