Webs rápidas con Astro: islands, 0 JS y Core Web Vitals

La mayoría de webs no son lentas porque el servidor tarde, sino porque el navegador del usuario tiene que descargar, parsear y ejecutar megabytes de JavaScript antes de poder hacer nada útil. Llevas un framework SPA para pintar una landing que es, en esencia, texto e imágenes. Pagas el coste de la hidratación completa para tener tres botones interactivos. Ese es el problema que Astro resuelve de raíz, y es la razón por la que construí este mismo portfolio con él.

En este artículo te cuento cómo se hacen webs rápidas con Astro sin trucos: la arquitectura de islands, el principio de 0 JS por defecto, la purga de CSS y cómo todo eso aterriza en métricas reales de Core Web Vitals. Spoiler: no es magia, es decidir qué se ejecuta en el cliente y qué no.

El coste real del JavaScript

Antes de hablar de Astro conviene entender qué pagas con un enfoque SPA tradicional. Cuando sirves una app de React o Next.js en modo cliente, el flujo es:

1. El navegador descarga el HTML (a menudo casi vacío).
2. Descarga el bundle de JavaScript.
3. Lo parsea y ejecuta.
4. React reconstruye el DOM y rehidrata cada componente para reconectar los eventos.
5. Recién entonces la página responde al usuario.

Los pasos 2 a 5 son tiempo en el que el usuario ve algo en pantalla pero no puede interactuar. En un móvil de gama media —que es el dispositivo real de buena parte de tu tráfico— esa hidratación se nota. Y aquí está el matiz que casi nadie menciona: la mayor parte de ese JavaScript reconstruye una interfaz que ya estaba lista en el HTML. Es trabajo duplicado.

0 JS por defecto: la decisión de diseño que lo cambia todo

Astro invierte la pregunta. En lugar de “¿cómo hidrato toda la app?”, pregunta “¿qué partes necesitan JavaScript de verdad?”. Por defecto, un componente Astro se renderiza a HTML estático y no envía ni un byte de JS al cliente. Tu maquetación, tus secciones, tu contenido: HTML y CSS, como debe ser.

Esto no es una limitación, es el caso correcto por defecto. Una sección “Sobre mí” no necesita un runtime de 40 KB para mostrar un párrafo. Cuando sí necesitas interactividad —un formulario, un terminal, un conmutador de tema— la añades de forma explícita y aislada. A eso se le llama arquitectura de islands.

Arquitectura de islands: hidratar solo lo que respira

Una island es un componente interactivo (React, Preact, Svelte, Vue…) embebido en un mar de HTML estático. Cada island se hidrata de forma independiente y bajo demanda, sin arrastrar al resto de la página. Astro te da control fino sobre cuándo ocurre esa hidratación mediante directivas:

<!-- Se hidrata en cuanto el navegador está libre -->
<ThemeToggle client:idle />

<!-- Se hidrata solo cuando entra en el viewport -->
<AiTerminal client:visible />

<!-- No se hidrata nunca: HTML puro -->
<About />

La diferencia entre client:idle y client:visible parece menor, pero es exactamente la palanca que decide tu rendimiento. En este portfolio aplico una estrategia por coste:

• Islands pesadas y por debajo del fold (el terminal de IA, el formulario de contacto) usan client:visible. Su JavaScript no se descarga hasta que el usuario hace scroll y las ve. Si nunca llegan, nunca pagan.
• Islands ligeras (el conmutador de tema, el botón de “volver arriba”) usan client:idle. Se cargan cuando el hilo principal está ocioso, sin competir con el renderizado inicial.

Solo hay cuatro islands en todo el sitio. El resto —el 90% del DOM— es HTML que el navegador pinta sin ejecutar nada. Esa es la base de una web rápida: no es que el JavaScript sea eficiente, es que la mayor parte ni existe en el cliente.

Preact en lugar de React cuando el peso importa

React 19 es excelente, pero su runtime pesa. Cuando una island es trivial —un par de estados, sin librerías de ecosistema— Astro permite cambiar a Preact, una alternativa con la misma API y una fracción del tamaño (unos 3 KB frente a las decenas de React). Para un conmutador de tema o un contador, la diferencia de bundle es brutal y el usuario no nota ningún cambio funcional. La regla práctica: usa React cuando necesites su ecosistema; usa Preact cuando solo necesites reactividad ligera.

CSS: enviar solo lo que se usa

