Core Web Vitals y SEO técnico: la arquitectura como ventaja

Los buscadores ya no sólo juzgan de qué trata tu página, sino cómo se siente al usarla: si carga rápido, si no salta mientras se dibuja, si responde sin lag al primer toque. Esas percepciones se destilan en tres números —los Core Web Vitals— que forman parte de la señal de experiencia de página. La buena noticia para quien ha llegado hasta aquí con Astro es que esta batalla se pelea, en gran medida, con la arquitectura que ya elegiste. Un sitio que envía poco JavaScript por defecto parte con ventaja en las métricas que más cuestan a las webs modernas. Esta lección, que cierra el nivel, conecta el SEO técnico con lo que Astro es en su núcleo: la velocidad no como algo que se añade al final, sino como una propiedad que emerge de cómo está construido el sitio.

Las tres métricas: LCP, CLS, INP

Los Core Web Vitals reducen la experiencia de carga a tres ejes. El LCP, Largest Contentful Paint, mide carga: cuánto tarda en pintarse el elemento más grande del viewport —normalmente una imagen de portada o un bloque de texto—. Se considera bueno por debajo de 2,5 segundos. El CLS, Cumulative Layout Shift, mide estabilidad visual: cuánto salta el contenido mientras la página se dibuja, ese salto irritante que te hace pulsar el botón equivocado; bueno por debajo de 0,1. Y el INP, Interaction to Next Paint, mide reactividad: cuánto tarda la página en responder visualmente a una interacción del usuario; bueno por debajo de 200 milisegundos.

El INP merece una nota, porque es reciente: sustituyó al antiguo FID en 2024 como métrica de reactividad, y es más exigente. Donde el FID sólo miraba la primera interacción, el INP observa la latencia de todas a lo largo de la visita y se queda con la peor. Esto lo hace especialmente sensible a la cantidad de JavaScript que compite por el hilo principal: cada script que se hidrata, cada manejador pesado, cada re-render bloquea ese hilo y alarga la respuesta al siguiente toque. El INP es, en el fondo, un medidor indirecto de cuánto JavaScript le has echado encima al navegador.

Dos precisiones evitan malentendidos con estos números. El buscador no exige perfección instantánea: te califica por el percentil 75 de tus visitas reales, así que basta con que tres de cada cuatro caigan en el rango bueno para aprobar el vital. Y los tres se miden por separado pero se aprueban juntos: tu eslabón más débil manda, porque de nada sirve un LCP soberbio si el INP se arrastra. Cada métrica tiene tres bandas —buena, a mejorar y pobre—, y el objetivo no es exprimir la que ya va bien, sino levantar la que te suspende.

Conviene además situar el peso real de todo esto. La experiencia de página es una señal de desempate, no una palanca mágica: entre dos páginas de relevancia parecida, la más rápida y estable gana, pero ninguna cantidad de velocidad rescata a una página que no responde a lo que el usuario buscaba. La velocidad es necesaria, no suficiente; tratarla como lo único que importa es tan ingenuo como ignorarla. Su virtud es que, a diferencia de la relevancia, está casi por completo en tus manos.

Por qué la arquitectura de Astro juega a favor

Aquí es donde las decisiones de los primeros niveles rinden dividendos. Astro entrega HTML estático por defecto y no envía JavaScript salvo donde declaras una isla, y esa postura ataca de raíz las tres métricas. El LCP mejora porque el navegador recibe HTML ya renderizado que puede pintar de inmediato, sin esperar a que un framework construya la página en el cliente. El CLS mejora porque el componente Image de astro:assets reserva el espacio de cada imagen con sus dimensiones, evitando el salto cuando la imagen carga. Y el INP —la métrica que más sufren las webs cargadas de scripts— se cuida casi solo: si tu página envía cero o poco JavaScript, el hilo principal está libre y las interacciones responden al instante.

La arquitectura de islas es la pieza clave. En una aplicación tradicional, toda la página se hidrata aunque el noventa por ciento sea contenido estático, y esa hidratación masiva es justo lo que ahoga al INP. En Astro, sólo se hidrata la isla concreta que necesita interactividad, con la directiva client: que además puedes retrasar —client:visible, client:idle— para no gastar el hilo hasta que haga falta. El resultado es que el coste en JavaScript de una página de Astro es proporcional a su interactividad real, no a su tamaño, y las métricas lo reflejan.

Hay un cuarto tiempo que alimenta al LCP y que la arquitectura de Astro también acorta: el TTFB, el tiempo hasta el primer byte. Un sitio estático se sirve como ficheros desde un CDN al borde, de modo que ese primer byte llega con la latencia de la red y poco más, sin una capa de servidor renderizando en cada petición. Cuando parte de la página sí necesita cómputo o personalización, las server islands dejan diferir justo ese trozo sin bloquear el resto: el armazón estático se pinta ya, y el fragmento dinámico se rellena después, en lugar de retrasar la página entera por su componente más lento.

