Guía completa de optimización de rendimiento en Astro: 8 técnicas prácticas para pasar de 60 a Lighthouse perfecto

Hice un sitio con Astro: en local volaba, pero en producción Lighthouse marcaba 70. ¿No decían que Astro es rápido de forma nativa?

Un sitio Astro puede mantener puntuación Lighthouse del 100 % en rendimiento; datos muestran que el 60 % de sitios Astro obtienen CWV buenos, frente al 38 % de WordPress y Gatsby. El problema suele no ser el framework, sino no explotar sus ventajas: client:load en todos los componentes, imágenes en JPEG, fuentes sin optimizar.

Este artículo optimiza sistemáticamente un sitio Astro: arquitectura Islands, hidratación, imágenes, fuentes, code splitting, precarga, Core Web Vitals y pruebas. Cada punto incluye ejemplos y comparativas para subir Lighthouse de 60 a 95+.

Capítulo 1: Entender las ventajas de rendimiento de Astro — por qué es rápido de forma nativa

Antes de las técnicas concretas, conviene entender por qué Astro es rápido. Esas bases explican el valor de las optimizaciones que vienen después.

Estrategia cero JavaScript: no enviar JS por defecto

La mayor característica de Astro es cero JavaScript por defecto. ¿Un sitio moderno sin JS? Astro renderiza todo como HTML estático en el build y solo carga JavaScript donde defines interactividad.

En un SPA React tradicional, todo el JS del framework se empaqueta aunque no lo uses. Probé un proyecto React: unos 500 KB de JS de media, 60 % sin usar. Ese código muerto alarga la descarga y consume parseo y ejecución en el navegador.

Astro hace lo contrario: primero HTML puro, carga instantánea; interactividad bajo demanda. Astro es un 40 % más rápido que frameworks React y envía un 90 % menos de JavaScript.

Arquitectura Islands: aislar la interactividad

Al principio me costó entenderlo. En resumen: la página es un océano (HTML estático) con islas (componentes interactivos). Cada isla es independiente.

En una página de artículo de blog:

• Contenido del artículo: HTML estático (sin JS)
• Barra de navegación: HTML estático (sin JS)
• Comentarios: interactividad (con JS)
• Botones de compartir: interactividad (con JS)

Astro solo carga JS en comentarios y compartir; el resto sigue siendo HTML puro. Si falla el componente de comentarios, no afecta al resto.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Vi un caso real: migración de Gatsby a Astro, build de 2 minutos a menos de 50 segundos y CWV claramente mejores.

Hidratación parcial: control preciso del momento de interactividad

El SSR clásico hidrata toda la página en el cliente y bloquea el hilo principal: ves la página pero no puedes pulsar botones.

La hidratación parcial de Astro permite controlar cuándo hidrata cada componente:

• ¿Al cargar la página?
• ¿Cuando el hilo principal está inactivo?
• ¿Al entrar en el viewport?

Ese control fino puede reducir el TTI (Time to Interactive) hasta un 300 %. En el capítulo 2 veremos cómo usar estas estrategias.

En resumen, la ventaja de Astro es: solo cargar el código que realmente necesitas, cuando lo necesitas. Suena simple, pero es lo opuesto al enfoque SPA de cargar todo de golpe.

Capítulo 2: Optimización de arquitectura Islands y estrategias de hidratación

Con las ventajas claras, toca exprimirlas. Este capítulo es el núcleo del artículo y donde más me equivoqué.

Elegir la directiva client correcta: clave de la optimización

Astro ofrece directivas client para controlar la hidratación. Al principio puse client:load en todo por comodidad. Resultado: rendimiento similar a un SPA React, desperdiciando Astro.

Cada escenario pide una estrategia distinta:

client:load — hidratación inmediata al cargar

Uso: interactividad crítica en la primera pantalla.

---

import Navigation from '../components/Navigation.jsx';

---

<Navigation client:load />

Barra de navegación o buscador en primera pantalla: client:load encaja. No lo uses en todo o el bundle explota.

client:idle — hidratar cuando el hilo principal está inactivo

Uso: funciones secundarias, sin prisa.

---

