- Con la llegada de funciones modernas de CSS como View Transitions API, ya no es necesario usar una arquitectura SPA para lograr transiciones de página fluidas
- La mayoría de los sitios SPA no ofrecen realmente el nivel de rendimiento ni de fluidez que prometían, y más bien el código JavaScript pesado tiende a perjudicar la experiencia de usuario
- En navegadores basados en Chromium, es posible implementar una navegación rápida y natural sin JavaScript usando transiciones de página nativas y Speculation Rules
- La complejidad estructural de las SPA dificulta la optimización del navegador, por lo que para sitios web reales una arquitectura MPA centrada en HTML y CSS resulta más rápida y más fácil de mantener
- En adelante, conviene evitar adoptar SPA innecesariamente y aprovechar CSS moderno y funciones nativas para desarrollar sitios web eficientes y fáciles de mantener
Introducción: el fin de las SPA y la aparición del CSS moderno
- Con la adopción reciente de funciones modernas de CSS como View Transitions API, las principales ventajas que antes ofrecían las SPA (aplicaciones de una sola página) han dejado de ser necesarias
- Aunque muchos equipos de desarrollo siguen eligiendo frameworks SPA como React o Vue, el centro de esa decisión no es el rendimiento, sino una idea equivocada sobre la interacción y la experiencia de navegación fluida
- La práctica de creer que una SPA es indispensable para lograr una navegación fluida ya es una forma de pensar anticuada
La ilusión de las SPA frente a la realidad
- En algún momento, las SPA fueron la única manera de lograr transiciones de página naturales, pero eso ya no es así
- Muchas SPA presentan problemas como los siguientes:
- Solo tienen efectos de desvanecimiento en estados de carga, pero les falta verdadera fluidez en la transición del contenido
- Problemas de restauración del scroll y manejo inconsistente del foco
- Retrasos de navegación por demoras de renderizado/hidratación
- Layout shift y aparición repentina de contenido, además de cargas tipo skeleton
- Complejidad innecesaria y uso excesivo de JavaScript con beneficios mínimos frente al costo en rendimiento
- Frameworks SPA representativos (Next.js, Gatsby, Nuxt, etc.) añaden grandes cantidades de código JS para imitar el comportamiento nativo básico del navegador
- Como resultado, se sacrifica la naturalidad nativa, baja la velocidad y también se perjudica el SEO
La evolución de la plataforma web y el cambio en el rol de CSS
- Los navegadores modernos basados en Chromium (Chrome, Edge, etc.) ya admiten transiciones de página nativas y declarativas
- Con View Transitions API es posible implementar animaciones fluidas entre documentos o entre páginas completas sin usar JavaScript
- Sus capacidades clave incluyen:
- Efectos de desvanecimiento entre páginas (posibles con solo 3 o 4 líneas de CSS)
- Animaciones de elementos compartidos, como una transición natural de una miniatura a una imagen detallada
- Conservación de elementos persistentes como encabezados o barras de navegación
- Al tratarse de URLs reales y navegación entre páginas reales, se maximiza la compatibilidad con SEO, compartir enlaces y caché de atrás/adelante
Cómo aprovechar al máximo la sinergia entre CSS y JS
- Si hace falta, también se puede invocar manualmente una View Transition dentro de la página mediante JS
- Por ejemplo, usando una cantidad mínima de JavaScript para cambios de tema, alternancia de pestañas o modo oscuro
Speculation Rules y navegación instantánea
- Speculation Rules permite que el navegador precargue/prerrenderice páginas por adelantado mientras predice el comportamiento del usuario (por ejemplo, al pasar el cursor), ofreciendo navegación casi instantánea
- Se puede configurar declarativamente mediante
<script type="speculationrules">
- Condición importante: el efecto de máximo rendimiento aparece cuando la página es ligera y está optimizada; si la página es pesada, existe el riesgo de desperdiciar recursos
Respeto por las funciones propias del navegador y bfcache
- bfcache (Back/Forward Cache) restaura al instante una página completa en forma de snapshot cuando el usuario navega hacia atrás o hacia adelante
- Requisito previo: hace falta una arquitectura limpia basada en HTML y CSS puros; no se puede aplicar en estructuras que interceptan el routing como las SPA
- En conclusión, los navegadores modernos están evolucionando para recompensar los sitios web simples y robustos
Comparación de rendimiento entre SPA y MPA
- SPA promedio (tomando Next.js como referencia):
- Tamaño del bundle JS: 1 a 3 MB
- TTI (tiempo hasta estar interactiva): 3.5 a 5 segundos
- Transición de rutas: falsa/simulada
- SEO: complejo, difícil de mantener
- Comportamiento de scroll/anclas: inestable
- MPA moderna (con transiciones CSS y Speculation Rules):
- Bundle JS: 0 KB (solo mejoras opcionales)
- TTI: alrededor de 1 segundo
- Transición de rutas: comportamiento nativo real
- SEO: muy sencillo
- Scroll inteligente, foco e historial: comportamiento nativo del navegador y soporte completo
Diferencia entre sitio web y app, y necesidad de replantear la idoneidad
- La mayoría de los sitios web en realidad no son una “app” y no necesitan estado compartido, routing del cliente ni interacciones complejas
- Para páginas de marketing, portales de documentación, e-commerce, blogs, etc., resulta más adecuada una estructura centrada en HTML, de carga rápida y simple
- Si se adopta una pila SPA en todos los proyectos, puede provocar complejidad excesiva y degradación del rendimiento
- Exigencia de “que se vea como una app”
- Adopción de un framework
- Aumento del routing del cliente y de la complejidad
- Caída de rendimiento y necesidad de optimizaciones adicionales
- Y aun así sigue siendo más lento que una estructura de enlaces nativos + animaciones CSS
Conclusión y recomendaciones
- Las SPA fueron más bien una solución temporal frente a limitaciones de la plataforma en el pasado, pero esas restricciones ya no existen hoy
- Ahora ya es posible aprovechar activamente las siguientes funciones nativas:
- Transiciones reales entre páginas
- Prerrenderizado inmediato mediante Speculation Rules
- Estructuras resistentes a la degradación progresiva
- Marcado limpio, carga rápida y uso de URLs reales
- Una arquitectura que puede recibir al máximo la ayuda de la plataforma
- Si se insiste en una SPA solo por la “fluidez”, se termina pagando el costo en complejidad, rendimiento y mantenibilidad
- Con renderizado del servidor, páginas reales, animaciones basadas en CSS, precarga intencional y JavaScript mínimo, es posible crear sitios web rápidos y agradables para la época actual
- Aprovechando la tecnología disponible en 2025, hay que apuntar a una experiencia web más rápida, más simple y bienvenida para cualquiera
10 comentarios
Para empezar, si la única razón para considerar una SPA era la "suavidad", yo simplemente habría renunciado a esa suavidad y la habría hecho como una MPA, así que la verdad no me genera mucha empatía...
Lo decepcionante de este artículo
Reduce demasiado la verdadera finalidad de un SPA
La View Transitions API es realmente genial, pero eso por sí solo no significa que los SPA dejen de ser necesarios.
Mira todos los sitios web con el mismo criterio
Sitio de marketing ≠ dashboard ≠ app de comercio ≠ herramienta de colaboración en tiempo real
Todos tienen requisitos estructurales distintos.
En la práctica, SPA + SSR + MPA conviven
Los frameworks híbridos como Next.js muestran bien esto.
Los recursos estáticos usan SSG, los dashboards después del inicio de sesión usan CSR/SPA, y para responder a los motores de búsqueda se usa SSR; se necesita una combinación flexible.
Creo que un SPA, más que solo una mejora en la experiencia de usuario, es el resultado de una mejora estructural.
En las páginas donde un SPA no es necesario, MPA + modern CSS puede ser una buena opción, pero los SPA siguen siendo esenciales en términos de estructura, estado, escalabilidad y mantenimiento. Creo que el modern CSS puede "complementar" a los SPA, pero no "reemplazarlos".
De los casos que presentaste, lo único que no se puede reemplazar con cosas como View Transitions son las herramientas de colaboración en tiempo real, pero la gran mayoría de los sitios web no son herramientas de colaboración en tiempo real. Sitios de marketing, dashboards y apps de comercio: todo eso se puede construir excluyendo frameworks SPA y manteniendo condiciones como renderizado del lado del servidor, páginas reales, animaciones basadas en CSS, precarga intencional y adopción mínima de JS. También existe Hotwire, de la comunidad de Rails, que apunta a eso, y además hay casos de producción como Basecamp y Hey. ¿Gestión de estado? A menos que sea algo como una herramienta de colaboración en tiempo real, normalmente basta con métodos del lado del servidor como parámetros de URL o sesiones del servidor, o con
localStorage. También hay casos en los que claramente introducen una SPA solo por las transiciones de página (como el sitio oficial de AGF; incluso con Astro sería suficiente, pero hay casos claros donde metieron React), y no se puede negar que una de las ventajas representativas de las SPA de las que más se habla son precisamente las transiciones de página.Si bien es cierto que los frameworks SPA actuales y la tendencia del frontend basada en ellos necesitan seguir cuidándose de la no estandarización, y que también tienden a provocar sobreingeniería y consumo innecesario de recursos...
También siento que se está viendo el concepto de SPA de una forma demasiado estrecha, pero más aún, me hace dudar si realmente se entiende qué impacto tienen los frameworks SPA en el desarrollo en general.
Decir que con solo la API de View Transitions y algo de CSS ya está todo resuelto significa, dicho de otra manera, que todas las demás funciones que no tienen relación con eso, y los paradigmas necesarios para lograrlas, carecen por completo de sentido; me parece una postura demasiado arrogante.
Eso es un tema aparte de la sobreingeniería que implica crear con React un sitio que apenas reemplaza un folleto.
Estoy de acuerdo en que la mayoría de los proyectos pequeños no necesitan forzosamente un framework SPA, pero en servicios que exigen interacciones complejas y una experiencia de usuario continua, además del mantenimiento y la mejora continua que eso conlleva, no creo que sea así, a pesar de los avances de CSS.
Honestamente, se ve como cuando alguien dice sobre Rust o Haskell, sin siquiera haberlos tocado: "eso no hace falta, hoy en día todo se puede hacer con C++".
Mmm, no estoy tan seguro. ¿No se usan los frameworks SPA más por las interacciones complejas con el usuario que por las transiciones fluidas?
Sin duda hay casos en los que se adopta un framework SPA solo por una interacción fluida. Muchos de los sitios con SPA no necesitan interacciones complejas.
Estoy muy de acuerdo.
Un ejemplo claro es que React en sí mismo también es el Spring del frontend.
Es pesado y complejo; parece que hace el trabajo más conveniente, pero en realidad configura un proceso más complicado para hacer tareas simples, y luego ofrece la extraña comodidad de hacer más llevadero ese proceso que se volvió innecesariamente complejo.
Estoy de acuerdo. A menos que se trate de una web app compleja como Google Docs, creo que con Hotwire, creado por el ecosistema de Rails, es más que suficiente, y para páginas estáticas, Astro también basta.
Comentarios en Hacker News
Los SPA tienen sentido cuando los usuarios pasan sesiones largas dentro de una sola app; es decir, cargas un bundle grande una vez y luego puedes usar la app con solo pequeñas solicitudes de red. Las transiciones suaves son un extra, y no creo que sean el problema esencial que resuelven los SPA. Decir que el routing del lado del cliente existe para las transiciones de página es malentender el propósito de los SPA. Si usaste un SPA bajo esa premisa equivocada, entonces este artículo sí tiene razón, pero los SPA surgieron en la era de jQuery para apps complejas: enormes masas de código jQuery donde cada
divfuncionaba como una miniapp y se sincronizaba con muchas solicitudes pequeñas de red. En navegadores antiguos y con internet lento, eso permitía usarlo de forma eficiente sin recargar todo el código cada vez. Después evolucionó con frameworks como React, que facilitaron el desarrollo estructurado de apps, y la ventaja central del SPA es cachear un bundle grande de una sola vez para usuarios con sesiones largas y luego minimizar el tráfico de red(Cita de la opinión anterior: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Estoy totalmente de acuerdo. El autor es consultor SEO y parece enfocado solo en sitios web de marketing. Las apps reales (no los sitios de marketing) sí pueden beneficiarse muchísimo de un SPA. Por ejemplo, si imaginas Google Maps hecho sin SPA, aunque le agregues animaciones de transición de página, la UX empeoraría gravemente
Se menciona eso de “solo acumulamos espagueti de jQuery”, pero en realidad yo sí apliqué patrones tempranos de diseño en JS como los IIFE para estructurar código, hacer carga diferida de módulos, ofuscación, etc. Y por mi experiencia, AngularJS fue el intento más grande de estructurar el frontend, y también resultaba atractivo para desarrolladores Java por la modularización, la DI y la facilidad de pruebas. Al principio, cuando hacía apps con Backbone, pensaba que la mayoría de la funcionalidad estaría en el backend y no prestaba mucha atención a las pruebas, pero luego al reconstruir con AngularJS terminé teniendo muchas más pruebas en frontend. Claro, hoy me genera rechazo lo verboso, complejo e indirecto del Angular moderno o del código Java
Creo que una conexión de red lenta y un entorno con caché agresiva son una de las razones más fuertes para necesitar SPA, sobre todo en aplicaciones y no tanto en sitios web. Si tienes una conexión decente, puedes bajar todo el frontend una vez, dejarlo en caché, y después usarlo consumiendo el mínimo ancho de banda
Si trabajas en un lugar que usa pipelines modernos de CI/CD, es muy probable que ese bundle grande de JS se reconstruya y la caché se invalide varias veces al día con cada despliegue. HTTP2 ya viene por defecto en navegadores desde hace 10 años, y gracias al multiplexing ya no hay razón para agrupar JS en bundles tan grandes. El enfoque SPA de crear bundles enormes no aprovecha las capacidades modernas del navegador ni del servidor
Me pregunto cuántos casos reales hay donde las solicitudes de red de verdad se vuelvan tan pequeñas después de la carga inicial. La mayoría de los SPA que he visto seguían haciendo llamadas grandes incluso después de cargar, y eran mucho más lentos que simplemente enviar HTML directo. Tampoco se sostiene la idea de que JSON mágicamente se comprime mejor que HTML; HTML también se comprime bastante bien. En la práctica, el argumento de que los SPA son mejores por temas de red se acerca mucho más a propaganda o superstición
Creo que el valor de un SPA no está solo en las transiciones suaves, sino en que puedes manejar la mayor parte del recorrido del usuario del lado del cliente y casi olvidarte del servidor. Por ejemplo, en 2025 todavía me molesta que la mayoría de las tiendas en línea recarguen toda la página y vuelvan a pedir datos cada vez que cambias un filtro o entras a una categoría. Cuando el usuario va y viene entre categorías haciendo varias solicitudes, la UX sería mucho mejor si todo el catálogo se descargara una sola vez al cliente y luego se pudiera filtrar sin comunicarse con el servidor. Claro, se puede objetar que habría demasiados datos, pero en la mayoría de las tiendas una categoría cabe en unos pocos KB y pesa menos que una sola foto de producto. Llevo construyendo apps así desde 2005 y todavía no entiendo por qué esta UX no se usa más ampliamente
En mi opinión, lo más molesto de tener que hacer un full reload no es el tamaño de los datos sino la eficiencia del sitio. Los datos reales son unos pocos KB, pero la página en sí descarga 100MB y el navegador consume 1GB de RAM. Por ejemplo, Hacker News recarga en la mayoría de la navegación y funciona bien incluso en laptops viejas. En cambio, un SPA como DoorDash en el mismo equipo tardó 30 segundos, y completar un pedido real de comida tomó más de 3 minutos. Había que esperar 2.5 minutos solo para que apareciera la interfaz, y aun así casi nada de eso era full reload
Herramientas como HTMX resuelven gran parte de este problema. Siento que el enfoque SPA termina creando dos apps separadas: un frontend y un backend. A mí me parece mejor resolver casi todo del lado del servidor y en el cliente agregar solo efectos interactivos simples (mostrar/ocultar, expandir/colapsar, efectos, etc.). Claro, hay lugares donde un SPA sí es útil
En una experiencia parecida, algunos proyectos personales los alojo en un servidor web estático. En vez de renderizar decenas de miles de páginas individuales, renderizo del lado del cliente en un SPA a partir de un solo archivo JSON. También he usado GitHub Pages. Últimamente estoy probando una estructura que usa un build wasm de una base de datos sqlite para traer solo las páginas necesarias mediante HTTP Range Requests. Full Text Search de sqlite también funciona, pero para búsquedas cortas es una lástima tener que traer toda la tabla, así que quizá sea mejor bajar toda la DB y construir localmente la tabla FTS
También hay ejemplos en contra. Por ejemplo, si haces Shift-clic en la categoría “sci-fi” para abrirla en una pestaña nueva, en un MPA eso funciona casi sin esfuerzo, pero en un SPA hay que manejarlo aparte y es incómodo. Y si no hay links de categoría y solo se puede acceder mediante un
select box, la UX es malaEn general, las empresas no quieren que el usuario descargue el catálogo completo, porque la competencia podría analizarlo fácilmente. Además, en casos como la venta de libros, pueden ser cientos de miles de títulos, y mover todo eso de una vez es ineficiente tanto para la experiencia del usuario como para ancho de banda y memoria
El propósito de un SPA nunca ha sido la transición entre páginas. Casi no existen SPA que implementen bien esas transiciones. Por ejemplo, en Next.js, por cómo funciona la carga de rutas, implementar transiciones de página es casi imposible. Yo mismo intenté agregar una funcionalidad de transición de página decente en Next.js y fue una pesadilla total. Veo dos ventajas claras de los SPA. Primero, la mayoría de las apps quiere cierto grado de interactividad, porque HTML/CSS por sí solos no bastan, y mezclar React con HTML puro es un gran dolor, sobre todo cuando necesitas manejo de estado global. Segundo, si ya cargaste de antemano toda la estructura de la página, la carga posterior de datos es más rápida, y para la UX es mejor mostrar una respuesta inmediata y una pantalla de carga al hacer clic que reaccionar recién 500ms después. Claro, si estamos hablando de menos de 100ms es otra historia. Como no hace falta volver a dibujar la página completa, el rendimiento del frontend no puede ser igualado solo con HTML. Hay casos como Basecamp que han hecho buenas webapps complejas sin SPA, pero basta hacer clic por 30 segundos aquí y allá para ver que no alcanza el rendimiento de un SPA. Me gustaría que la web funcionara más como web, pero aunque Next.js y los SPA agregan complejidad, sí mejoraron la velocidad y capacidad de respuesta de las apps, aunque al mismo tiempo volvieron el desarrollo más incómodo y generaron el problema de bundles grandes. Aun así, no creo que solo con HTML se pueda igualar todavía el rendimiento de un SPA
No sé en qué universo vive este consultor SEO que escribió el artículo. Poner a Next y Nuxt como ejemplos representativos de frameworks opuestos a los SPA está completamente mal. 1. Next prácticamente domina por completo en EE. UU. y Occidente, y cuando la gente habla de una nueva app React normalmente se refiere a Next. En el ecosistema Vue, Nuxt es casi el estándar; Nuxt = el Next del mundo Vue. O sea, la gente está eligiendo casi sin darse cuenta Next y la estrategia MPA. El péndulo se ha ido demasiado hacia MPA, así que más bien habría que recomendar probar un SPA. Los últimos 8 años fueron una fiebre por volver a MPA, y ahora hasta Facebook recomienda oficialmente Next en su documentación en lugar de Create React App. 2. Las quejas sobre la complejidad de Next son quejas sobre la dificultad de la estrategia MPA moderna; el mundo SPA lleva casi 10 años prácticamente congelado. 3. Desarrollar MPA es mucho más difícil que desarrollar SPA, porque hay que respetar mucho más estrictamente la separación entre servidor y cliente. 4. Si en un SPA quieres cargar datos al estilo MPA, eso es elección del desarrollador y debe asumir sus ventajas y desventajas. También puedes precargar los datos y hacer que la navegación dentro del SPA sea instantánea. 5. Además del frontend principal donde el SEO de verdad importa, existen muchos más dashboards internos o apps, y ahí suele haber muchos desarrolladores React, así que es importante no cargar con peso innecesario por la obsesión de ofrecer siempre el primer frame perfecto
Me parece injusto el tono con el que se desprecia a los SPA. Sí requieren más esfuerzo, pero también tienen claramente más ventajas. Durante mucho tiempo, los SPA fueron la única forma de crear una UX que se sintiera como una app. El autor menciona el cansancio hacia las apps, pero si de verdad quieres ofrecer una experiencia de “aplicación”, un SPA es casi la única opción. Comparar un SPA pesado con un sitio web ligero o estático es inapropiado. Si alguien puede hacer un sitio ligero, también puede hacer un SPA ligero. Ya sea un SPA o un sitio web, si se construye de forma ineficiente será lento y pesado igual. Como alguien que ha invertido mucho en SPA, siempre me interesó encontrar una manera de lograr la misma experiencia con menos esfuerzo, pero este artículo se siente más como un poco de maquillaje visual. La política tiene valor, pero no creo que sea lo bastante influyente como para decidir si usar o no SPA
Me parece imposible “hacer linear.app sin un framework SPA”, y la idea de que “las transiciones nativas de CSS mataron la mayor ventaja de los SPA, el client routing” no tiene sentido
Creo que Linear es un caso muy especial incluso entre los SPA. No se trata de prohibir los SPA ni de eliminar por completo JS del navegador. Linear es rápido por su diseño “offline-first”, pero casi ningún servicio está hecho así. Para venta de boletos, foros, noticias, blogs o sitios informativos, creo que desarrollar sobre SSR es mucho mejor. Usar SPA solo donde realmente haga falta, y hacer el resto con SSR rápido de desarrollar y CSS para que se vea como SPA, es mucho más eficiente
No es que los SPA no tengan lugar, pero el otro 99% de los sitios no necesita ser SPA
El objetivo de un SPA no son las view transitions. El texto original sugiere que las transiciones llamativas entre páginas son importantes, y eso es un error. En vez de echarle la culpa al “CMO” o al “brand manager”, habría que iluminar el valor esencial de los SPA. Son un gran framework para la lógica del cliente, para la separación de responsabilidades (lógica de frontend separada del backend), para mejorar la experiencia de desarrollo y acelerar el desarrollo. Creo que se ven muchos textos así porque, como mi comentario, están construidos para generar discusión, pero en realidad no me parece que merezcan tanta atención
Desde mi punto de vista, la promesa principal de un SPA no es la suavidad de las transiciones, sino construir una API de datos y un frontend completamente separados del backend. Por eso no me gusta mezclar SSR y client rendering. Para mí, o es un sitio web o es una app
También me queda la duda de “¿cuál es el criterio para llamar algo SPA o MPA?”. Mi sitio personal basado en Next.js en la práctica renderiza casi todo del lado del servidor. Técnicamente es un SPA, pero si activas JS funcionan RSC y la navegación del lado del cliente, y si desactivas JS, los componentes exclusivos de cliente (por ejemplo, un generador de códigos QR) muestran contenido alternativo y el resto se renderiza por SSR completamente; se siente un poco más lento, pero funciona bien. Es mucho más trabajoso no renderizar componentes desde el servidor. El progressive enhancement es lo mejor
Window loadde la appTambién me frustra muchísimo que la industria SEO o desarrolladores web junior que entraron después de la pandemia sigan malentendiendo y menospreciando los SPA. Desde la perspectiva de alguien que desarrolla desde los 2000, el verdadero origen de los SPA no fue esa “promesa falsa” del artículo, sino la necesidad de separar por completo frontend y backend a medida que se expandía la estrategia mobile-first a finales de los 2000 y comienzos de los 2010. Antes de eso, el frontend normalmente era HTML renderizado por templates del servidor con un poco de jQuery por encima, pero luego tanto apps móviles como de escritorio tenían que compartir la misma lógica de negocio y la misma DB, así que se volvió tendencia releer la arquitectura REST y los textos de Roy Fielding, adoptar arquitectura orientada a servicios y exponer APIs hacia afuera. También había motivos de optimización de costos. Durante ese periodo, frameworks web full-stack como Ruby on Rails o Django pasaron por un pequeño bajón. Con el ascenso de Node.js, y a medida que navegadores y móviles se volvían más potentes, fue posible mover mucha lógica de negocio hacia los “edge devices”, es decir, hacia el cliente. Ese es precisamente el punto central de los SPA. No creo que CSS pueda reemplazar esa necesidad