Las Core Web Vitals son las métricas que Google utiliza para representar tres aspectos fundamentales de la experiencia de una página web: qué tan rápido aparece su contenido principal, qué tan rápido responde a una interacción y qué tan estable permanece visualmente mientras carga.
Actualmente son tres: LCP, INP y CLS. No son un puntaje único ni equivalen al número de 0 a 100 que muestra Lighthouse en PageSpeed Insights.
Entender esta diferencia es importante porque un sitio puede obtener un excelente puntaje en una prueba de laboratorio y, al mismo tiempo, ofrecer una experiencia peor a una parte de sus usuarios reales.
¿Qué son las Core Web Vitals?
Core Web Vitals es un subconjunto de las Web Vitals de Google pensado para medir aspectos de la experiencia de usuario que pueden observarse de forma consistente en la web.
Las tres métricas actuales cubren carga, capacidad de respuesta y estabilidad visual:
| Métrica | Qué mide | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | Carga del contenido principal | ≤ 2,5 s | > 2,5 y ≤ 4 s | > 4 s |
| INP | Respuesta a las interacciones | ≤ 200 ms | > 200 y ≤ 500 ms | > 500 ms |
| CLS | Estabilidad visual | ≤ 0,1 | > 0,1 y ≤ 0,25 | > 0,25 |
Para considerar que una página ofrece una buena experiencia en estas métricas, Google recomienda alcanzar los valores “buenos” en el percentil 75 de las visitas, tanto en dispositivos móviles como en computadoras.
Podés consultar la definición vigente en la documentación oficial de Web Vitals.
LCP: ¿cuánto tarda en aparecer el contenido principal?
Largest Contentful Paint (LCP) mide cuánto tiempo pasa desde que comienza la navegación hasta que el navegador muestra el elemento de contenido visible más grande dentro de la pantalla.
En muchos sitios ese elemento es una imagen principal, un banner, una fotografía de producto o un bloque grande de texto.
Un buen LCP debe ser de 2,5 segundos o menos.
Causas frecuentes de un LCP alto
- respuesta lenta del servidor o TTFB elevado;
- imagen principal demasiado pesada;
- imagen LCP descubierta demasiado tarde por el navegador;
- CSS o JavaScript que bloquea el renderizado;
- fuentes web que retrasan la presentación del contenido;
- contenido principal generado tarde mediante JavaScript;
- falta de caché o una caché mal configurada.
Cómo mejorar LCP en WordPress
Primero conviene identificar cuál es realmente el elemento LCP. Si se trata de una imagen, debemos optimizar su peso, dimensiones y formato, pero también asegurarnos de que el navegador pueda descubrirla temprano.
Si el problema ocurre antes de que el navegador reciba el HTML, la prioridad cambia: hay que revisar hosting, PHP, base de datos, consultas, caché y recursos disponibles. Nuestra guía de velocidad de carga y web hosting profundiza en esa parte del proceso.
Un CDN como Cloudflare también puede reducir latencia y acelerar la entrega de recursos, aunque no reemplaza una aplicación o un servidor correctamente optimizados.
INP: ¿qué tan rápido responde la página?
Interaction to Next Paint (INP) mide la capacidad de respuesta de una página durante las interacciones del usuario. Observa clics, toques y pulsaciones de teclado y evalúa el tiempo que transcurre hasta que el navegador puede mostrar visualmente la respuesta.
Un buen INP debe ser de 200 milisegundos o menos.
INP es especialmente importante porque un sitio puede “verse cargado” pero sentirse pesado al abrir un menú, seleccionar una opción, agregar un producto al carrito o completar un formulario.
Causas frecuentes de un INP alto
- demasiado JavaScript ejecutándose en el navegador;
- tareas largas que bloquean el hilo principal;
- plugins o constructores que cargan código innecesario;
- scripts de terceros como chat, publicidad, mapas o herramientas de seguimiento;
- manejadores de eventos que realizan demasiado trabajo;
- actualizaciones complejas del DOM después de una interacción.
Tenemos una guía específica para medir y resolver problemas de INP donde explicamos cómo identificar interacciones lentas y reducir el trabajo que bloquea al navegador.
CLS: ¿el contenido se mueve mientras carga?
Cumulative Layout Shift (CLS) mide la inestabilidad visual inesperada. Es lo que percibimos cuando un botón, texto o imagen cambia de posición mientras intentamos leer o interactuar con la página.
Un buen CLS debe ser de 0,1 o menos.
Causas frecuentes de CLS
- imágenes o videos sin dimensiones reservadas;
- banners, avisos o formularios que aparecen empujando el contenido;
- fuentes que modifican el tamaño del texto cuando terminan de cargar;
- contenido insertado dinámicamente por plugins o scripts;
- anuncios sin espacio previamente reservado.
La solución suele consistir en reservar espacio desde el comienzo, definir correctamente dimensiones y evitar insertar contenido por encima de elementos que el usuario ya está viendo.
¿Qué pasó con FID?
Si leíste artículos anteriores sobre Core Web Vitals probablemente hayas encontrado FID (First Input Delay) en lugar de INP.
FID fue una Core Web Vital original, pero solamente medía el retraso de la primera interacción. Esa limitación podía ocultar problemas que aparecían más adelante durante el uso de la página.
INP reemplazó oficialmente a FID como Core Web Vital en marzo de 2024 y el soporte de FID fue posteriormente retirado de las herramientas de Chrome. Hoy la métrica que debemos optimizar para capacidad de respuesta es INP.
Este cambio es una de las razones principales por las que conviene desconfiar de guías antiguas de Core Web Vitals que todavía presentan FID como una de las métricas actuales.
FCP, TTFB y TBT: útiles, pero no son Core Web Vitals
PageSpeed Insights y otras herramientas muestran muchas métricas adicionales. Que no sean Core Web Vitals no significa que debamos ignorarlas.
| Métrica | Para qué sirve |
|---|---|
| FCP | Indica cuándo aparece el primer contenido visible. Ayuda a entender la percepción inicial de carga. |
| TTFB | Mide cuánto tarda en llegar el primer byte de respuesta. Es muy útil para detectar problemas de servidor, caché o latencia. |
| TBT | Mide cuánto tiempo queda bloqueado el hilo principal durante la carga. Lighthouse lo utiliza como indicador de laboratorio relacionado con problemas que también pueden afectar INP. |
Un detalle importante: Lighthouse no puede medir INP de la misma forma que los datos reales porque una auditoría automática no utiliza la página como lo hace una persona. Por eso muestra Total Blocking Time (TBT) como una métrica de laboratorio útil para diagnosticar capacidad de respuesta. TBT puede correlacionarse con INP, pero no es un reemplazo directo.
Datos de campo vs. datos de laboratorio
Para interpretar correctamente Core Web Vitals debemos distinguir dos fuentes de información.
| Datos de campo | Datos de laboratorio | |
|---|---|---|
| Origen | Usuarios reales | Prueba controlada o simulada |
| Ejemplo | CrUX | Lighthouse |
| Ventaja | Reflejan la experiencia real | Permiten repetir pruebas y diagnosticar |
| Limitación | Necesitan suficiente tráfico y reflejan un período | No representan todos los dispositivos, redes y comportamientos reales |
Chrome UX Report (CrUX) reúne datos de experiencia de usuarios reales de Chrome que cumplen los criterios de inclusión de Google. No es una medición de todas las visitas de nuestro sitio ni reemplaza a Google Analytics.
En PageSpeed Insights, los datos de campo se agregan sobre una ventana móvil de los 28 días anteriores. Si no hay suficiente información para una URL concreta, PageSpeed puede mostrar datos agregados del origen cuando están disponibles.
Si querés profundizar en esta diferencia, nuestro artículo ¿por qué mi sitio sigue lento si PageSpeed da buen puntaje? explica por qué una buena prueba de Lighthouse puede coexistir con una experiencia real deficiente.
Cómo medir las Core Web Vitals
PageSpeed Insights
PageSpeed Insights es el punto de partida más sencillo. Combina datos reales de CrUX, cuando existen, con una auditoría de laboratorio de Lighthouse.
La sección de experiencia de usuarios reales debe interpretarse por separado de la puntuación de rendimiento de Lighthouse. El número grande de 0 a 100 no es “la nota de Core Web Vitals”.
Google Search Console
El informe de Core Web Vitals de Search Console permite detectar grupos de páginas con problemas similares. Es especialmente útil para descubrir que una plantilla, categoría o familia completa de URLs comparte un problema.
Search Console utiliza datos de campo y agrupa URLs que ofrecen experiencias similares. Por eso no debemos interpretar cada fila como una prueba individual ejecutada en ese momento.
CrUX Vis
CrUX Vis permite visualizar la evolución histórica de los datos reales de CrUX. Es muy útil para comprobar si una mejora técnica está produciendo una tendencia sostenida en LCP, INP o CLS.
Sus datos históricos se actualizan semanalmente y muestran períodos móviles de 28 días, lo que ayuda a observar tendencias en lugar de depender de una fotografía aislada.
Chrome DevTools y Lighthouse
Para diagnosticar causas concretas necesitamos herramientas de laboratorio. Chrome DevTools permite analizar solicitudes de red, tareas largas, JavaScript, renderizado y elementos responsables de las métricas. Lighthouse ayuda a detectar oportunidades de mejora y regresiones de rendimiento.
La mejor práctica no es elegir entre datos reales o laboratorio: utilizamos datos de campo para descubrir qué está fallando y herramientas de laboratorio para investigar por qué.
¿Las Core Web Vitals afectan al SEO?
Sí, Google indica que las Core Web Vitals son utilizadas por sus sistemas de ranking como parte de las señales relacionadas con la experiencia de página. Pero eso no significa que exista una “nota de velocidad” capaz de reemplazar la relevancia y calidad del contenido.
Google también aclara que no existe una única señal de experiencia de página y que obtener resultados perfectos en herramientas como Search Console o PageSpeed no garantiza alcanzar las primeras posiciones.
Por eso no recomendamos perseguir un 100 en Lighthouse a cualquier costo. El objetivo debe ser ofrecer una experiencia rápida, estable y fácil de usar a personas reales.
Podés consultar la explicación oficial en la documentación de experiencia de página de Google Search.
Cómo mejorar Core Web Vitals en WordPress
No existe un plugin que resuelva todos los casos. La optimización correcta depende de cuál de las tres métricas falla y de la causa real.
Si falla LCP
- medir TTFB y verificar si el servidor responde rápido;
- utilizar caché de página correctamente configurada;
- optimizar la imagen principal sin aplicar lazy loading al elemento LCP cuando eso retrasa su descubrimiento;
- reducir CSS y JavaScript bloqueante;
- revisar fuentes y recursos críticos;
- utilizar CDN cuando ayude a acercar recursos a los visitantes.
Si falla INP
- reducir JavaScript innecesario;
- eliminar plugins que duplican funciones o cargan recursos en páginas donde no se necesitan;
- revisar scripts de terceros;
- dividir tareas largas;
- evitar procesos excesivos en eventos como clics, cambios de variantes o formularios.
Si falla CLS
- definir dimensiones o proporciones para imágenes y videos;
- reservar espacio para banners y contenido dinámico;
- cargar fuentes de forma que reduzca cambios de tamaño;
- evitar insertar elementos por encima del contenido ya visible.
En WordPress, una regla sencilla suele dar buenos resultados: cada plugin, widget, fuente, píxel o integración debe justificar el trabajo adicional que agrega. Un sitio más simple de ejecutar es más fácil de mantener rápido.
Un método práctico para trabajar con Core Web Vitals
- Detectá el problema con datos reales. Revisá PageSpeed Insights y Search Console.
- Identificá la métrica. No optimices “velocidad” en abstracto: separá LCP, INP y CLS.
- Reproducí y diagnosticá. Utilizá Lighthouse y Chrome DevTools sobre una URL representativa.
- Corregí la causa, no solamente el síntoma. Si el problema es TTFB, optimizar JavaScript puede no cambiar nada. Si es INP, cambiar de CDN puede no resolverlo.
- Probá más de una plantilla. Homepage, artículo, landing, producto y checkout pueden comportarse de forma muy diferente.
- Volvé a medir. Las pruebas de laboratorio permiten comprobar el cambio inmediatamente.
- Esperá la validación de campo. Los datos de CrUX utilizan una ventana móvil, por lo que la mejora real aparece gradualmente.
Preguntas frecuentes sobre Core Web Vitals
¿Cuáles son las Core Web Vitals actuales?
Son LCP, INP y CLS. LCP mide carga, INP capacidad de respuesta y CLS estabilidad visual.
¿FID sigue siendo una Core Web Vital?
No. INP reemplazó a FID en marzo de 2024 y hoy es la métrica vigente para evaluar capacidad de respuesta.
¿FCP es una Core Web Vital?
No. FCP es una métrica útil para diagnosticar la percepción inicial de carga, pero no forma parte de las tres Core Web Vitals actuales.
¿Un puntaje 100 en PageSpeed significa que apruebo Core Web Vitals?
No necesariamente. El puntaje de Lighthouse es una medición de laboratorio. La evaluación de Core Web Vitals que muestra PageSpeed puede utilizar datos reales de CrUX de los últimos 28 días.
¿Por qué no aparecen datos reales para mi URL?
CrUX necesita suficiente volumen de datos elegibles. Algunas URLs no alcanzan ese umbral aunque el sitio completo sí tenga información disponible. En esos casos PageSpeed puede mostrar datos del origen o indicar que no hay datos de campo suficientes.
Core Web Vitals como herramienta, no como objetivo aislado
Core Web Vitals nos da una forma objetiva de detectar experiencias lentas, interacciones pesadas y movimientos inesperados de contenido. Su mayor valor no está en obtener tres indicadores verdes, sino en ayudarnos a comprender dónde nuestros usuarios encuentran fricción.
Si administrás WordPress, conviene revisar estas métricas junto con la calidad del hosting, la caché, los plugins activos y los recursos que realmente necesita cada página.
Si sos cliente de Duplika y necesitás ayuda para encontrar la causa de un problema de rendimiento, nuestro equipo puede ayudarte a analizarlo. También podés conocer nuestro servicio de mantenimiento de WordPress.