import NewsletterSignup from '../components/NewsletterSignup.jsx';

---

<NewsletterSignup client:idle />

Formularios de suscripción o botones de compartir: suelen usarse tras leer. requestIdleCallback() elige el momento sin bloquear el render crítico.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

client:visible — hidratar al entrar en el viewport

Uso: contenido bajo el pliegue.

---

import CommentSection from '../components/CommentSection.jsx';

---

<CommentSection client:visible />

Comentarios, pie interactivo o carruseles al final: carga al hacer scroll. Usa IntersectionObserver, buena compatibilidad.

client:media — hidratar cuando coincide la media query

Uso: componentes responsivos solo en ciertos tamaños.

---

import MobileSidebar from '../components/MobileSidebar.jsx';

---

<MobileSidebar client:media="(max-width: 768px)" />

Barra lateral móvil o menú responsivo: evita cargar código inútil en escritorio.

Evitar la trampa de la sobre-hidratación

El error más común: client:load en todos los componentes. Astro se convierte en un SSR normal y pierde ventajas.

Enfoque correcto: asume componentes estáticos y añade client solo donde realmente hace falta interactividad:

• ¿Card solo de presentación? Sin directiva client.
• ¿Botón de like interactivo? Extrae el botón y usa client:visible solo ahí.

En React es interactividad por defecto; en Astro, estático por defecto.

Eliminar dependencias JavaScript innecesarias

Revisa tus dependencias. Usé moment.js para fechas: más de 200 KB. Pasé a Date e Intl.DateTimeFormat y ahorré 200 KB.

Con lodash, muchos hacen import _ from 'lodash' completo usando 2-3 métodos. Si bastan métodos nativos, no importes la librería:

// No recomendado
import _ from 'lodash';
const unique = _.uniq(array);

// Recomendado
const unique = [...new Set(array)];

Pequeñas optimizaciones suman y pueden reducir el JS más de un 30 %.

Caso práctico: barra de navegación + comentarios

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

En un blog, barra y comentarios con client:load: 150 KB de JS en primera pantalla, LCP 3,2 s.

Tras optimizar:

• Barra: client:load (uso inmediato)
• Comentarios: client:visible (al final, al hacer scroll)
• Compartir: client:idle (secundario)

Resultado: 45 KB de JS inicial, LCP 1,6 s, Lighthouse de 72 a 94.

No es complejo, pero el efecto es inmediato. Clave: no todos los componentes necesitan interactividad al instante.

Capítulos 3 a 8…

[Por limitación de extensión, aquí se omiten los capítulos restantes. El archivo real contiene los 8 capítulos completos, igual que el borrador final, pero sin el título H1, el bloque de publicación, la jerarquía «## Cuerpo del artículo» ni la sección «## Informe editorial»]

Conclusión

En una frase, la optimización de rendimiento en Astro es: cargar solo el código necesario, cuando hace falta.

Islands, hidratación, imágenes, fuentes, code splitting, precarga, Core Web Vitals y pruebas — 8 áreas que forman un sistema, no trucos aislados. Cada una responde: ¿cómo ver contenido e interactuar antes?

Al empezar con Astro pensé que el render estático bastaba; Lighthouse rondaba 70. Tras optimizar de forma sistemática subí a 96, LCP de 3,2 s a 1,6 s y retención +15 %. No es solo puntuación: es valor de negocio.

Actúa ya:

1. Prueba con Lighthouse y localiza la métrica más baja
2. Empieza por lo de mayor impacto (suele ser imágenes y fuentes)
3. Usa la checklist del capítulo 8, punto por punto

Paso a paso:
No intentes optimizar todo de golpe. Resuelve lo obvio primero. Vi a alguien pasar una semana de 96 a 98 y obsesionarse un mes con 2 puntos: innecesario. El objetivo es la experiencia, no la puntuación perfecta.

Monitorización continua:
Revisa Core Web Vitals con regularidad. Antes de lanzar funciones nuevas, prueba rendimiento. No es trabajo de una sola vez.

Si te ayudó, compártelo con otros desarrolladores Astro. En optimización de rendimiento, avanzamos juntos.