A esto se suma que Astro transmite el documento en streaming: no espera a tener el HTML completo para empezar a enviarlo, sino que va soltando el <head> y el principio del <body> mientras el resto se genera. El navegador recibe antes lo que necesita para empezar a pintar y a descargar los recursos críticos, lo que adelanta el LCP sin que tú hagas nada especial. Son tres propiedades —CDN, islas de servidor y streaming— que no configuras: vienen con la forma del framework.

Medir: campo frente a laboratorio

Hay dos maneras de medir el rendimiento, y confundirlas lleva a conclusiones falsas. Los datos de laboratorio —los de Lighthouse o la pestaña de rendimiento— se toman en un entorno controlado y sintético: útiles para depurar porque son reproducibles, pero no reflejan a tus usuarios reales. Los datos de campo —los del informe CrUX, recogidos de usuarios reales de Chrome durante los últimos 28 días— son los que el buscador usa de verdad para la señal de experiencia de página. Un LCP impecable en tu portátil de gama alta con fibra no dice nada de cómo lo vive alguien con un móvil modesto en una red lenta.

La consecuencia práctica es que optimizas con el laboratorio pero te calificas con el campo. Herramientas como PageSpeed Insights te muestran ambos lado a lado; el informe de Core Web Vitals de Search Console agrupa tus URLs por estado según los datos de campo. Para instrumentar tus propias medidas, la librería web-vitals reporta las métricas reales tal como las percibe cada visitante, y puedes enviarlas a tu analítica para ver la distribución completa, no sólo un número de ejemplo.

// medir los vitals reales de tus usuarios
import { onLCP, onCLS, onINP } from 'web-vitals';

function reportar(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify(metric));
}
onLCP(reportar);
onCLS(reportar);
onINP(reportar);

Cuando un número sale mal, saber que sale mal no basta: necesitas saber por qué. Para eso existe la build de atribución de web-vitals, que además del valor te devuelve el elemento culpable —qué nodo fue el LCP, qué desplazamiento disparó el CLS, qué interacción concreta alargó el INP—. Convierte una métrica anónima en una dirección accionable, que es la diferencia entre saber que algo va lento y saber exactamente qué arreglar.

Una consecuencia práctica del dato de campo es la paciencia. Como se calcula sobre una ventana móvil de veintiocho días, arreglar una métrica hoy no se refleja en tu calificación mañana, sino a medida que la mejora se promedia con las semanas anteriores. Optimizas con la señal instantánea del laboratorio, pero esperas a que el campo, más lento y más verdadero, te dé la razón.

Prácticas concretas en Astro

La teoría se aterriza en unos pocos hábitos. Usa siempre el componente Image con width y height explícitos para que el navegador reserve el hueco y el CLS no se dispare; deja que Astro genere formatos modernos y tamaños responsivos, que aligeran el LCP.

---
import { Image } from 'astro:assets';
import portada from '../assets/portada.png';
---
<Image src={portada} alt="Portada del artículo" width={1200} height={630} />

Precarga la fuente que pinta el texto principal y dale font-display: swap para que el texto se muestre con una fuente de respaldo mientras la definitiva llega, en lugar de dejar un hueco en blanco que dañaría el LCP. Y sé avaro con las islas: elige la directiva client: más perezosa que el componente tolere, para que la hidratación no compita con la pintura inicial.

---
import Comentarios from '../components/Comentarios.tsx';
---
<!-- se hidrata solo cuando entra en pantalla, no antes -->
<Comentarios client:visible />

Ese precargado de la fuente crítica es una sola línea en el <head>, y ahorra el parpadeo de texto sin fuente que castiga al LCP.

---
// en el <head> del layout, para adelantar la fuente critica
---
<link
  rel="preload"
  href="/fonts/inter.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Vigila con especial recelo los scripts de terceros —analíticas, anuncios, incrustaciones de vídeo o de redes—, los verdugos más habituales de los Core Web Vitals: cada uno es una isla del JavaScript de otro que compite por tu hilo principal y que tú no gobiernas. Cárgalos con moderación, difiérelos o aíslalos en un worker, y trátalos con el mismo criterio que tus propias islas, porque un solo widget descuidado hunde el INP de toda la página. Por último, las Transiciones de Vista hacen que navegar se sienta instantáneo sin convertir el sitio en una SPA: con <ClientRouter /> en el <head> y la precarga de enlaces al vuelo, el buscador sigue viendo páginas estáticas independientes mientras el usuario percibe una navegación continua.

flowchart LR
ARQ[arquitectura de Astro] --> HTML[html estatico por defecto]
ARQ --> ISL[islas con client directives]
ARQ --> IMG[componente Image con dimensiones]
HTML --> LCP[LCP rapido]
IMG --> CLS[CLS estable]
ISL --> INP[INP reactivo]
LCP --> EXP[senal de experiencia de pagina]
CLS --> EXP
INP --> EXP
style ARQ fill:#89b4fa,color:#11111b
style EXP fill:#a6e3a1,color:#11111b