Requisitos de Google PageSpeed para la búsqueda con IA

La documentación de búsqueda de Google ha sido explícita desde 2021 sobre las señales de experiencia de página, incluidos los Core Web Vitals, como factores de posicionamiento. Lo que ha quedado más claro en la era de la búsqueda con IA es que estas señales de rendimiento no solo influyen en las posiciones de la página de resultados tradicional. Influyen en si los sistemas de IA (incluidos AI Overviews, Gemini y la clase emergente de agentes de IA que navegan en nombre de los usuarios) consideran que su contenido es lo bastante creíble y accesible como para incluirlo en sus resultados.

Un sitio web que carga lento, cambia su diseño de forma inesperada o tarda demasiado en responder a la interacción no solo frustra a los visitantes humanos. Le indica a los sistemas de evaluación de calidad de Google que la experiencia que ofrece su sitio está por debajo del umbral que Google quiere respaldar cuando cita contenido en una respuesta generada por IA. Entender las métricas específicas, cuáles son los umbrales de aprobación y cómo se conectan con la visibilidad en IA es hoy una parte central de mantener la presencia en la búsqueda orgánica en 2026.

Qué miden realmente los Core Web Vitals

Los Core Web Vitals son tres métricas estandarizadas que Google usa para medir la experiencia real de cargar y usar una página web. Son distintas de métricas de rendimiento más antiguas, como el tiempo de carga de página o el Time to First Byte, que medían el comportamiento técnico del servidor y no la experiencia del usuario al interactuar con una página ya renderizada.

Largest Contentful Paint (LCP)

El LCP mide cuánto tarda el elemento visible más grande de la página (normalmente la imagen principal, un titular grande o la miniatura de un video) en terminar de cargar y mostrarse en la pantalla del usuario. Es el indicador de Google para saber "¿cuándo se siente utilizable la página?", porque el elemento visible más grande suele ser lo que los usuarios esperan ver antes de poder interactuar con el contenido.

El LCP se mide desde el momento en que la página empieza a cargar hasta el momento en que el elemento más grande se pinta en la pantalla. Un LCP lento significa que los usuarios miran una página parcial o en blanco mientras esperan, algo que Google trata como una señal de mala experiencia.

Interaction to Next Paint (INP)

El INP reemplazó en 2024 a la antigua métrica First Input Delay (FID). Mientras que el FID medía el retraso antes de que el navegador pudiera responder al primer clic o toque del usuario, el INP mide la capacidad de respuesta de todas las interacciones a lo largo de toda la sesión: cada clic, toque o entrada de teclado que el usuario realiza mientras está en la página.

El INP es una métrica de capacidad de respuesta más completa porque captura si una página se siente lenta durante toda la visita, y no solo en el primer momento de interacción. Una página con una carga inicial rápida pero con JavaScript lento que hace que los botones no respondan después de que el usuario se desplaza hacia abajo no pasará el INP, aunque apruebe el LCP.

Cumulative Layout Shift (CLS)

El CLS mide la estabilidad visual; específicamente, cuánto se mueve el diseño de la página de forma inesperada durante la carga o el uso. Cuando las imágenes cargan sin espacio reservado, cuando las fuentes se renderizan y cambian el diseño del texto, cuando anuncios que cargan tarde empujan el contenido hacia abajo, o cuando aparecen banners de consentimiento y desplazan toda la página, todo esto genera CLS. Un CLS alto significa que los usuarios intentan interactuar con elementos que se mueven antes de que puedan hacer clic en ellos, lo que Google registra como una mala experiencia.

El CLS se mide como una puntuación (no como un valor de tiempo). Se acumula a lo largo de la sesión, lo que significa que las páginas que desplazan el contenido repetidamente, por desplazamiento infinito, imágenes con carga diferida sin atributos de tamaño o inyección de contenido dinámico, pueden acumular una puntuación de CLS alta aunque cada cambio individual parezca pequeño.

Los umbrales exactos de aprobación

