Qué es Core Web Vitals: guía para no técnicos
Core Web Vitals suena a jerga de auditoría, pero en realidad describe algo muy simple: cómo de rápida, estable y usable se siente tu web para una persona real.
El problema es que mucha gente oye siglas como LCP, INP o CLS, abre una herramienta y se bloquea. Esta guía está pensada justo para eso: entender qué significan, por qué importan y qué mirar primero sin convertirte en desarrollador.
TL;DR
- Core Web Vitals son tres métricas principales que Google usa para medir experiencia real de usuario.
- LCP mide cuándo se ve el contenido principal, INP cómo responde la web al interactuar y CLS cuánto se mueve el layout sin querer.
- No basta con pasar un test una vez: lo importante es vigilar la evolución en datos reales.
- Puedes empezar por el performance checker y luego pasar a seguimiento continuo si el rendimiento ya afecta a negocio.
Qué son exactamente los Core Web Vitals
Son un conjunto de métricas definidas por Google para medir experiencia de usuario en la web desde tres ángulos:
- Carga: cuándo percibes que la página principal ya está visible.
- Interactividad: cuándo la página responde de verdad a tus acciones.
- Estabilidad visual: si la página se mueve de forma molesta mientras la usas.
Google no los creó para fastidiar a los equipos técnicos. Los creó porque una web puede “cargar” y aun así sentirse lenta, torpe o inestable.
Las tres métricas que debes entender
LCP: Largest Contentful Paint
LCP mide cuándo aparece el elemento principal de contenido visible en pantalla.
Traducido: cuánto tarda la página en parecer realmente cargada.
Google considera, de forma orientativa:
- bueno: hasta 2,5 segundos,
- necesita mejora: entre 2,5 y 4 segundos,
- malo: más de 4 segundos.
Si el LCP va mal, el usuario siente que la página tarda demasiado en arrancar.
INP: Interaction to Next Paint
INP mide cuánto tarda la página en responder cuando alguien interactúa, por ejemplo:
- hace clic,
- toca un botón,
- abre un desplegable,
- o empieza a escribir.
Traducido: cuánto tarda la web en reaccionar de verdad.
Orientativamente:
- bueno: hasta 200 ms,
- necesita mejora: entre 200 y 500 ms,
- malo: más de 500 ms.
Si aquí fallas, la web parece torpe aunque “ya esté cargada”.
CLS: Cumulative Layout Shift
CLS mide cuánto se mueve el contenido de una página de forma inesperada mientras el usuario la está viendo.
Es lo que pasa cuando:
- vas a pulsar un botón,
- se carga una imagen tarde,
- aparece una barra,
- y de repente todo se desplaza.
Orientativamente:
- bueno: hasta 0,1,
- necesita mejora: entre 0,1 y 0,25,
- malo: más de 0,25.
Si el CLS es malo, la web transmite poca calidad y genera bastante fricción.
Por qué importan para SEO
No son el único factor de posicionamiento ni el más fuerte por sí solo. Pero sí son una señal clara de experiencia.
Importan porque:
- ayudan a Google a distinguir experiencias mejores y peores,
- afectan directamente a cómo se siente la web,
- y además tienen impacto en conversión, no solo en SEO.
Dicho claro: una web con malos Core Web Vitals puede no hundirse solo por eso, pero sí perder ventaja frente a otra que ofrece una experiencia claramente mejor.
La diferencia entre datos de laboratorio y datos reales
Aquí es donde más confusión hay.
Datos de laboratorio
Son tests simulados. Muy útiles para detectar problemas, pero no representan exactamente lo que viven tus usuarios.
Datos reales o de campo
Son datos recogidos de personas reales navegando por tu web en condiciones reales.
La diferencia importa mucho. Puedes tener:
- un test de laboratorio aceptable,
- y usuarios reales sufriendo una web lenta o inestable.
Por eso no basta con abrir una herramienta una vez y darlo por hecho. La parte interesante es vigilar cómo evoluciona el comportamiento real.
Umbrales que conviene tener en la cabeza
No necesitas memorizar media documentación de Google. Te basta con recordar esto:
| Métrica | Bueno | Necesita mejora | Malo |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 s a 4 s | > 4 s |
| INP | ≤ 200 ms | 200 ms a 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 a 0,25 | > 0,25 |
Eso ya te permite interpretar casi cualquier herramienta sin perderte.
Cómo medir Core Web Vitals sin complicarte
Opción 1. Revisión rápida
Empieza por el performance checker de Weaking. Te sirve para una foto inicial y para detectar si hay señales claras de problema.
Opción 2. Search Console
Search Console te ayuda a ver grupos de URLs con problemas y tendencias generales.
Opción 3. Monitoring continuo
Si ya dependes de la web para captar negocio, lo útil es no enterarte tarde. Ahí es donde el monitoring continuo tiene sentido, especialmente porque Weaking mete Real User Monitoring y no se queda solo en tests simulados.
Qué suele pasar en una PyME cuando salen mal
Normalmente no hay un único culpable. Lo habitual es una mezcla de:
- imágenes demasiado pesadas,
- plugins o scripts de terceros,
- hosting justo,
- plantillas que cargan más de la cuenta,
- y cambios que nadie revisa después.
Por eso es tan importante no mirar Core Web Vitals como un tema aislado del resto de la web.
Qué suele empeorar el LCP
Las causas típicas son:
- servidor lento,
- imágenes enormes,
- recursos críticos cargando tarde,
- demasiados scripts bloqueantes,
- o un hero principal demasiado pesado.
En una PyME, las dos primeras suelen ser responsables de más problemas de los que parece.
Cómo lo traduciría a lenguaje no técnico
Si el LCP va mal, el usuario siente que la web tarda demasiado en “arrancar de verdad”.
Qué suele empeorar el INP
Aquí el patrón cambia un poco. Suele fallar por:
- JavaScript pesado,
- eventos mal gestionados,
- widgets de terceros,
- sliders, chats o popups que bloquean,
- o páginas que intentan hacer demasiadas cosas a la vez.
Si el usuario toca algo y la web no responde, da igual que tu diseño sea precioso.
Cómo lo traduciría a lenguaje no técnico
Si el INP va mal, la web se siente pesada, lenta o torpe justo cuando alguien intenta hacer algo importante.
Qué suele empeorar el CLS
Muy habitual cuando:
- las imágenes no reservan espacio,
- se insertan banners o barras tarde,
- cambian tipografías y recolocan el texto,
- o se cargan módulos por encima del contenido ya visible.
Es una métrica muy molesta porque ataca la sensación de control del usuario.
Cómo lo traduciría a lenguaje no técnico
Si el CLS va mal, la web da sensación de improvisación. Parece que nada está quieto cuando toca interactuar.
Por dónde empezar si salen mal
No intentes arreglar los tres a la vez sin criterio. Prioriza así:
- corrige lo que afecta a las páginas más importantes,
- luego ataca el cuello de botella más repetido,
- y después valida si la mejora se mantiene.
Si falla LCP
Empieza por:
- imágenes principales,
- servidor,
- y recursos críticos del above the fold.
Si falla INP
Mira:
- scripts de terceros,
- widgets,
- elementos interactivos lentos,
- y JavaScript innecesario.
Si falla CLS
Revisa:
- tamaños reservados para imágenes,
- banners dinámicos,
- fuentes,
- y bloques que aparecen tarde.
Qué no haría para “mejorarlos”
Tampoco conviene caer en soluciones impulsivas:
- no eliminaría media web solo por subir una puntuación,
- no quitaría elementos útiles si el problema real es cómo cargan,
- y no perseguiría una nota perfecta si el cuello de botella comercial está en otro lado.
La prioridad es mejorar experiencia real donde más negocio se juega.
Cuándo conviene monitorizarlos y no solo medirlos
Medir una vez está bien. Monitorizar tiene sentido cuando:
- haces cambios frecuentes en la web,
- dependes de móvil,
- el equipo toca plantillas, plugins o scripts a menudo,
- o has tenido degradaciones que nadie vio venir.
En ese punto, los Core Web Vitals dejan de ser una auditoría y pasan a ser una métrica operativa.
El error más común: perseguir puntuaciones en vez de experiencia
Mucha gente quiere ver “verde” en una herramienta y ya.
Lo importante no es el color. Lo importante es:
- si la página principal carga con agilidad,
- si responde cuando alguien interactúa,
- y si deja de moverse sin control.
Cuando entiendes eso, las métricas dejan de ser una obsesión técnica y pasan a ser una guía útil.
Cuándo deja de ser un tema “nice to have”
Yo dejaría de tratarlo como secundario cuando:
- la web ya genera leads o ventas,
- hay caída clara en móvil,
- Search Console marca grupos de URLs afectadas,
- o cada deploy empeora algo y nadie se entera hasta tarde.
Ahí ya no es un “ya lo miraremos”. Es una parte del rendimiento del negocio.
Resumen
- Core Web Vitals mide carga, respuesta e inestabilidad visual.
- LCP, INP y CLS son fáciles de entender si los conectas con experiencia real.
- No son solo una cuestión técnica: afectan a SEO, conversión y percepción de calidad.
- Empieza por una revisión rápida y luego vigila evolución en datos reales.
- Si la web ya importa a nivel comercial, el seguimiento continuo vale más que una foto puntual.
Preguntas frecuentes
¿Core Web Vitals afecta de verdad al SEO?
Sí, pero no como único factor. Tiene más sentido verlo como una señal de experiencia que puede darte o quitarte ventaja frente a competidores similares.
¿Qué es más importante: LCP, INP o CLS?
Depende del tipo de problema, pero normalmente empezaría por el que más degrada la experiencia en páginas clave.
¿Una buena puntuación garantiza posicionar?
No. Ayuda, pero no sustituye contenido, relevancia, enlazado, autoridad ni una web técnicamente bien planteada en general.
¿Con PageSpeed basta?
Sirve para empezar, pero no siempre refleja lo que viven tus usuarios reales. Por eso tiene tanto valor el seguimiento continuo con datos de campo.
¿Qué hago primero si todo sale mal?
Empieza por las páginas que generan negocio, prioriza el cuello de botella dominante y vuelve a medir antes de tocar veinte cosas a la vez.