Por qué este sitio usa Astro y no Next.js
Trabajamos con Next.js, pero este sitio no lo usa. Una CSP estricta, HTML estático y cero JavaScript por defecto inclinaron la balanza.
Construimos aplicaciones con Next.js y con Django. Aun así, el sitio del estudio está hecho con Astro. No es una preferencia de gusto: es aplicar a nuestro propio sitio lo que le decimos a cualquier cliente, que la herramienta se elige por el problema y no por costumbre.
El problema que había que resolver
Antes de escribir código fijamos tres objetivos que cualquiera puede comprobar:
- A+ en securityheaders.com y en MDN Observatory, lo que exige una CSP estricta, sin
'unsafe-inline'en los scripts. - Lighthouse ≥ 95 en las cuatro categorías, en móvil.
- Un sitio de contenido: textos en MDX dentro del repositorio, sin inicio de sesión, pensado para durar años.
Con esos tres objetivos, la pregunta no era «¿qué framework conocemos mejor?», sino «¿cuál cumple los tres sin pelear contra él?».
Next.js y la CSP estricta
La documentación de Next.js sobre CSP es clara: para usar un nonce, la página tiene que generarse en cada petición. Las páginas estáticas se construyen antes de que exista una petición, así que no hay dónde poner el nonce. Con nonces, todas las páginas pasan a ser dinámicas, se desactivan la optimización estática y la regeneración incremental, y el HTML deja de poder guardarse en la caché de la CDN.
Eso dejaba tres salidas en Next.js, y ninguna encajaba:
| Salida | Lo que cuesta |
|---|---|
| Nonce y render dinámico | Cada visita ejecuta el servidor y el HTML no se cachea. Duele si el servidor está lejos de tus visitantes |
'unsafe-inline' en script-src |
Observatory resta 20 puntos: adiós al A+ |
| Integridad por hashes | La propia documentación la marca como experimental |
Lo que hace Astro
Astro calcula en el build el hash de cada script y estilo que emite, y lo envía en la cabecera CSP de cada página estática. No hay que elegir entre HTML estático y una política estricta: tienes las dos cosas. En otro post contamos los detalles y los huecos que tuvimos que cubrir.
A eso se suman dos ventajas que pesan en un sitio de contenido:
- Cero JavaScript por defecto. Una página que no necesita interactividad no envía runtime. Este sitio no tiene React instalado: los pocos detalles interactivos (el menú, el filtro de proyectos, el formulario) son scripts pequeños escritos a mano.
- Contenido validado. Los textos viven en MDX con un esquema de Zod. Si a un caso de cliente le falta su consentimiento fechado, el build falla.
Los costos, a la vista
Ninguna decisión es gratis. Estos son los de esta:
- El sitio no muestra Next.js. Lo compensamos donde importa: los proyectos que presentamos sí están hechos con Next.js y Django.
- Menos familiaridad. Astro se escribe con HTML, TypeScript y CSS; lo nuevo son las colecciones de contenido y el enrutado. Fue una curva corta.
- Dependencia del framework. El contenido es MDX con un esquema explícito, así que se puede llevar a otra herramienta si algún día hace falta. Ese es el seguro real, más que cualquier promesa de un proveedor.
El resultado
El 8 de octubre de 2026 medimos producción con Lighthouse en las siete plantillas del sitio, en móvil y escritorio: 100 en rendimiento, accesibilidad, buenas prácticas y SEO en casi todas, y nunca por debajo de 95. Las cabeceras de seguridad dan A+ en las dos herramientas. Puedes repetir las mediciones desde la página de inicio.
Cuándo sí elegiríamos Next.js
Si el proyecto es una aplicación, con sesiones, datos por usuario y pantallas que cambian con cada interacción, Next.js (o Django) sigue siendo nuestra elección: ahí el render en el servidor por petición no es un costo, es lo que necesitas. Para un sitio de contenido que debe ser rápido y verificablemente seguro, Astro hace ese trabajo con menos esfuerzo.
¿Tienes que decidir el stack de tu proyecto? Cuéntanos qué necesitas y te decimos qué usaríamos y por qué.