Partial Hydration en Astro y comparación con Next.js

⚡ Partial Hydration en Astro y cómo se diferencia de Next.js

En los últimos años, los frameworks de frontend han encontrado soluciones cada vez más creativas para mejorar la performance de las aplicaciones web. Uno de los conceptos más importantes en esta evolución es hydration.

Hoy te quiero contar cómo Astro implementa una técnica llamada partial hydration, qué resuelve exactamente y cómo se diferencia de frameworks como Next.js que manejan hydration de una forma más tradicional.

📖 ¿Qué es Hydration?

Cuando generas una web con renderizado en servidor (SSR) o generación estática (SSG), el navegador recibe HTML ya renderizado. Pero ese HTML es estático, y para que los componentes sean interactivos, se necesita asociarles el comportamiento JavaScript que se definió en el cliente.

Ese proceso se llama hydration.

Proceso clásico:

El servidor renderiza el HTML.
El cliente recibe ese HTML.
Se descarga y ejecuta el bundle JS.
El framework recorre el DOM, rehidrata los componentes y los vuelve interactivos.

Problema: se hidrata todo, incluso lo que no es necesario.

🚀 ¿Qué es Partial Hydration?

Es una optimización que hidrata solo las partes interactivas de una página — los islands — dejando el resto como HTML estático.

Ventaja: ✅ Menos JS que descargar y ejecutar. ✅ Mayor performance inicial. ✅ Mejora en Core Web Vitals.

🌌 Astro y su enfoque “Islands Architecture”

Astro usa este modelo desde su núcleo. Genera HTML estático para toda la página, y solo hidrata los componentes que realmente lo necesitan.

Ejemplo:

---
import Counter from '../components/Counter.jsx';
---

<html>
  <body>
    <h1>Blog Post</h1>
    <Counter client:load />
  </body>
</html>

client:load indica que ese componente se hidratará al cargarse la página.

Astro permite varios modos de carga:

client:load → al cargar la página.
client:idle → cuando el navegador está en idle.
client:visible → cuando entra en viewport.
client:media → según media queries.

👉 Esto permite tener control fino sobre cuándo y cómo se hidrata cada componente.

🔍 ¿Cómo se diferencia de Next.js?

Next.js usa hydration completa por defecto. Toda la página generada en SSR/SSG se hidrata en cliente al cargar el bundle.

Aunque Next.js ha mejorado con React Server Components (RSC), sigue basándose en hydration completa o parcial controlada con dynamic imports o use client.

Ejemplo en Next.js:

'use client';

export default function Counter() {
  // Componente que solo vive en cliente
}

Pero:

No tiene granularidad por componente aislado con control de hydration progresiva.
No aplica islands architecture como modelo de diseño.

📊 Comparativa rápida

📌 Concepto	Astro	Next.js
Hydration Default	Partial per-component (islands)	Full hydration
Control por carga	`client:load`, `client:idle`, etc.	`use client`, dynamic imports
HTML inicial	100% estático (salvo islands)	HTML con hydration JS global
Ideal para	Blogs, landing pages, e-commerce	SPAs, dashboards, apps complejas
React Server Components	En roadmap	Implementado desde Next 13

📚 Referencias

📖 Islands Architecture explicado

🎯 Conclusión

Astro propone una solución moderna a los problemas de hydration: hidratar solo lo necesario, cuando es necesario. Esto reduce el JS en cliente, mejora la performance y hace que las webs sean más rápidas desde su primer render.

Mientras Next.js sigue evolucionando con React Server Components, Astro ya ofrece control granular por componente, y por eso es una opción excelente para proyectos donde el contenido estático predomina y la interactividad está bien localizada.