Meta descripción: Cómo una web de 364 páginas estáticas con Astro logra un TTFB inferior a 50 ms, 100/100 en PageSpeed, JSON-LD, Open Graph y cero JavaScript innecesario.
Hay un momento en la vida de cualquier web en el que dejas de preguntarte «¿qué contenido voy a publicar?» y empiezas a preguntarte «¿por qué esto tarda tanto en cargar?». Ese momento suele llegar cuando el sitio ya tiene cientos de páginas, un tema lleno de plugins, un puñado de scripts de terceros y una puntuación de PageSpeed que da más pena que orgullo.
Esta web ha pasado por ese proceso. Hoy cuenta con 364 páginas, todas ellas generadas previamente en HTML puro, con una respuesta del servidor inferior a 50 milisegundos, una puntuación de 100/100 en Google PageSpeed y un nivel de SEO técnico que hace unos años habría requerido media docena de plugins y mucha paciencia. La tecnología que lo hace posible se llama Astro.
En este artículo te explico, sin humo, qué ha cambiado, por qué importa para el posicionamiento y para la experiencia de quien te lee, y qué decisiones técnicas hay detrás. Si tienes un blog, una web de servicios o un proyecto de contenido, casi todo lo que cuento aquí te puede servir aunque no uses Astro.
1. El problema de las webs «dinámicas por costumbre»
La mayoría de las webs que se construyen hoy funcionan de una manera sorprendentemente ineficiente. Cada vez que alguien visita una página, el servidor ejecuta código, consulta una base de datos, monta el HTML con una plantilla, lo envía al navegador y, además, adjunta uno o varios paquetes de JavaScript que el navegador tiene que descargar, analizar y ejecutar antes de que la página sea realmente usable.
Ese esfuerzo tiene sentido cuando el contenido cambia en cada visita: un panel de usuario, una tienda con stock en tiempo real, una red social. Pero un artículo de blog no cambia entre una visita y la siguiente. Es el mismo texto, las mismas imágenes y la misma estructura para el lector número uno y para el lector número diez mil. Construir esa página desde cero cada vez es como cocinar un plato nuevo cada vez que un cliente lo pide, aunque el menú no haya cambiado en meses.
La consecuencia es conocida: tiempos de respuesta irregulares, dependencia de cachés que hay que configurar y vigilar, páginas pesadas, y un rendimiento que se degrada a medida que crece el sitio o aumentan las visitas.
La alternativa es tan antigua como la propia web, pero llevada al siglo XXI: generar las páginas una sola vez, en el momento de publicar, y servirlas como archivos estáticos.
2. Qué es Astro y por qué encaja tan bien con un blog
Astro es un framework pensado desde cero para sitios orientados a contenido: blogs, webs corporativas, documentación, portafolios, medios. Su filosofía se resume en una frase: enviar al navegador solo lo que haga falta.
Funciona así:
- Durante la compilación, Astro toma tus plantillas, tus artículos (por ejemplo, en Markdown) y tus datos, y genera un archivo HTML completo por cada página.
- Al visitar la web, el servidor no calcula nada: simplemente entrega el archivo que ya está listo, normalmente desde una red de distribución de contenidos (CDN) cercana al usuario.
- El JavaScript es opcional, no obligatorio. Si un componente no necesita interactividad, no se envía ni una línea de código para él.
A esta idea se la conoce como arquitectura de islas: la página es un mar de HTML estático y solo las «islas» que realmente necesitan interactividad (un menú móvil, un buscador, un formulario) reciben su porción de JavaScript. Todo lo demás es texto, imágenes y estilos.
Para una web con 364 páginas, esto significa que el trabajo pesado se hace una vez, en mi ordenador o en el proceso de despliegue, y no millones de veces en el servidor cada vez que alguien lee un artículo.
3. Rendimiento: velocidad que se nota y que se mide
3.1. Time to First Byte (TTFB) casi nulo
El TTFB es el tiempo que pasa desde que el navegador solicita una página hasta que recibe el primer byte de respuesta. Es la base de todo lo demás: si el servidor tarda 800 milisegundos en empezar a responder, ninguna optimización posterior podrá compensarlo del todo.
Con las 364 páginas precalculadas en HTML puro, el servidor no ejecuta lógica ni consulta bases de datos: localiza un archivo y lo entrega. El resultado es una respuesta inferior a 50 ms, tanto para un lector como para Googlebot. Y eso es relevante por partida doble:
- Para las personas, porque la sensación de inmediatez es perceptible. La página «está ahí» antes de que el usuario tenga tiempo de dudar.
- Para los rastreadores, porque Google asigna a cada sitio un presupuesto de rastreo limitado. Un servidor que responde rápido permite que Googlebot recorra más páginas en menos tiempo, algo especialmente valioso cuando el sitio crece o se actualiza con frecuencia.
3.2. Core Web Vitals y PageSpeed 100/100
Los Core Web Vitals son el conjunto de métricas con el que Google mide la experiencia real de usuario. Tres de ellas son las más conocidas:
- LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento principal de la página, normalmente el titular o la imagen destacada.
- INP (Interaction to Next Paint): cuánto tarda la página en responder cuando el usuario interactúa con ella.
- CLS (Cumulative Layout Shift): cuánto «saltan» los elementos mientras la página termina de cargar.
Una arquitectura basada en HTML estático juega con ventaja en las tres. El contenido principal ya viene en el documento, por lo que aparece en pantalla de inmediato, sin esperar a que un framework de JavaScript «monte» la página. No hay parpadeos de carga ni esqueletos que se sustituyen por contenido real. Y como hay muy poco JavaScript en el hilo principal, el navegador queda libre para responder a cualquier interacción sin retrasos.
El resultado práctico es una puntuación de 100/100 en Google PageSpeed. Conviene ser honestos con lo que significa esa cifra: es una medición de laboratorio, útil como termómetro, pero no es lo único que cuenta. Lo importante no es el número en sí, sino lo que refleja: una experiencia rápida, estable y fluida, también en móviles de gama media y con conexiones mediocres, que es donde muchas webs flaquean.
Y sí, Google ha dicho públicamente que la experiencia de página es una señal de posicionamiento. No convierte una web mala en una web top, pero entre dos contenidos de calidad similar, la que ofrece mejor experiencia parte con ventaja. Además, una web rápida reduce la tasa de rebote, aumenta el tiempo de lectura y mejora las conversiones, que son beneficios que van más allá del SEO.
3.3. Zero-JS por defecto
Quizá el aspecto más transformador sea el enfoque zero-JS por defecto. En muchos sitios modernos, leer un simple artículo obliga al navegador a descargar varios megabytes de JavaScript: librerías, frameworks, código de seguimiento, widgets, polyfills. Ese código hay que descargarlo, analizarlo y ejecutarlo, y todo eso consume batería, datos móviles y paciencia.
En esta web, las páginas no obligan al lector a descargar megabytes de código para leer un texto. El JavaScript solo se envía donde es realmente necesario, como en el menú móvil. Lo demás es HTML y CSS, dos lenguajes que los navegadores procesan a una velocidad enorme.
Esto tiene beneficios concretos:
- Menor consumo de datos, importante para quien navega con tarifas limitadas o en zonas con poca cobertura.
- Mayor accesibilidad: una página que funciona sin depender de scripts es más robusta ante errores, extensiones del navegador o dispositivos antiguos.
- Menos superficie de fallo y de ataque: menos código en el cliente significa menos cosas que pueden romperse o ser explotadas.
- Mantenimiento más sencillo: menos dependencias, menos actualizaciones críticas y menos sorpresas tras cada cambio.
4. SEO de última generación integrado en la base
La velocidad es solo la mitad de la historia. Un buen posicionamiento también necesita que los buscadores entiendan perfectamente de qué trata cada página y que las redes sociales sepan presentarla bien. Aquí es donde un sitio estático construido con cuidado brilla, porque todos los elementos técnicos se generan de forma coherente y automática para cada URL.
4.1. Datos estructurados con JSON-LD y Schema.org
Cada artículo incluye datos estructurados en formato JSON-LD siguiendo el vocabulario de Schema.org. En concreto se inyectan dos tipos de marcado:
- BlogPosting: describe el artículo con su título, autor, fecha de publicación, fecha de modificación, imagen destacada y temática. Es como entregar a Google una ficha técnica del contenido para que no tenga que adivinar nada.
- BreadcrumbList: describe la ruta de navegación (Inicio > Categoría > Artículo), lo que ayuda a los buscadores a entender la jerarquía del sitio y puede mostrarse en los resultados como una ruta limpia en lugar de una URL larga.
Es importante matizar: los datos estructurados no garantizan resultados enriquecidos ni mejoran por sí solos el ranking. Lo que hacen es eliminar ambigüedad. Cuando Google «entiende al instante» quién es el autor, cuándo se publicó el contenido, qué imagen lo representa y dónde encaja dentro del sitio, tiene menos motivos para equivocarse al clasificarlo y más información para mostrarlo bien.
Además, al generarse en la compilación a partir de los mismos datos que alimentan la página (el título, la fecha o la imagen del propio artículo), el marcado nunca queda desfasado respecto al contenido visible. Esa coherencia es una de las ventajas silenciosas de este enfoque frente a plugins que a veces duplican o contradicen la información.
4.2. Open Graph dinámico: la primera impresión al compartir
Cuando alguien comparte un enlace en Twitter/X, WhatsApp, LinkedIn o Facebook, la plataforma no muestra la página: muestra una tarjeta construida a partir de metadatos Open Graph. Si esos metadatos faltan o son pobres, el enlace aparece como una URL fría y sin imagen, y la probabilidad de que alguien haga clic se desploma.
Cada página de esta web genera su propia tarjeta visual optimizada, con título, descripción e imagen específicos. El efecto es que cualquier artículo compartido luce profesional y reconocible en todas las plataformas, lo que contribuye a lo que podríamos llamar el SEO indirecto: más clics, más difusión, más menciones y más oportunidades de enlaces naturales.
Un detalle práctico que suele pasarse por alto: conviene que la imagen social tenga una proporción adecuada (en torno a 1200 × 630 píxeles), que el texto sea legible a tamaño reducido y que cada artículo tenga su propia imagen en lugar de una genérica para todo el sitio.
4.3. Sitemap XML y robots.txt nativos
También se generan de forma nativa dos archivos básicos pero esenciales:
- Sitemap XML: una lista completa de las URLs del sitio, con sus prioridades y frecuencias de actualización. Facilita que los buscadores descubran todas las páginas, incluidas las que están más profundas en la estructura, y detecten rápidamente cuáles han cambiado.
- robots.txt: el archivo que indica a los rastreadores qué pueden y qué no pueden recorrer, y que además señala la ubicación del sitemap.
Al producirse en cada compilación, ambos archivos reflejan siempre el estado real del sitio. Si publico un artículo nuevo, aparece en el sitemap sin que yo tenga que acordarme de actualizar nada. Si elimino una página, desaparece. Es un ejemplo perfecto de automatización que previene los típicos errores humanos del SEO: URLs olvidadas, páginas huérfanas o mapas desactualizados.
Con estas piezas combinadas, la indexación resulta limpia y predecible: Google recibe HTML inmediato, datos estructurados coherentes, un mapa completo del sitio y señales claras sobre qué rastrear.
5. Detalles que suman: iconografía Lucide
Hay decisiones pequeñas que también reflejan la filosofía del conjunto. Una de ellas es la elección de Lucide para los iconos. Se trata de una biblioteca de iconos SVG limpios, consistentes y de código abierto, con varias ventajas:
- Vectoriales: se ven nítidos en cualquier pantalla y a cualquier tamaño, desde un móvil hasta un monitor de alta densidad.
- Ligeros: al ser SVG, pueden incrustarse directamente en el HTML sin peticiones adicionales ni fuentes de iconos pesadas.
- Accesibles: se pueden etiquetar correctamente para lectores de pantalla o marcarse como decorativos cuando corresponde.
- Personalizables: heredan color y tamaño desde CSS, lo que permite mantener coherencia visual y soportar modos claro y oscuro sin esfuerzo.
Frente a las antiguas fuentes de iconos, que obligaban a descargar un archivo entero para usar apenas unos pocos símbolos, los SVG integrados cargan solo lo que se utiliza. Es el mismo principio de todo el proyecto aplicado a un detalle visual: nada de peso innecesario.
6. Lo que he aprendido en el camino
Una migración como esta deja varias lecciones que creo que merece la pena compartir:
- Más no siempre es mejor. Cada plugin, script o dependencia que añades es una promesa de mantenimiento y un coste de rendimiento. Empezar desde lo mínimo y añadir solo lo imprescindible produce sitios más sólidos.
- La velocidad es una decisión de arquitectura, no de optimización final. Intentar «arreglar» un sitio lento a base de cachés y compresiones es mucho más difícil que partir de una base que ya es rápida por diseño.
- El SEO técnico debe ser automático. Si depende de que alguien se acuerde de rellenar un campo o regenerar un archivo, tarde o temprano fallará. Integrarlo en la plantilla garantiza coherencia en las 364 páginas, y en las que vengan.
- El contenido sigue mandando. Nada de lo anterior sustituye a escribir cosas útiles. La técnica elimina obstáculos, pero es el contenido el que gana la atención y la confianza del lector.
- Medir antes y después. Herramientas como PageSpeed Insights, Search Console o los informes de Core Web Vitals permiten comprobar que los cambios funcionan de verdad y no solo en teoría.
7. ¿Es Astro para todo el mundo?
Sería deshonesto presentarlo como una solución universal. Astro brilla en webs donde el contenido es protagonista y la interactividad es puntual. Si tu proyecto es una aplicación con sesiones de usuario, paneles complejos, datos en tiempo real o una tienda con miles de variaciones dinámicas, probablemente necesites otro enfoque, o una combinación: contenido estático en Astro y partes dinámicas en servicios específicos.
También hay una curva de aprendizaje. Quien venga de gestores de contenido tradicionales tendrá que acostumbrarse a flujos de trabajo basados en archivos, control de versiones y despliegues automáticos. A cambio, obtiene propiedad total del código, costes de alojamiento mínimos (los sitios estáticos pueden alojarse prácticamente gratis) y una seguridad muy superior, ya que no hay base de datos ni panel de administración expuesto a ataques.
Conclusión
Las cifras hablan por sí solas: 364 páginas precalculadas en HTML, respuestas por debajo de 50 ms, 100/100 en PageSpeed, JavaScript solo donde hace falta, datos estructurados en cada artículo, tarjetas sociales optimizadas, sitemap y robots.txt siempre al día e iconos SVG ligeros y accesibles.
Pero detrás de los números hay una idea sencilla: una web debería respetar el tiempo y los recursos de quien la visita. Un lector que llega desde un móvil con cobertura justa merece ver el contenido de inmediato. Un buscador que visita el sitio merece entender con claridad qué hay en cada página. Y quien mantiene la web merece una base técnica que no se rompa cada vez que toca algo.
Si estás pensando en renovar tu sitio, mi recomendación es empezar por una pregunta: ¿cuánto de lo que envío al navegador es realmente necesario? Probablemente la respuesta te sorprenda, y ese será el primer paso hacia una web más rápida, más visible y más agradable de usar.
Y tú, ¿has medido últimamente el rendimiento de tu web? Cuéntame en los comentarios qué resultados te salen y qué es lo que más te preocupa.
