Casi todo el mundo con una web ha oído hablar de las Core Web Vitals, y casi nadie sabe exactamente qué miden. Se suelen resumir como "velocidad", pero eso es solo un tercio de la historia y probablemente el tercio menos interesante.
Son tres métricas, cada una responde a una pregunta distinta que se hace un visitante sin darse cuenta, y las tres tienen efecto directo sobre si esa visita se convierte en cliente o se vuelve a los resultados de búsqueda.
Las tres métricas, en cristiano
LCP: ¿cuándo veo algo útil?
El Largest Contentful Paint mide cuánto tarda en aparecer el elemento más grande de la parte visible: normalmente la imagen principal o el titular. No mide cuándo la página ha terminado de cargar del todo, sino cuándo el usuario percibe que ya hay algo.
Es la métrica que más se nota en la primera impresión. Si tarda, el visitante ve una pantalla en blanco y una parte se marcha antes de que aparezca nada.
INP: ¿responde cuando toco?
El Interaction to Next Paint mide cuánto tarda la página en reaccionar cuando alguien hace clic, escribe o toca. Sustituyó al antiguo FID en 2024, y el cambio fue a mejor: el FID solo miraba la primera interacción, mientras que el INP tiene en cuenta todas las de la visita.
Es la métrica que más frustra cuando va mal, y la más ignorada. Una web puede pintarse rapidísimo y luego quedarse pensando dos segundos cada vez que pulsas un botón. El usuario no dice "tiene mal INP": dice que la web va rara y no vuelve.
CLS: ¿se me mueve lo que estoy mirando?
El Cumulative Layout Shift mide cuánto salta el contenido mientras la página termina de cargar. Es lo que ocurre cuando vas a pulsar un enlace, entra una imagen sin espacio reservado, todo se desplaza y acabas pulsando otra cosa.
Parece un detalle estético y no lo es: en formularios y procesos de compra, un CLS alto se traduce directamente en errores del usuario y en abandonos.
Los umbrales que exige Google
| Métrica | Bien | Mejorable | Deficiente |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Un detalle importante: Google evalúa el percentil 75 de tus visitas reales. Es decir, no basta con que vaya bien en tu ordenador con fibra: tiene que ir bien para tres de cada cuatro visitantes, incluidos los que entran desde el móvil con mala cobertura.
Qué revisar primero según la métrica que falle
Si falla el LCP
- La imagen principal pesa demasiado. Es la causa más habitual con diferencia. Formatos modernos como WebP o AVIF, tamaños adecuados a cada pantalla y nada de servir una imagen de 3.000 píxeles a un móvil.
- No se prioriza lo que se ve primero. La imagen del encabezado debe cargarse con prioridad alta y sin lazy loading; lo de más abajo, al revés.
- Fuentes que bloquean el pintado. Precargar las tipografías críticas y usar font-display para que el texto se vea aunque la fuente aún no haya llegado.
- Servidor lento. Si el hosting tarda medio segundo en empezar a responder, ese medio segundo lo pagan todas las métricas.
Si falla el INP
- Demasiado JavaScript. Es casi siempre la causa. Cada script que se ejecuta ocupa el hilo principal, y mientras está ocupado la página no puede responder a nada.
- Scripts de terceros. Chats, mapas, píxeles de publicidad, widgets de reseñas. Suman rápido y suelen aportar menos de lo que cuestan. Conviene cargarlos con retraso o solo donde hagan falta.
- Animaciones mal hechas. Animar propiedades que obligan al navegador a recalcular la disposición es caro; animar transform y opacity lo compone la tarjeta gráfica y sale casi gratis.
Si falla el CLS
- Imágenes sin dimensiones. Poner width y height en cada imagen permite al navegador reservar el hueco antes de que llegue. Es la corrección más barata que existe.
- Anuncios o banners insertados sobre la marcha. Reservar su espacio desde el principio, aunque quede vacío un instante.
- Fuentes que cambian de tamaño al cargar. Ajustar las métricas de la fuente de reserva para que ocupe lo mismo que la definitiva.
Por qué esto se traduce en dinero
El efecto sobre el posicionamiento existe, pero es de desempate: entre dos páginas igual de buenas, gana la que ofrece mejor experiencia. El efecto grande está antes, en la conversión.
La cadena es sencilla y bastante inmediata: una página lenta pierde visitantes antes incluso de mostrarse; una página que no responde al primer toque genera desconfianza; y una página que se mueve mientras la usas provoca errores en formularios y carritos. Nada de eso aparece en un informe de posiciones, pero sí en las ventas.
Lo que no hay que hacer
Perseguir el 100 en PageSpeed Insights es una trampa clásica. Esa puntuación es de laboratorio, se calcula en condiciones simuladas y no es lo que Google usa para evaluarte. Se puede tener 100 en el test y malos datos reales, y al revés.
Lo que cuenta son los datos de campo: usuarios reales, dispositivos reales, redes reales. Si Search Console dice que tus URLs están en verde, estás bien aunque la puntuación de laboratorio sea un 87.
Conclusión
Las Core Web Vitals no son una lista de deberes técnicos: son la forma que ha encontrado Google de medir algo que siempre ha importado, que es si usar tu web resulta agradable o irritante.
Es también parte de lo que revisamos en cualquier proyecto de desarrollo web. Casi todo el trabajo está en unos pocos sitios previsibles: el peso de las imágenes, la cantidad de JavaScript y los espacios reservados en el diseño. Arreglar esos tres frentes suele bastar para pasar de rojo a verde, y el efecto se nota antes en las conversiones que en las posiciones.
Fuentes
- Google. Web Vitals. web.dev
- Google. Interaction to Next Paint (INP). web.dev
- Google Search Central. Understanding Core Web Vitals and Google search results. developers.google.com
- Chrome UX Report. Real-user experience data. developer.chrome.com