Velocidad del sitio y Core Web Vitals

La velocidad de un sitio influye tanto en el presupuesto de rastreo que los robots le dedican como en la experiencia real de los visitantes: un sitio lento se explora con menos frecuencia y menos profundidad, y pierde visitantes incluso antes de que lleguen a leer el contenido. Los Core Web Vitals son la herramienta estándar para medir esa velocidad de forma comparable entre sitios.

Por qué la velocidad influye en el crawl budget y en la experiencia

El presupuesto de rastreo (crawl budget) designa el número de páginas que un robot está dispuesto a explorar en tu sitio en un tiempo dado. Ese presupuesto no es ilimitado: depende en parte de la capacidad de tu servidor para responder con rapidez. Por lo general se observa que un sitio lento o inestable lleva a los robots a reducir su frecuencia de paso y el número de páginas exploradas por visita, lo que ralentiza mecánicamente el descubrimiento de contenido nuevo y su actualización en el índice.

Del lado del usuario, el efecto es más directo: un tiempo de carga largo aumenta la tasa de abandono incluso antes de que se muestre el contenido. Para un objetivo GEO, esto cuenta doblemente: una página lenta tiene menos probabilidades de ser rastreada por un crawler de IA, y menos probabilidades de ser leída hasta el final por un internauta que hace clic desde una respuesta generada.

Las tres métricas Core Web Vitals explicadas

Google definió tres métricas que, juntas, forman los Core Web Vitals:

• LCP (Largest Contentful Paint): el tiempo necesario para mostrar el elemento visible más grande en pantalla (a menudo una imagen principal o un titular). Objetivo generalmente recomendado: por debajo de 2,5 segundos.
• INP (Interaction to Next Paint): el retraso entre una interacción del usuario (clic, pulsación de tecla) y la actualización visual correspondiente. Esta métrica sustituyó al FID (First Input Delay) en 2024. Objetivo generalmente recomendado: por debajo de 200 milisegundos.
• CLS (Cumulative Layout Shift): la medida de los desplazamientos visuales inesperados durante la carga (un botón que se mueve justo antes de que hagas clic en él, por ejemplo). Objetivo generalmente recomendado: por debajo de 0,1.

Estos umbrales son referencias orientativas publicadas por Google, no reglas absolutas válidas en todos los contextos: un sitio con mucho contenido interactivo complejo puede tolerar márgenes ligeramente distintos según su uso.

Medir con PageSpeed Insights (y por qué no solo con él)

pagespeed.web.dev es la herramienta de referencia para probar una página concreta. Proporciona dos tipos de datos, que conviene no confundir:

• Los datos de campo (Field Data), procedentes del Chrome User Experience Report, que reflejan la experiencia real de tus visitantes durante los últimos 28 días — disponibles solo si tu sitio recibe suficiente tráfico de Chrome.
• Los datos de laboratorio (Lab Data), generados en una prueba simulada en el momento en que lanzas el análisis — útiles para diagnosticar, pero que pueden variar de una prueba a otra según las condiciones de red simuladas.

El informe de Core Web Vitals de Google Search Console, visto en una lección anterior, complementa esta herramienta al ofrecer una vista agregada de todo el sitio en lugar de página por página, lo que ayuda a priorizar por plantilla en lugar de por URL aislada.

Móvil y escritorio: dos realidades distintas

Los Core Web Vitals se evalúan por separado para móvil y para escritorio, y los resultados a menudo divergen claramente entre ambos. Dado que la mayor parte del tráfico web se produce hoy en móvil, y que Google utiliza la indexación «mobile-first» (es la versión móvil de tu página la que sirve de referencia para el rastreo y la evaluación), se recomienda tratar los resultados móviles como prioritarios en caso de tener que elegir. Un sitio que obtiene buenas puntuaciones en escritorio pero puntuaciones mediocres en móvil sigue siendo, desde el punto de vista de Google, un sitio con un problema de velocidad que corregir.

Las correcciones más frecuentes y su orden de prioridad

En la mayoría de las auditorías, las ganancias más rápidas provienen de:

1. Compresión y redimensionamiento de imágenes: servir imágenes al tamaño realmente mostrado, en un formato moderno (WebP o AVIF), con carga diferida (lazy loading) para las imágenes fuera de pantalla.
2. Reducción del JavaScript bloqueante: retrasar la carga de scripts no esenciales para el renderizado inicial (chat en línea, widgets de terceros, píxeles publicitarios secundarios).
3. Reserva de espacio para los elementos dinámicos: definir dimensiones explícitas para imágenes, vídeos y anuncios antes de que se carguen, para evitar desplazamientos de la maquetación (CLS).
4. Caché y CDN: usar una red de distribución de contenido para acercar los archivos estáticos a los visitantes, y configurar una caché de navegador adecuada.
5. Elección del alojamiento: un alojamiento compartido barato suele seguir siendo el factor limitante más difícil de corregir sin cambiar de solución técnica.

Seguir el impacto en el tiempo

Después de cada corrección significativa, vuelve a comprobar con PageSpeed Insights y vigila el informe de Core Web Vitals de Search Console en las semanas siguientes en lugar de en la hora siguiente: los datos de campo se basan en una ventana móvil de 28 días, no reaccionan de forma instantánea a un cambio.

Una vez controlada la velocidad, la base técnica del sitio está prácticamente asentada. Es momento de abordar el control del acceso de los robots con la lección sobre el archivo robots.txt y el control de los crawlers de IA, y después entender en detalle cómo lee una página un motor de búsqueda.