Core Web Vitals: Google juzga tu velocidad página a página, pero tu informe las agrupa

Las Core Web Vitals son tres medidas con las que Google determina lo rápida y agradable que es tu web para el visitante. No son sugerencias, son cifras duras que influyen directamente en tus posiciones en los resultados de búsqueda.

• LCP (Largest Contentful Paint): mide en cuánto carga el elemento visible más grande. El umbral de Google: 2,5 segundos.
• INP (Interaction to Next Paint): sustituye desde marzo de 2024 a la vieja medida FID y mide en cuánto responde tu web a una interacción del usuario. Umbral: 200 milisegundos.
• CLS (Cumulative Layout Shift): mide los saltos inesperados de los elementos durante la carga. Valor deseado: por debajo de 0,1.

Google juzga estos valores página a página, sobre el percentil 75 de los datos de usuarios reales; así está en la explicación de Google sobre Core Web Vitals. Si prefieres refrescar antes lo básico, mira nuestra base de conocimiento.

A veces se lee que desde marzo de 2026 Google juzga toda tu web con una nota compuesta de Core Web Vitals. Ese cambio nunca ha ocurrido y esa expresión no es de Google. Lo que sí hay: Google juzga la experiencia de página página a página y nunca ha anunciado una nota compuesta de sitio.

La confusión viene de tu informe. Search Console agrupa URL con una experiencia de usuario parecida y da a todo el grupo el mismo estado. Si un grupo tiene pocos datos, el informe cae en un grupo para todo tu dominio. Por eso una página de plantilla lenta pinta de rojo un grupo entero, aunque el resto del grupo sea rápido. Eso es una forma de presentarlo en tu informe y no una valoración de posicionamiento para toda la web.

Un grupo en Search Console recibe el estado de las URL que peor van dentro de él. Diez páginas rápidas en el mismo grupo no lo compensan: ves rojo, y no ves de entrada qué URL lo provoca. Cuando lo que falla no es la medición sino la presentación en el teléfono, la web se ve mal en el móvil recorre los ajustes.

No es una pequeñez, porque ese informe es lo que guía tus decisiones. Mientras tu grupo esté en rojo no sabes si el problema está en una plantilla concreta o en todas partes, y sueles acabar acelerando la página equivocada.

Consejo: abre el grupo rojo, ordena por las peores URL y empieza por ahí. Arreglar una página lenta aporta más que acelerar todavía más diez páginas rápidas.

No hace falta adivinar. Con tres herramientas gratuitas ves en unos minutos cómo estás.

• Google Search Console: abre el informe Core Web Vitals en el menú de la izquierda y mira cuántas páginas salen como deficientes. Más de un 20 por ciento apunta a un problema.
• PageSpeed Insights: entra en pagespeed.web.dev e introduce tu URL. No pruebes solo la portada, prueba también tu página de contacto, entradas del blog y páginas de servicio.
• Site Kit para WordPress: este complemento conecta tus datos de Search Console directamente con tu panel de WordPress.

Comprobar solo la portada es un error muy repetido. Son justo las páginas olvidadas, más adentro de tu web, las que tiran la nota hacia abajo.

• Paso 1: haz inventario de tus peores páginas. Abre Search Console, ve al informe Core Web Vitals y ordena por deficiente. Esas son tus prioridades.
• Paso 2: ponte con las imágenes. En las webs de pymes es la causa que más vemos. Un porcentaje lo dejamos fuera a propósito, porque es una impresión de nuestro propio trabajo y no una medición. Comprímelas por debajo de 200 KB, usa el formato WebP y activa la carga diferida. Complementos como ShortPixel o Imagify lo automatizan.
• Paso 3: limpia tus scripts. Cada complemento, widget, medidor y chat ralentiza tu página. Quita lo que no necesites de verdad.
• Paso 4: arregla tu alojamiento. El alojamiento compartido barato se queda corto a menudo. El alojamiento WordPress gestionado con caché y CDN tiene un efecto medible, pero las tarifas de entrada varían: Cloudways empieza en torno a 11 dólares al mes, Kinsta en torno a 35 dólares y WP Engine en medio. Para una web profesional con tráfico real cuenta con 30 a 50 euros al mes, y mira qué entra en esa cifra de CDN, copias de seguridad y entorno de pruebas.
• Paso 5: quita o mejora las páginas viejas. Las páginas con mala nota y sin tráfico es mejor quitarlas y redirigirlas a una página relevante.