El otro gran lastre invisible es el CSS. Frameworks de utilidades como Tailwind pueden generar miles de clases, pero tu página usa una mínima parte. La clave es la purga: en producción, el compilador escanea tu markup y elimina toda clase que no aparezca, dejando una hoja de estilos diminuta.

En este portfolio uso Tailwind CSS 4 + DaisyUI 5 definidos CSS-first, y Astro además inyecta el CSS crítico inline y divide el resto por ruta. El resultado es que cada página carga solo los estilos que necesita, sin un único bundle.css monolítico que arrastras a todas partes. Menos CSS que descargar y parsear se traduce directamente en un primer pintado más rápido.

Core Web Vitals: dónde se cobra todo esto

Las decisiones anteriores no son estética de ingeniero: se miden. Google evalúa la experiencia con los Core Web Vitals, y cada uno mapea a algo concreto que Astro ataca:

• LCP (Largest Contentful Paint) — cuánto tarda en aparecer el elemento principal. Con HTML servido directamente y sin esperar a la hidratación, el contenido se pinta antes. Sumado a imágenes en WebP optimizado y loading="lazy" para lo que está bajo el fold, el LCP baja sin esfuerzo.
• INP (Interaction to Next Paint) — cuánto tarda la página en responder a un clic o un toque. Como el hilo principal no está saturado hidratando toda la app, queda libre para responder. Menos JavaScript ejecutándose = interacciones más ágiles.
• CLS (Cumulative Layout Shift) — cuánto “salta” el layout. Se controla reservando dimensiones de imágenes y fuentes. Cargo Geist Variable y Geist Mono de forma autoalojada para evitar el parpadeo de fuentes y el reflow asociado.

Un detalle que cuido especialmente: el tema sin parpadeo. El modo claro/oscuro lo fija un pequeño script inline en el <head>, antes del primer pintado. Así el usuario nunca ve un destello de tema incorrecto, un fallo de CLS sutil pero molesto que arrastran muchos sitios con conmutador de tema.

Una técnica concreta: el cómputo pesado fuera del hilo principal

Cuando una interacción sí requiere trabajo costoso, la respuesta no es “menos features”, sino mover ese cómputo donde no bloquee la UI. En CV Finder AI calculo embeddings vectoriales de currículums dentro del navegador, y para que la interfaz no se congele ese cálculo corre en Web Workers dedicados. El hilo principal queda libre, el INP no se resiente y la página sigue respondiendo mientras procesa en segundo plano. Es la misma filosofía de Astro —no bloquees el hilo principal— aplicada a la lógica de aplicación.

Por qué esto importa para SEO y conversión

Aquí está la parte que interesa a quien paga la web, no solo a quien la programa. Los Core Web Vitals son señal de ranking en Google: dos páginas con contenido equivalente, la más rápida posiciona mejor. Pero el efecto más directo está en la conversión. Cada décima de segundo de espera erosiona la intención del usuario; una página que responde al instante retiene, una que se arrastra pierde visitas antes de cargar.

Una web rápida con Astro no es un capricho técnico: es menos rebote, mejor posicionamiento y más conversiones por la misma inversión en contenido y diseño. El rendimiento es una feature de negocio que se disfraza de detalle de ingeniería.

Cuándo Astro es la elección correcta (y cuándo no)

Honestamente, Astro no es la herramienta para todo. Brilla en lo que es predominantemente contenido con islas de interactividad: portfolios, blogs, landings, documentación, e-commerce, sitios de marketing. Para una aplicación con estado denso y muchas vistas interactivas —un dashboard en tiempo real, un editor— el modelo de SPA con React o Next sigue teniendo sentido, y de hecho así construí DevFlow AI y el dashboard de monitorización. La habilidad no está en casarse con un framework, sino en elegir el modelo de renderizado adecuado para cada problema. Astro y Next no compiten: resuelven cosas distintas.

Lo que me llevo

Construir webs rápidas con Astro no consiste en optimizar al final, sino en decidir desde el principio qué se ejecuta en el cliente. 0 JS por defecto, islands hidratadas con cabeza, CSS purgado y un ojo permanente en LCP e INP. El resultado es una web que carga rápido en el móvil real de tu usuario, posiciona mejor y convierte más, sin sacrificar la interactividad donde de verdad hace falta.

Si tienes un proyecto donde la velocidad de carga te está costando tráfico o conversiones —o quieres una web que pase los Core Web Vitals sin parches— hablémoslo. Es justo el tipo de problema en el que disfruto poniéndome.