Cuando nos propusimos rediseñar la página web de Basi Software, la elección más obvia fue Next.js. Lo utilizamos constantemente en los proyectos de nuestros clientes. El equipo lo conoce al dedillo.
En su lugar, nos decidimos por Astro. A continuación te explicamos por qué y lo que hemos aprendido.
El impuesto SPA
Las aplicaciones de una sola página han trasladado la carga de la representación del servidor al cliente. Para aplicaciones muy interactivas —cuadros de mando, editores, herramientas colaborativas—, esa es la solución adecuada. Para una página web de marketing con un formulario de contacto, supone una carga.
El «impuesto SPA» aparece como:
- Código JavaScript incluido para interacciones que nunca se producen — El usuario lee el «hero», se desplaza por la página y se va. Nunca ha hecho clic en el elemento que activa la ventana modal. Pero aun así has incluido el código JavaScript de la ventana modal.
- Cascadas de hidratación — React rehidrata todo el árbol antes de que sea posible cualquier interacción
- Cambio de maquetación — El HTML renderizado por el servidor se sustituye por HTML renderizado por el cliente, lo que provoca CLS
# Lighthouse on our old Next.js site (production build)
Performance: 71
First Contentful Paint: 1.8s
Total Blocking Time: 340ms
JavaScript bundle: ~280kb (gzipped)
# After migrating to Astro
Performance: 98
First Contentful Paint: 0.6s
Total Blocking Time: 0ms
JavaScript bundle: ~6kb (only the Nav and ContactForm islands)Qué significa realmente la arquitectura insular de Astro
El término «islas» fue acuñado por Katie Sylor-Miller, de Etsy. La idea es que una página, que por lo demás sería estática, cuente con «islas» aisladas de interactividad. Cada isla se carga de forma independiente. El resto se envía como HTML sin JavaScript.
---
// Layout.astro — the shell is pure HTML
import Nav from '../components/Nav.astro'; // Static shell + small script
import ContactForm from './ContactForm'; // React island
import HeroSection from './HeroSection.astro'; // Zero JS — static HTML
---
<body>
<!-- Astro component — no framework runtime required -->
<Nav />
<main>
<!-- Static Astro component — ships as HTML, zero runtime cost -->
<HeroSection />
</main>
</body>El formulario de contacto es el único «framework island» que hay aquí. La navegación mantiene su comportamiento interactivo gracias a un pequeño script del navegador, por lo que no hace que React se cargue en todas las páginas.
Directivas importantes
Astro presenta cinco pautas de hidratación. Elegir la adecuada tiene un impacto cuantificable:
| Directiva | Cuándo hidrata | Uso para |
|---|---|---|
client:load | Inmediatamente | Navegación interactiva en la parte superior de la página |
client:idle | Cuando el navegador está inactivo | Componentes por debajo de la línea de pliegue |
client:visible | Cuando el elemento entra en el área visible | Componentes diferidos |
client:media | Cuando se cumple la consulta de medios | Widgets exclusivos para móviles |
client:only | Solo del lado del cliente, sin SSR | Componentes que dependen de la API del navegador |
En la mayoría de las páginas web de marketing, client:visible es la opción predeterminada adecuada para todo lo que se encuentre por debajo de la línea de pliegue.
Ver transiciones sin un marco de trabajo
Una de las razones por las que los equipos optan por Next.js es su enrutador integrado con transiciones entre páginas. Astro también cuenta con esta función, a través del <ClientRouter /> el componente y la API de transiciones de vista.
---
import { ClientRouter } from 'astro:transitions';
---
<head>
<ClientRouter />
</head>/* Custom transition — runs on every page navigation */
::view-transition-old(root) {
animation: fade-out 0.3s ease-in forwards;
}
::view-transition-new(root) {
animation: slide-up 0.4s cubic-bezier(0.22, 1, 0.36, 1) forwards;
}El transition:persist El atributo en el elemento `Nav` hace que no se vuelva a cargar al pasar de una página a otra: el «island» de React permanece activo, conservando la posición de desplazamiento y el estado abierto o cerrado.
Colecciones de contenidos para contenidos con seguridad de tipos
Este mismo blog funciona con Astro Content Collections, una capa de contenido validada por Zod y basada en TypeScript:
// src/content/config.ts
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
description: z.string(),
pubDate: z.coerce.date(),
category: z.string(),
tags: z.array(z.string()).default([]),
}),
});
export const collections = { blog };Todos los archivos MDX de src/content/blog/ Ahora está completamente tipado. Si a una entrada le falta un campo obligatorio, la compilación falla; no se produce un error en tiempo de ejecución en el entorno de producción.
¿Cuándo conviene seguir optando por Next.js?
Astro no es la respuesta a todo:
- Aplicaciones muy interactivas — si la mayor parte de la página debe ser reactiva, utiliza React. Un sitio de Astro con
client:loaden cada componente es peor que Next.js. - Funcionalidades en tiempo real — Los paneles de control en tiempo real, la edición colaborativa y las interfaces de usuario que hacen un uso intensivo de WebSockets deben integrarse en una SPA adecuada.
- Aplicaciones grandes autenticadas — flujos de autenticación, enrutamiento dinámico basado en los datos del usuario, estado complejo del lado del cliente — Aquí gana Next.js
La regla general: si la mayoría de tus páginas son principalmente leer en lugar de interactuó con, Astro es el mejor punto de partida.
Conclusión
El retorno a la arquitectura de varias páginas no supone un paso atrás. Es el reconocimiento de que el modelo nativo de la web —documentos enlazados mediante hipervínculos— sigue siendo la arquitectura más eficaz, accesible y resistente para los sitios web centrados en el contenido.
Astro hace que sea muy agradable construir de esa manera en 2026.
Comments
Loading comments…