Consejo: piensa en la regla del 80/20 como regla práctica y no como medición: en la práctica la mayor parte de tu problema de velocidad está en una pequeña parte de tus páginas.

Si no te aclaras solo, lo cogemos nosotros como parte de mejorar el SEO.

• Imágenes sin comprimir: el mayor culpable. Una foto de seis megabytes en la página 17 puede cargarse la nota de toda tu web.
• Demasiados complementos: en casi todas las webs que abrimos hay complementos que alguien activó por algo y que después nadie limpió. Cuéntalos y pregúntate por cada uno para qué sigue estando hoy.
• Sin caché: la diferencia puede llegar a 3 o 4 segundos de carga por página.
• Scripts externos de terceros: Google Analytics, Facebook Pixel, HotJar, Google Tag Manager. Cada petición extra ralentiza tu página.
• Contenido incrustado: un vídeo de YouTube incrustado carga un reproductor completo con sus propios scripts, y eso cuesta un tiempo que se nota. Cuánto exactamente cambia por página, así que mídelo tú mismo una vez con y sin. Usa una miniatura con botón de reproducción que cargue el vídeo solo al hacer clic.

¿Quieres mirar más allá de la velocidad? Lee entonces cómo te encuentran en las AI Overviews de Google y en ChatGPT.

Casi siempre se citan tres cifras: 2,5 segundos, 200 milisegundos y 0,1. Son los límites de lo que Google llama bueno. Lo que se cuenta mucho menos es que cada medida tiene tres franjas y no dos, y que la de en medio es justo donde se queda la mayoría de las webs de empresas pequeñas. No estás en rojo, tampoco en verde, y el informe te deja en un sitio que cuesta interpretar.

• LCP. Bueno hasta 2,5 segundos, necesita mejorar entre 2,5 y 4 segundos, deficiente por encima de 4 segundos. Fuente: la definición de LCP en web.dev, consultado el 25-08-2026.
• INP. Bueno hasta 200 milisegundos, necesita mejorar entre 200 y 500 milisegundos, deficiente por encima de 500 milisegundos. Fuente: la definición de INP en web.dev, consultado el 25-08-2026.
• CLS. Bueno hasta 0,1, necesita mejorar entre 0,1 y 0,25, deficiente por encima de 0,25. Fuente: la definición de CLS en web.dev, consultado el 25-08-2026.

Hay un detalle más que cambia cómo lees tu informe. Una URL solo cuenta como aprobada cuando las tres medidas están en verde a la vez, medidas en el percentil 75; así lo describe la página de Google sobre las Core Web Vitals, consultado el 25-08-2026. Con dos verdes y un ámbar, esa URL sigue sin pasar. Por eso la primera pregunta no es cómo acelero mi web, sino cuál de las tres agujas se sale. El trabajo para bajar el LCP no se parece en nada al trabajo para bajar el CLS, y quien no mira eso primero acaba comprimiendo imágenes en una web cuyo problema son los saltos de maquetación.

Abres PageSpeed Insights y ves dos bloques que dicen cosas distintas. Arriba, lo que vivieron visitantes reales. Abajo, una prueba de laboratorio. No es un fallo de la herramienta: son dos maneras de medir, y solo una de las dos es la que acaba en tu informe de Search Console.

Los datos de campo vienen del Chrome UX Report. Recogen lo que experimentaron usuarios reales de Chrome que aceptaron compartir esa información, sobre una ventana de 28 días que va corriendo, tal como recoge la metodología del Chrome UX Report, consultado el 25-08-2026. El valor que se publica es el percentil 75: de cada cuatro visitas, tres fueron igual de rápidas o más. Ese percentil está en la página de Google sobre las Core Web Vitals, consultado el 25-08-2026.

Los datos de laboratorio los produce Lighthouse. Carga tu página una vez, en un entorno simulado, con una red y un dispositivo que define la propia herramienta. Sirve para diagnosticar, para ver qué recurso pesa demasiado y para comparar dos versiones de la misma página, pero no es lo que Google usa para valorar la experiencia de página.

