Su desarrollador muestra una puntuación de 95 en PageSpeed y jura que todo está en orden. Google, mirando los datos de campo de sus visitantes reales, puede estar viendo un sitio reprobado. Esa diferencia entre laboratorio y campo es donde la mayoría de los sitios B2B pierde posiciones sin que nadie se dé cuenta.
En esta guía va a entender qué mide cada métrica, cuáles son las metas oficiales y cómo diagnosticar su sitio en 15 minutos.
Qué son los Core Web Vitals
Core Web Vitals son las tres métricas oficiales que Google usa para medir la experiencia real de quien visita su sitio: LCP (velocidad de carga), INP (velocidad de respuesta al clic) y CLS (estabilidad visual de la página). Se recogen de usuarios reales en Chrome, entran en el algoritmo de posicionamiento y aparecen directamente en Search Console, lo que las convierte en el indicador de experiencia más concreto que un gestor tiene a mano.
Cada una responde a una pregunta simple. El LCP mide cuánto tarda en aparecer el elemento más grande de la pantalla. El INP mide cuánto tarda la página en reaccionar cuando el usuario hace clic, toca o escribe. El CLS mide cuánto salta el diseño mientras carga, ese botón que cambia de lugar justo en el momento del clic.
El INP es el más reciente del trío: en marzo de 2024 sustituyó al FID como métrica oficial. Si su último diagnóstico de rendimiento es anterior a esa fecha, está desactualizado.
Un detalle que mucha gente ignora: Google evalúa estas métricas con datos de campo de CrUX (Chrome User Experience Report), recogidos de visitantes reales a lo largo de 28 días. Una prueba de laboratorio con puntuación verde no garantiza nada si la experiencia real, en el 4G de su cliente, es mala.
Y conviene calibrar la expectativa. Core Web Vitals es una señal de posicionamiento confirmada, pero funciona como criterio de desempate entre páginas de contenido comparable. Corregir las métricas no compensa un contenido flojo, e ignorarlas le entrega ventaja al competidor que sí hizo la tarea.
Por qué el gestor de marketing debe mirar los Core Web Vitals antes que el equipo de TI
Su sitio abre rápido en su portátil, con wifi corporativo y caché llena. El cliente llega por 4G, en un Android de gama media, haciendo clic en un anuncio que usted pagó. Es en ese escenario donde las métricas se desploman, y usted nunca lo ve.
El impacto en los ingresos, no solo en el ranking
Google lo midió: el 53% de los usuarios móviles abandona una página que tarda más de 3 segundos en cargar. El estudio Milliseconds Make Millions (Google y Deloitte, 2020) encontró que 0,1 segundo menos de carga elevó la conversión del retail en un 8,4%.
Traducido a su dashboard: misma inversión en medios, mismo creativo, mayor costo por lead. La optimización del sitio devuelve ese margen antes de cualquier ajuste de campaña.
Dónde entran los Core Web Vitals en el SEO técnico en 2026
Dentro del Page Experience, las tres métricas funcionan como criterio de desempate: entre dos contenidos de calidad parecida, el más rápido tiende a quedar por delante. Y el efecto va más allá del ranking.
Un sitio lento consume más crawl budget, indexa menos páginas y dificulta la lectura por parte de ChatGPT, Gemini y Perplexity. Una página que la IA no logra procesar bien difícilmente se convierte en cita dentro de la respuesta.
LCP, INP y CLS explicados sin jerga
LCP: cuánto tarda en aparecer el contenido principal
LCP (Largest Contentful Paint) mide cuándo termina de cargar el elemento visible más grande, generalmente la imagen hero o el título de su landing page. Villanos clásicos: imagen de banner de 2 MB, servidor lento y fuente que bloquea la renderización.
INP: el retraso entre el clic y la respuesta de la página
INP (Interaction to Next Paint) mide el tiempo entre la interacción y la reacción visual. El usuario toca "añadir al carrito" y no pasa nada durante un segundo: eso es un INP malo. La causa más común son los scripts de terceros, píxeles, chats y etiquetas de medios ejecutándose todos al mismo tiempo.
CLS: el diseño que salta y hace que el usuario falle el botón
CLS (Cumulative Layout Shift) mide cuánto se mueve la página durante la carga. Banner que aparece de repente y empuja el contenido, imagen sin dimensión reservada, el clic que iba al menú y acierta en el anuncio.
Los límites de aprobación de cada métrica
| Métrica | Bueno | Necesita mejorar | Malo |
|---|---|---|---|
| LCP | hasta 2,5s | 2,5s a 4s | por encima de 4s |
| INP | hasta 200ms | 200ms a 500ms | por encima de 500ms |
| CLS | hasta 0,1 | 0,1 a 0,25 | por encima de 0,25 |
Detalle que lo cambia todo: Google evalúa el percentil 75. Es decir, el 75% de sus visitantes reales necesita tener esa experiencia, y no el promedio.
Cómo medir los Core Web Vitals de su sitio en 15 minutos
Abra PageSpeed Insights, pegue la URL de su página más importante y mire primero el bloque de arriba, "descubra lo que están experimentando sus usuarios reales". Ese es el dato que Google usa en el posicionamiento.
Después, en Search Console, acceda al informe Core Web Vitals. Agrupa URLs con el mismo problema, así que 400 páginas malas pueden ser una única plantilla de producto rota. Corregir la plantilla resuelve el grupo entero de una sola vez.
Datos de campo o datos de laboratorio
PageSpeed muestra dos números diferentes en la misma pantalla, y eso confunde a muchos gestores. El dato de campo viene de CrUX, el panel de Chrome que recoge la experiencia de usuarios reales en los últimos 28 días. El dato de laboratorio (Lighthouse) es una simulación hecha en el momento, en un entorno controlado.
Las decisiones de negocio se toman con datos de campo. El laboratorio sirve para que el desarrollador diagnostique la causa.
Priorice por ingresos, no por puntuación
No se ponga a corregir página por página. Liste las plantillas que concentran conversión (home, landing pages de medios pagos, páginas de producto) y ataque esas primero. Quien mantiene una rutina de gestión de sitios acompaña estas métricas todos los meses, antes de que el tráfico pago sufra.
Qué corregir primero y qué delegar al desarrollador
Correcciones de alto impacto y bajo esfuerzo
Empiece por lo que se resuelve en días: comprimir imágenes a WebP, activar caché, eliminar scripts de herramientas que ya nadie usa en Tag Manager. Solo la compresión de imágenes suele bajar el LCP de forma visible. En el proyecto de SP Labor, 6.433 imágenes pasaron de 4,0 GB a 1,4 GB, y el PageSpeed llegó a 97 en móvil.
Cuando el problema es el tema, el plugin o el hosting
Algunas señales indican un cuello de botella estructural: TTFB por encima de 800 ms (servidor lento), WordPress con 40 plugins activos, tema que carga 2 MB de CSS en cada página. En ese escenario, la optimización puntual es como intentar secar el hielo. El camino es un proyecto de optimización de sitios, con revisión de stack y hosting.
El briefing que el equipo técnico necesita recibir
No pida "dejar el sitio rápido". Pida con criterio de aceptación: "LCP de la home por debajo de 2,5 s en el dato de campo de PageSpeed, medido en 28 días". Sin una meta medible, entra en el ciclo de "optimizamos y no cambió nada".
Y recuerde: una métrica buena hoy se degrada en tres meses sin seguimiento. Una rutina de gestión de sitios monitorea las tres métricas de forma continua y corrige antes de que Search Console reclame.
Por dónde empezar esta misma semana
Ese sitio que abre rápido en su portátil sigue engañándolo. El usuario del 4G, en el Android de gama media, siente cada segundo de LCP y cada botón que no responde. Y Google mide todo eso en campo, todos los días, con datos de gente real.
Ahora usted sabe leer esos números. Tres cosas para llevarse de aquí:
- El dato de campo manda. El bloque de usuarios reales de PageSpeed Insights y el informe de Search Console son los números que entran en el posicionamiento. La prueba de laboratorio sirve para diagnóstico, nunca para celebrar.
- Imágenes y scripts resuelven la mayor parte. Compresión a WebP, caché y limpieza de Tag Manager bajan el LCP en días, sin reescribir el sitio.
- El cuello de botella estructural pide ingeniería. Servidor lento, tema pesado y código heredado no se arreglan con un plugin. Ahí el camino es un proyecto de optimización de sitios con responsable y plazo.
El paso de mañana cabe en 15 minutos: ejecute PageSpeed en la página que más clics pagos recibe, capture la pantalla del dato de campo y llévela a la reunión con el equipo. Si nadie del otro lado de la mesa sabe responder quién monitorea esto todos los meses, el problema es de gestión de sitios, y no se resuelve solo.
En SP Labor, este trabajo llevó el PageSpeed a 97 en móvil y 99 en escritorio. El método existe, y es replicable.
¿Quiere saber dónde está perdiendo ingresos su sitio por rendimiento? Hable con un Experto y reciba un diagnóstico de su caso, sin compromiso.
Los Core Web Vitals miden una sola cosa: el respeto de su sitio por el tiempo de quien paga sus cuentas.
Preguntas frecuentes
¿Qué son los Core Web Vitals?
Son las tres métricas oficiales que Google usa para medir la experiencia de usuarios reales en su sitio: LCP mide la velocidad de carga, INP mide el tiempo de respuesta al clic y CLS mide la estabilidad visual de la página. Los datos vienen de visitantes reales en Chrome, entran en el algoritmo de posicionamiento y aparecen en Search Console.
¿Cuáles son las metas de Google para cada métrica?
LCP hasta 2,5 segundos, INP hasta 200 milisegundos y CLS hasta 0,1. Google evalúa el percentil 75, es decir, el 75% de las visitas necesita quedar dentro de la meta. Por encima de eso la página entra en la franja "necesita mejorar" o "mala", y usted lo ve agrupado por URL en el informe Core Web Vitals de Search Console.
¿Los Core Web Vitals afectan al posicionamiento en Google?
Sí, son un factor de posicionamiento confirmado, aunque el contenido y la autoridad pesan más. En la práctica, el impacto mayor suele ser indirecto: una página lenta aumenta el abandono incluso antes de que el contenido aparezca. Google midió que el 53% de los usuarios móviles desiste cuando la carga pasa de 3 segundos, lo que derriba la conversión de tráfico pago y orgánico al mismo tiempo.
¿Cuál es la diferencia entre datos de campo y de laboratorio?
Los datos de campo vienen de usuarios reales de Chrome en los últimos 28 días, con el móvil y la conexión que realmente tienen. Ese es el dato que Google usa. Los datos de laboratorio son una simulación hecha en el momento de la prueba, útil para diagnosticar la causa, pero no representa la experiencia real. En PageSpeed Insights, el bloque de arriba es campo, el de abajo es laboratorio.
¿Por qué mi sitio me parece rápido pero reprueba en los Core Web Vitals?
Porque usted lo prueba en el portátil, con wifi corporativo y la caché llena de la navegación anterior. Su cliente llega por 4G, en un Android de gama media, cargando todo desde cero. Las métricas de campo capturan ese escenario, su prueba manual no. Si Search Console señala URLs reprobadas, confíe en el informe, refleja a quien realmente visita.
¿Cómo mejorar el LCP rápidamente?
Empiece comprimiendo imágenes a WebP, activando caché y eliminando scripts abandonados en Tag Manager. Solo la compresión de imágenes suele bajar el LCP de forma visible: en el proyecto de SP Labor, 6.433 imágenes pasaron de 4,0 GB a 1,4 GB y el PageSpeed llegó a 97 en móvil. El servidor lento y la fuente que bloquea la renderización son los pasos siguientes.
¿Cuánto tardan los Core Web Vitals en actualizarse después de la corrección?
El dato de campo considera una ventana móvil de 28 días, así que la mejora aparece de forma gradual en Search Console y en PageSpeed Insights. Las correcciones aplicadas hoy empiezan a mover el informe en una o dos semanas y se consolidan en cerca de un mes. Use la prueba de laboratorio para validar en el momento si la corrección funcionó técnicamente.
