CWV

Core Web Vitals — métricas de experiencia de carga, interacción y estabilidad visual

Por Yapci Bello ·

Las tres métricas de experiencia de usuario que Google mide con datos reales de navegación: LCP (velocidad de carga del elemento principal), INP (respuesta a la interacción) y CLS (estabilidad visual del diseño).

Qué agrupan exactamente

Core Web Vitals es el nombre que Google le puso a un conjunto pequeño de métricas de experiencia de usuario. La gracia no está en cada una por separado, sino en la idea de fondo: en lugar de valorar una web por lo bien construida que parece por dentro, se valora por lo que le pasa a la persona que la abre. Hoy son tres:

  • LCP, o cuánto tarda en pintarse el elemento visible más grande de la pantalla. Bueno por debajo de 2,5 segundos.
  • INP, o cuánto tarda la página en reaccionar de forma visible cuando pulsas o escribes. Bueno por debajo de 200 milisegundos. Sustituyó a FID en marzo de 2024.
  • CLS, o cuánto se mueve el contenido mientras carga. Bueno por debajo de 0,1.

Cada una responde a una pregunta distinta que cualquiera se hace sin saber que se la está haciendo: ¿ya se ve?, ¿me hace caso?, ¿se está quieto? Ese es todo el concepto. El resto son detalles de medición.

La lista no es eterna. Google ha ido cambiando qué métricas forman parte del grupo —la sustitución de FID por INP es el ejemplo más claro— y volverá a hacerlo cuando encuentre una forma mejor de medir lo mismo. Conviene tratar el nombre como una etiqueta que apunta a un conjunto variable, no como tres siglas grabadas en piedra.

De dónde salen los números

Aquí está la confusión que más veces he tenido que deshacer. Existen dos formas distintas de obtener estas métricas y no dicen lo mismo:

Datos de laboratorio. Una herramienta carga tu página en un entorno simulado, con una velocidad de red y un dispositivo definidos por la propia herramienta, y te da un resultado. Es reproducible, es inmediato y sirve para comparar dos versiones de la misma página mientras trabajas. Lo que no es, es la realidad.

Datos de campo. Son mediciones tomadas en navegadores de personas reales que han entrado en tu web, con su móvil, su conexión y su batería. Google los recopila en el informe público de experiencia de usuario de Chrome y los muestra agregados en Search Console. Son los que cuentan cuando se habla de Core Web Vitals «de verdad».

La diferencia deja de ser teórica en cuanto miras los dos números a la vez. En el sitio de un gabinete de logopedia lo comprobamos: el laboratorio daba 80 en móvil, una nota que en una reunión suena a suspenso, mientras los datos de usuarios reales pasaban las tres métricas con holgura —LCP 1,8 s, INP 133 ms y CLS 0—. Ese es exactamente el motivo por el que no se optimiza para la puntuación del laboratorio: la nota simulada estaba pidiendo trabajo que las personas que usaban la web no necesitaban.

Dos consecuencias prácticas más. La primera: los datos de campo se publican como ventana móvil de 28 días, así que un arreglo hecho hoy tarda semanas en verse reflejado del todo. La segunda: se evalúan por percentil 75, es decir, se exige que el 75 % de las visitas estén dentro del umbral bueno. No es una media; una minoría de visitas muy lentas puede tirar del percentil aunque la mayoría vaya fina.

Y hay un tercer detalle que descoloca a mucha gente: si una URL recibe pocas visitas, no hay datos de campo suficientes y Google agrupa la página con otras similares del sitio. Lo que ves entonces no es tu página, es su vecindario.

Cómo lo abordo al auditar

Mi orden de trabajo es casi siempre el mismo, y empieza por no mirar la nota.

Primero separo móvil de escritorio. Casi todos los problemas serios están en móvil y casi todos los informes bonitos se hacen en escritorio. Luego miro qué grupos de URL salen marcados en Search Console: la ficha de producto, el listado, el artículo del blog. Un sitio no tiene un problema de Core Web Vitals, tiene plantillas concretas con un problema concreto, y arreglar una plantilla arregla miles de páginas de golpe.

Con la plantilla identificada, bajo al laboratorio para entender la causa, y solo entonces toco código. Después toca esperar. Es la parte que peor se lleva en las reuniones: no hay forma de confirmar la mejora en dos días, porque la ventana de 28 días necesita llenarse de visitas nuevas.

Lo que me encuentro con más frecuencia no son webs mal programadas, sino webs bien programadas a las que se les han ido añadiendo capas: un banner de cookies, tres herramientas de medición, un chat, una fuente tipográfica externa, un carrusel de la página de inicio que nadie usa. Ninguna capa parece grave por sí sola. La suma sí lo es.

Cuando hay que priorizar entre las tres, uso una regla sencilla: el CLS es el más barato de arreglar, porque sus causas son pocas y conocidas; el LCP es el que más impacto tiene en la percepción de velocidad, porque es el que decide si la web se siente rápida. No compiten: se suelen atacar en ese orden.

Por qué le importa a un negocio

Por dos motivos, y en este orden.

El primero es que son un factor de posicionamiento real, pero modesto. Google lo ha dicho con bastante honestidad: la experiencia de página ayuda a desempatar entre contenidos de utilidad comparable, no coloca en primera posición a quien no la merece. Una web rapidísima con contenido flojo no gana. Una web con buen contenido y una experiencia penosa sí puede perder frente a un competidor equivalente.

El segundo es más importante que el primero y no tiene nada que ver con el buscador: la experiencia lenta o inestable hace que la gente se vaya antes de comprar. El valor de estas métricas está en que ponen número a algo que antes solo se comentaba en pasillo. Si un formulario tarda medio segundo en responder a cada pulsación, se abandona. Si el botón de comprar se mueve justo cuando vas a pulsarlo, se pulsa lo que no era.

Cuando hago la recomendación a un cliente, nunca la justifico por el SEO. La justifico por la analítica: mostrar que la plantilla más lenta es también la que peor convierte suele ser más convincente que cualquier gráfico verde y rojo.

Errores frecuentes

Confundir la puntuación de la herramienta con los Core Web Vitals. El número grande y redondo que da un análisis de rendimiento es una nota de laboratorio compuesta por varias métricas con pesos propios. No es lo que Google usa para evaluar tu sitio. Puedes tener esa nota mediocre y estar en verde en campo, y también lo contrario.

Optimizar la página de inicio y olvidar el resto. La portada suele ser la más cuidada y la que menos tráfico de entrada recibe desde el buscador. El dinero está en las plantillas de ficha, listado y artículo.

Medir en el ordenador del despacho. Un portátil bueno con fibra no se parece a un móvil de gama media con cobertura irregular. Si no fuerzas condiciones realistas, siempre vas a ver que todo va perfecto.

Tratar los umbrales como un aprobado o suspenso. Pasar de 2,6 a 2,4 segundos cambia el color del informe, pero apenas cambia la sensación de quien usa la web. Pasar de 6 a 3 segundos no aprueba y sin embargo transforma la experiencia. Persigue la mejora, no el color.

Esperar resultados inmediatos. Entre el despliegue del arreglo y la consolidación del dato de campo hay semanas. Quien no lo sabe revierte cambios buenos por impaciencia.

Dónde trato CWV a fondo

¿Quieres que lo implementemos por ti?

Yo diseño la estrategia; la ejecuta mi equipo en SMedialab, la agencia que cofundé en Tenerife.

Ir a SMedialab →

Buscador del sitio

Escribe al menos dos letras para buscar.