De ahí salen dos consecuencias muy prácticas. La primera: una página nueva o con pocas visitas puede no tener datos de campo, y entonces solo ves laboratorio; eso no significa que vaya bien, significa que aún no hay suficiente gente que la haya abierto. La segunda: cuando arreglas algo hoy, el laboratorio lo refleja al momento y el campo tarda, porque la ventana de 28 días tiene que ir dejando atrás los días malos uno a uno. Quien mira solo el campo concluye a los tres días que no ha servido de nada. Quien mira solo el laboratorio concluye que ya está hecho. Las dos conclusiones son falsas y las dos cuestan semanas.

La lectura sana es sencilla: usa el laboratorio para decidir qué tocas y el campo para comprobar si de verdad ha cambiado algo para la gente. Y anota la fecha en la que hiciste el cambio, porque dentro de un mes vas a necesitar saber dónde empieza a contar.

La reacción automática ante un LCP alto es comprimir la imagen grande. A veces funciona. Muchas veces no, porque la imagen es el último de los cuatro trozos en los que se descompone esa medida. Google publica esa descomposición, y es la herramienta más útil que existe para no perder una tarde en el sitio equivocado. Fuente: la guía de Google para optimizar el LCP, consultado el 25-08-2026.

• Tiempo hasta el primer byte. Lo que tarda tu servidor en empezar a contestar. Si aquí ya se te va casi un segundo, ninguna compresión de imágenes te va a salvar. Aquí mandan el alojamiento, la caché de página y la distancia entre tu servidor y tu visitante.
• Retraso hasta que empieza a cargarse el recurso. El tiempo entre que el navegador puede pedir la imagen y el momento en que de verdad la pide. Suele significar que la imagen se descubre tarde, por ejemplo porque la mete un script, un carrusel o una hoja de estilos en vez de estar en el HTML.
• Duración de la carga del recurso. Este sí es el peso del archivo. Aquí ayudan el formato moderno, el tamaño correcto para la pantalla y no servir una foto de 3000 píxeles a un teléfono.
• Retraso hasta que se pinta el elemento. La imagen ya está en el navegador pero todavía no se ve, casi siempre porque hay JavaScript o una fuente bloqueando la pintura.

La consecuencia práctica es que hay dos webs con el mismo LCP de 4 segundos y con dos planes de trabajo que no se parecen en nada. En una, tres segundos son servidor. En la otra, tres segundos son una imagen de seis megas. Comprimir en la primera no cambia casi nada, y cambiar de alojamiento en la segunda tampoco. Mira primero la descomposición, decide después.

Un detalle que se repite mucho en WordPress: la carga diferida de imágenes es buena para todo lo que está más abajo, y mala para la imagen principal. Si difieres la imagen que es tu propio LCP, la estás retrasando a propósito. Deja fuera de la carga diferida la primera imagen visible.

El INP mide lo que tarda tu página en enseñar algo después de que el visitante toca, hace clic o escribe. También se descompone, en tres partes. Fuente: la página de Google sobre el INP, consultado el 25-08-2026.

• Retraso de entrada. El tiempo entre el toque y el momento en que el navegador puede ponerse con él, porque estaba ocupado con otra cosa. Casi siempre es JavaScript de terceros ejecutándose justo después de la carga.
• Tiempo de proceso. Lo que tarda en ejecutarse el código que responde a esa interacción. Un menú, un filtro, un añadir al carrito.
• Retraso de presentación. Lo que tarda el navegador en pintar el resultado en pantalla después de ejecutar el código.

El INP se distingue de las otras dos medidas justamente en esto, porque no se mide al cargar. Se mide durante toda la visita, y se queda con la peor interacción, o casi la peor si hay muchas. Así que una página puede cargar en un suspiro y suspender el INP porque el menú desplegable tarda medio segundo en abrirse la primera vez.

Eso también explica por qué el INP no se ve en una prueba de laboratorio corriente: nadie interactuó con la página durante esa prueba. Para verlo de verdad tienes que abrir la web en el móvil y usarla como la usa un cliente: pulsa el menú, escribe en el buscador, abre el acordeón de preguntas, filtra el catálogo. Ahí es donde aparece.

Casi todo lo que arregla el INP consiste en quitar cosas, no en añadirlas. Un chat que carga en todas las páginas para usarse en una. Un gestor de etiquetas con doce etiquetas de las que ocho ya no van a ningún sitio. Un carrusel de la portada que solo ven los que hacen la foto de la web. Cuenta cuántos scripts se cargan y pregunta por cada uno para qué sigue estando hoy.

