El problema que Astro resuelve

La SPA: la aplicación entera, en el cliente

Una Single Page Application traslada el renderizado al navegador. El servidor entrega un HTML casi vacío —un contenedor— acompañado de un bundle que contiene el framework, el router, el árbol de componentes y toda la lógica. El navegador descarga ese bundle, lo analiza, lo compila y lo ejecuta antes de poder pintar nada útil.

Mira dónde corre cada línea de la entrada de una SPA de contenido. Todo lo naranja se descarga y se ejecuta en el dispositivo del lector; nada de ello estaba obligado a hacerlo.

El usuario mira una página en blanco hasta que ese bundle termina de ejecutarse. En una conexión lenta o un móvil de gama baja, esa espera es medible. Y el proceso es estrictamente secuencial: el navegador no puede pedir el JS hasta leer el HTML, no puede ejecutarlo hasta descargarlo, y no puede pintar hasta ejecutarlo.

La hidratación: el impuesto oculto

El renderizado en servidor —SSR o SSG— mejora la primera pintura: el servidor manda HTML ya formado y el usuario ve contenido pronto. Pero ese HTML es inerte: botones que no responden, menús muertos. Para hacerlo interactivo, el framework vuelve a ejecutar en el cliente el mismo árbol de componentes, reconstruye su estado y engancha los manejadores de eventos al DOM existente. Ese proceso se llama hidratación.

Dos métricas capturan el daño con precisión:

• TTI (Time to Interactive): cuándo la página responde de verdad. La hidratación lo empuja hacia adelante.
• TBT (Total Blocking Time): cuánto tiempo estuvo bloqueado el hilo principal. Cada tarea larga de hidratación suma milisegundos que el usuario percibe como lag.

Ambas pesan en Core Web Vitals y, con ello, en el posicionamiento. Hay además un coste que no aparece en ninguna métrica: la fragilidad. Si el JavaScript falla —un error suelto, una red que cae a medias—, una SPA se queda en blanco, porque el contenido dependía de él para existir. Un documento HTML se ve igual aunque el JS no llegue nunca.

La anatomía del desperdicio

No todo el peso es igual. Un byte de JavaScript es mucho más caro que un byte de imagen: la imagen se decodifica en hilos secundarios y hardware dedicado; el JavaScript hay que analizarlo, compilarlo a bytecode y ejecutarlo en el hilo principal.

• Una imagen se decodifica en hilos aparte y con hardware dedicado.
• El CSS puede retrasar la pintura, pero no bloquea la interactividad.
• El JavaScript hay que descargarlo, analizarlo, compilarlo y ejecutarlo, y todo eso ocurre en el hilo principal.

// El "waterfall" tipico de una SPA de contenido// 1. GET /            -> HTML de 2 KB (un div vacio)// 2. GET /index.js    -> 180 KB de framework mas app// 3. parse y compile  -> unos 250 ms de CPU en un movil medio// 4. execute y render -> construye el DOM que el HTML ya podria traer// 5. hydrate          -> reengancha listeners y dispara el TBT// Resultado: el usuario ve el texto tarde y lo puede tocar aun mas tarde

El reparto de ese coste es desigual: tú desarrollas en un portátil potente con fibra, pero buena parte de tu audiencia navega desde móviles modestos y redes irregulares. Lo que a ti te parece instantáneo puede costarle segundos a quien te lee.

El mismo contenido, como documento

Este es el mismo artículo escrito como página de Astro. No cambia lo que el lector ve: cambia dónde corre cada línea. Compara los colores con el bloque de arriba —aquí no hay nada naranja, porque no hay nada que descargar.

Cero JavaScript descargado, cero hidratación, cero TBT. El navegador recibe el artículo ya escrito y su único trabajo es pintarlo.

Aplicación o documento: la pregunta correcta

Aquí está el nudo. Una aplicación —un editor, un dashboard, una hoja de cálculo— es interactiva de arriba abajo: el coste de la SPA se justifica. Un sitio de contenido no. En un blog, en unas docs o en un landing, casi toda la página es texto, imágenes y enlaces —contenido que el HTML sabe representar sin una sola línea de JavaScript—. La interactividad, si la hay, es local: un buscador, un carrusel, un menú.

Tres criterios separan un caso del otro sin ambigüedad:

• Es aplicación si hay estado por todas partes e interacción constante: un dashboard, un editor de texto, un cliente de correo.
• Es contenido si se lee de arriba abajo y la interacción es puntual: un artículo, una guía, una ficha de producto.
• La prueba del papel: si pudieras imprimir la página y seguiría teniendo sentido, es contenido. Si al imprimirla lo pierde todo, es aplicación.

Casi toda web real es sobre todo contenido con algo de aplicación. El error caro es tratar ese “algo” como si fuera el todo.