Google define tres niveles para cada métrica: Bueno, Necesita mejorar y Deficiente. El umbral "Bueno" es el que debe usar como meta en el percentil 75 de las sesiones reales de usuarios medidas a partir de los datos de campo de Chrome. El estándar del percentil 75 significa que el 75 % de sus usuarios debe experimentar un rendimiento Bueno, no solo el usuario promedio o mediano.

Para aprobar los Core Web Vitals y obtener una clasificación de experiencia de página "Buena", las tres métricas deben estar en el rango Bueno en el percentil 75 de los datos de usuarios reales. Aprobar dos de tres no es suficiente: Google evalúa la métrica con peor desempeño, y una sola métrica Deficiente o que Necesita mejorar arrastra hacia abajo toda la evaluación de experiencia de página.

Cómo se conecta la velocidad de página con la visibilidad en búsqueda con IA

La conexión entre el rendimiento de la página y la visibilidad en la búsqueda con IA opera a través de varios canales distintos de las señales de posicionamiento tradicionales.

AI Overviews y la confiabilidad del contenido

Los AI Overviews de Google se nutren de un subconjunto seleccionado de contenido web que Google ha evaluado como confiable, bien estructurado y representativo de una buena experiencia de usuario. Las señales de rendimiento, incluidos los Core Web Vitals, forman parte de cómo Google evalúa la calidad general de una página. Una página con fallas crónicas de rendimiento le indica a los sistemas de calidad de Google que el sitio no recibe buen mantenimiento, lo que afecta la probabilidad de que su contenido se incluya en los resúmenes generados por IA.

Esto no es una exclusión binaria: no existe una regla documentada que diga "si no aprueba los Core Web Vitals, nunca aparecerá en AI Overviews". Pero la correlación entre las señales de calidad de página (incluido el rendimiento) y la frecuencia de citación en la búsqueda con IA es real. Las pautas internas de evaluación de calidad de Google (las Search Quality Rater Guidelines) subrayan que las páginas de baja calidad, incluidas las mal mantenidas o de carga lenta, no deben recomendarse ni amplificarse. Los AI Overviews son una extensión de los sistemas de recomendación de Google.

Navegación agéntica y tiempos de espera por rendimiento

Los agentes de IA que navegan sitios web en nombre de los usuarios, como Project Mariner de Google y herramientas similares, operan dentro de restricciones de tiempo. Cuando un agente llega a una página para evaluarla o completar una tarea, una página de carga lenta crea una barrera práctica: el agente puede agotar el tiempo de espera, no cargar los elementos interactivos antes de intentar usarlos, o simplemente darle menos prioridad al sitio frente a alternativas más rápidas que se renderizan por completo antes de que se cierre la ventana de sesión del agente.

Esta es una consecuencia más inmediata y directa del bajo rendimiento que el efecto, basado en correlación, sobre los AI Overviews. Un agente que no puede cargar su página de reservas ni interactuar con ella no puede completar una reserva. Un sitio con un LCP de 6 segundos puede simplemente no responder al agente antes de que termine la sesión.

El rendimiento móvil como señal de IA

La indexación principal de Google es mobile-first, lo que significa que los Core Web Vitals se miden principalmente en dispositivos móviles. El rendimiento móvil suele ser peor que el de escritorio en la mayoría de los sitios: los dispositivos móviles tienen menos capacidad de procesamiento, las conexiones móviles tienen mayor latencia y las pantallas móviles requieren cálculos de diseño adaptable que añaden carga de renderizado. Un sitio que aprueba los Core Web Vitals en escritorio pero falla en móvil está, en el sistema de medición de Google, fallando los Core Web Vitals.

Los sistemas de búsqueda con IA heredan esta evaluación mobile-first. Cuando los rastreadores y los sistemas de evaluación de calidad de Google analizan una página, lo hacen desde una perspectiva móvil de forma predeterminada. Optimizar solo la velocidad en escritorio e ignorar el rendimiento móvil deja una brecha considerable en su preparación para la búsqueda con IA.

Dónde fallan con más frecuencia los sitios

La mayoría de los sitios web de pequeñas y medianas empresas fallan los Core Web Vitals por un número reducido de razones predecibles. Entender estos patrones de falla le indica dónde dirigir el esfuerzo de optimización.