El CLS es la única de las tres que se ve a simple vista: estás a punto de pulsar un botón, la página se mueve y acabas en otro sitio. En la práctica los saltos vienen casi siempre de tres orillas, y las tres tienen la misma solución de fondo, que es reservar el espacio antes de necesitarlo. Fuente: la guía de Google para optimizar el CLS, consultado el 25-08-2026.

• Imágenes y vídeos sin medidas. Si el HTML no dice cuánto ocupa una imagen, el navegador no puede reservar hueco y todo lo que hay debajo salta cuando llega. Poner ancho y alto, o una proporción fija, arregla el caso más común de todos.
• Contenido que se inyecta después. Un aviso de cookies, un banner, un anuncio, un widget de opiniones, un iframe. Aparecen cuando la página ya estaba dibujada y empujan el texto hacia abajo. La solución no es quitarlos, es dejarles un sitio del tamaño correcto desde el principio.
• Fuentes web. El texto se pinta primero con una fuente del sistema y después cambia a la tuya. Si las dos fuentes tienen anchos distintos, cada párrafo se recoloca. Precargar la fuente y elegir una alternativa con métricas parecidas quita ese salto.

Hay un caso que confunde a mucha gente: los saltos que provoca el propio visitante. Si abres un acordeón y el contenido de debajo se mueve, eso es esperado y no cuenta igual, porque el movimiento viene después de una acción suya. Se penaliza el movimiento que nadie pidió, el que llega solo.

Comprobarlo es barato. Abre tu página en el móvil con la caché vacía y con la red limitada, y mírala mientras carga sin tocar nada. Todo lo que veas moverse está en tu CLS. Es la única de las tres medidas que puedes diagnosticar con los ojos antes de abrir una herramienta.

¿Google juzga las Core Web Vitals por página o por sitio entero?

Por página. Search Console las muestra en grupos de páginas con una experiencia parecida, y con pocos datos en un grupo para todo tu dominio. Si ves ahí un grupo rojo, busca la URL más lenta de ese grupo. Google nunca ha anunciado una nota de Core Web Vitals para todo el sitio.

¿Cuánto influyen las Core Web Vitals en mis posiciones?

Las Core Web Vitals no son el factor de posicionamiento más importante. Cuentan, y cuentan sobre todo cuando la competencia está muy igualada en contenido. Un número de posiciones no lo damos: cambia por término de búsqueda y nadie lo puede calcular por adelantado, nosotros tampoco.

¿Tengo que borrar todas mis páginas viejas?

No. Borra solo las páginas que van mal y traen poco tráfico. Las que sí traen tráfico se mejoran.

¿En cuánto veo resultado?

Google basa las Core Web Vitals en 28 días de datos de usuarios. Cuenta por tanto con cuatro semanas como mínimo antes de que una mejora pueda verse en el informe, porque eso es lo que tarda en correrse la ventana de medición. Cuándo reaccionan tus posiciones no se puede predecir: depende también de todo lo que hagan tus competidores en esas mismas semanas.

¿Puede ayudar TheSEO?

Sí. Hacemos un análisis completo, identificamos tus páginas problemáticas y entregamos un plan de acción concreto con prioridades. Mira nuestro enfoque en mejorar el SEO o profúndiza tú mismo en la base de conocimiento.

El orden de trabajo importa más que la herramienta que elijas. Abre el grupo que está en rojo en Search Console, ordena por las peores URL, mira cuál de las tres agujas se sale en esa página y arregla esa. Después espera cuatro semanas antes de sacar conclusiones, porque la ventana de medición es de 28 días y antes de eso tu informe todavía está contando los días malos. Si prefieres no hacerlo solo, la velocidad forma parte de mejorar el SEO y la capa de debajo, la que decide tu tiempo hasta el primer byte y tu orden de carga, está en SEO técnico; lo que cuesta cada cosa lo tienes en precios.

Y si lo que quieres es simplemente saber si tu grupo rojo es un problema de verdad o una página olvidada que nadie abre, cuéntanoslo. Nos mandas la captura del informe o la URL, y te decimos por dónde empezaríamos y qué no tocaríamos. Eso no cuesta nada y no te compromete a nada.