Fallas de LCP: imágenes principales sin optimizar y recursos que bloquean el renderizado

La causa más común de fallas de LCP es que la imagen principal de la página (la imagen grande de fondo o de banner en la parte superior) se entrega a tamaño completo, sin compresión ni codificación en formatos modernos. Una imagen principal JPEG de 3 MB en una conexión móvil producirá un LCP muy superior a 4 segundos, sin importar la velocidad del servidor.

La segunda causa más común de fallas de LCP son los recursos que bloquean el renderizado: archivos de JavaScript y CSS en el encabezado del documento que impiden que el navegador pinte algo en la pantalla hasta que terminan de descargarse y analizarse. Cada script que bloquea el renderizado en el encabezado retrasa el LCP al menos el tiempo que toma cargar y ejecutar ese archivo.

Fallas de INP: ejecución excesiva de JavaScript

Las fallas de INP casi siempre provienen de una ejecución excesiva de JavaScript en el hilo principal. Cuando el hilo principal del navegador está ocupado analizando, compilando y ejecutando paquetes grandes de JavaScript, no puede responder a las interacciones del usuario. El resultado son clics y toques que se sienten retrasados o sin respuesta: el usuario toca un botón y no pasa nada durante 300 a 600 ms antes de que la página responda.

Los scripts de terceros (plataformas de analítica, widgets de chat, redes publicitarias, administradores de etiquetas, píxeles de seguimiento) son culpables frecuentes. Cada script se ejecuta en el hilo principal y compite con el código propio de la página por el tiempo de procesamiento. Los sitios con cinco o más scripts de terceros activos en cada carga de página normalmente fallan el INP en móvil.

Fallas de CLS: imágenes sin dimensiones y contenido de carga tardía

Las fallas de CLS suelen provenir de imágenes y medios sin dimensiones de ancho y alto definidas explícitamente en su HTML. Cuando un navegador encuentra una imagen sin dimensiones, al principio no reserva espacio para ella y luego desplaza el diseño cuando la imagen carga y sus dimensiones pasan a conocerse. El mismo problema ocurre con las imágenes de carga diferida que no tienen dimensiones de marcador de posición, con las fuentes que desplazan el diseño del texto cuando terminan de cargar y con cualquier contenido inyectado en la página después del renderizado inicial (banners, avisos de consentimiento de cookies, superposiciones de widgets de chat).

Cómo medir su rendimiento actual

Antes de corregir cualquier cosa, necesita mediciones precisas. Existen dos tipos distintos de datos de rendimiento: los datos de laboratorio, obtenidos de pruebas controladas, y los datos de campo, obtenidos de usuarios reales.

Datos de campo: Google Search Console y CrUX

La fuente más autorizada para conocer el rendimiento de sus Core Web Vitals es el informe de Core Web Vitals de Google Search Console, que usa datos reales de usuarios de Chrome (CrUX, el Chrome User Experience Report) recopilados de los visitantes reales de su sitio. Estos son los datos que Google usa al evaluar su señal de experiencia de página. Si estos datos muestran fallas, Google ve fallas, sin importar lo que muestre cualquier herramienta de pruebas sintéticas.

El informe CrUX de Search Console separa los datos de móvil y de escritorio, muestra el detalle a nivel de URL para sitios grandes e indica si las páginas están en la categoría "Bueno", "Necesita mejorar" o "Deficiente" en el percentil 75. Comience aquí antes de usar cualquier otra herramienta.

Datos de laboratorio: PageSpeed Insights

La herramienta PageSpeed Insights de Google ejecuta una prueba sintética de su URL e informa tanto los datos de campo (CrUX, si están disponibles) como los datos de laboratorio de una carga simulada. La puntuación de laboratorio (el número de 0 a 100) sirve para identificar problemas específicos y medir el impacto de las correcciones, pero no es lo mismo que los datos de campo que Google usa para el posicionamiento. Una página puede obtener 95 en PageSpeed Insights y aun así fallar los Core Web Vitals en Search Console si los usuarios reales con dispositivos o conexiones más lentos tienen malas experiencias.

Use PageSpeed Insights como herramienta de diagnóstico para identificar qué corregir, no como un indicador de aprobado o reprobado. Las secciones "Oportunidades" y "Diagnósticos" muestran problemas específicos con su impacto estimado.

Acciones de optimización prioritarias

Resolver las fallas de Core Web Vitals sigue un orden de prioridad predecible. Las acciones con mayor impacto en la mayor cantidad de sitios son:

1. Convertir y comprimir las imágenes

Sirva todas las imágenes en formato WebP o AVIF en lugar de JPEG o PNG. Ambos formatos modernos suelen reducir el tamaño del archivo entre un 30 % y un 50 % con una calidad visual equivalente. Comprima todas las imágenes al menor tamaño de archivo que se vea aceptable en pantalla. Defina atributos explícitos de ancho y alto en todos los elementos <img>. Agregue loading="lazy" a todas las imágenes que están debajo del pliegue, y agregue fetchpriority="high" a su imagen principal o de LCP para indicarle al navegador que le dé prioridad.

2. Precargar la imagen de LCP

La imagen de LCP, es decir, la imagen que sea el elemento visible más grande de la página, debe precargarse en el encabezado del documento con una etiqueta <link rel="preload">. Esto le indica al navegador que comience a descargar esa imagen lo antes posible, antes de que haya analizado el CSS o el JavaScript que normalmente activarían la carga de la imagen. Este único cambio puede reducir el LCP entre 0.5 y 1.5 segundos en muchos sitios.

3. Diferir el JavaScript no crítico

Agregue los atributos defer o async a todas las etiquetas script que no necesiten ejecutarse antes de que se renderice la página. Difiera todos los scripts de terceros que no afecten el renderizado inicial: la analítica, los widgets de chat, los botones para compartir en redes sociales y los píxeles de seguimiento pueden diferirse hasta después de que cargue el contenido principal, sin afectar la experiencia del usuario. Reducir el JavaScript que bloquea el hilo principal mejora directamente tanto el LCP como el INP.

4. Auditar y reducir los scripts de terceros

Realice una auditoría de scripts de terceros. Haga una lista de cada script que carga su sitio, qué hace y si se usa activamente. Elimine todo lo que no aporte valor real al negocio. Consolide donde sea posible: usar Google Tag Manager para cargar varios scripts de seguimiento a través de un único contenedor reduce el número de solicitudes de red y la competencia por el hilo principal. Cada script de terceros que elimine mejora el INP y el LCP.

5. Reservar espacio para todo el contenido dinámico

Defina dimensiones explícitas en todos los elementos de imagen y video. Use min-height o aspect-ratio de CSS en los contenedores que cargan contenido dinámico (anuncios, incrustaciones, comentarios). Si usa un banner de consentimiento de cookies o cualquier superposición que aparezca después de cargar la página, asegúrese de que no empuje hacia abajo el contenido existente: use una superposición de posición fija en lugar de inyectarla en el flujo de la página.

6. Habilitar el almacenamiento en caché y la compresión a nivel de servidor

Asegúrese de que su servidor web o CDN sirva respuestas comprimidas (gzip o Brotli) para todos los archivos HTML, CSS y JavaScript. Habilite el almacenamiento en caché a largo plazo para los recursos estáticos (imágenes, fuentes, CSS, JS) con encabezados Cache-Control apropiados. Para los sitios en Cloudflare, asegúrese de que la minificación y la compresión Brotli estén habilitadas en la configuración de Speed.

Lecturas recomendadas

• ¿Qué es la Adaptación a la Búsqueda con IA?: el cambio más amplio en la forma en que los sistemas de IA descubren y citan el contenido web
• ¿Qué es la navegación agéntica (beta)?: cómo los agentes de IA navegan los sitios web de forma autónoma y qué necesita su sitio para respaldarlos
• ¿Qué es E-E-A-T?: las señales de confianza y autoridad que Google evalúa junto con el rendimiento
• Servicio de Optimización de Core Web Vitals: nuestro proceso de corrección de LCP, INP y CLS