Core Web Vitals: qué miden LCP, INP y CLS y cómo mejorarlos

Qué son los Core Web Vitals

Son el subconjunto de métricas de rendimiento que Google considera esenciales para cualquier página. Cada una tiene tres franjas:

Una página "aprueba" cuando el 75 % de sus visitas, medidas por separado en móvil y en ordenador, está en la franja buena. INP sustituyó a FID (First Input Delay) como Core Web Vital en marzo de 2024; si una guía todavía habla de FID, está desactualizada.

Cuánto influyen en el posicionamiento

Google lo dice sin rodeos en su documentación sobre experiencia de página: los Core Web Vitals se usan en sus sistemas de ranking, pero la búsqueda siempre intenta mostrar el contenido más relevante, aunque la experiencia de la página sea mejorable. Y tener buenas notas en Search Console o en otras herramientas no garantiza posicionar arriba.

En la práctica: entre dos páginas igual de útiles, la más rápida tiene ventaja. Una página rápida que no responde a lo que busca la gente no la tiene. La velocidad, además, afecta a la conversión con independencia de Google.

Datos de campo y de laboratorio: por qué no coinciden

• Datos de campo. Salen del Chrome User Experience Report (CrUX): visitas reales de usuarios de Chrome, en una ventana móvil de 28 días. Son los que usa Google, y los ves en el informe de Core Web Vitals de Search Console y en la parte superior de PageSpeed Insights.
• Datos de laboratorio. Lighthouse carga la página una vez en condiciones simuladas (un móvil de gama media con una conexión limitada). Sirven para encontrar las causas, pero su puntuación de 0 a 100 no es lo que mide Google.

Una web nueva o con poco tráfico no tiene datos de campo: CrUX necesita un volumen mínimo de visitas. Mientras tanto, guíate por el laboratorio. Y ten en cuenta que INP no se puede medir en laboratorio, porque necesita interacciones reales; Lighthouse usa el Total Blocking Time (TBT) como aproximación.

LCP: cuánto tarda en verse lo principal

El elemento LCP suele ser la imagen principal o el titular de la página. Google divide su tiempo en cuatro partes: el tiempo hasta el primer byte (TTFB), el retraso hasta que empieza a descargarse el recurso, lo que tarda en descargarse y el retraso hasta que se pinta. Las causas habituales, por orden de frecuencia:

1. Recursos que bloquean el renderizado. Hojas de estilo y fuentes web que el navegador debe descargar antes de pintar nada. Las fuentes servidas desde otro dominio añaden conexiones extra. Solución: CSS crítico en línea, fuentes alojadas en tu propio dominio y precargadas, y font-display: swap.
2. Una imagen principal pesada o que se descubre tarde. Solución: comprímela, sírvela en WebP o AVIF al tamaño al que se muestra, añade fetchpriority="high" y nunca le pongas loading="lazy": Google advierte que retrasar la carga de la imagen LCP siempre empeora la métrica.
3. Un servidor lento. Si el TTFB supera los 0,8 s, el problema está antes del navegador: alojamiento, ausencia de caché o una aplicación que genera cada página desde cero. Solución: caché y CDN.
4. Contenido que depende de JavaScript. Si el titular se genera en el navegador, o se oculta hasta que un script lo hace aparecer con una animación, el LCP espera a que el JavaScript se descargue y se ejecute. Solución: renderizar en el servidor y mostrar el contenido desde el primer momento; si quieres animaciones, que no escondan lo principal.

Un ejemplo de nuestra propia web: el logo de la cabecera era un PNG de 1.024 × 1.024 píxeles y 133 KB que se mostraba a 40 píxeles. Lo sustituimos por una versión de 160 píxeles que pesa 11 KB: un cambio mínimo, y 122 KB menos que descargar en la primera visita a cualquier página.

INP: cuánto tarda la página en responder

INP registra la latencia de las interacciones durante toda la visita (clics, toques, teclas) y se queda con una de las peores. Casi siempre el culpable es el hilo principal del navegador ocupado con JavaScript cuando el usuario intenta hacer algo.

• Tareas largas. Cualquier tarea de JavaScript de más de 50 ms bloquea la respuesta. Divide el trabajo y cede el control al navegador entre partes.
• Scripts de terceros. Chats, gestores de etiquetas, pruebas A/B y píxeles de publicidad suelen ser los que más pesan. Cárgalos después de la interacción o del consentimiento, y quita los que nadie consulta.
• Demasiado JavaScript. Divide el código por páginas y no cargues en la home lo que solo se usa en el panel de administración.
• Un DOM enorme y actualizaciones que recalculan el diseño de toda la página una y otra vez.

CLS: cuánto se mueve el contenido

Ese momento en que vas a pulsar un enlace y el texto salta porque ha cargado un banner encima. Causas y soluciones:

• Imágenes, vídeos e iframes sin dimensiones. Declara width y height, o un aspect-ratio, para que el navegador reserve el hueco.
• Anuncios, incrustaciones y avisos que empujan el contenido, como un aviso de cookies insertado encima de la página. Reserva su espacio o muéstralos superpuestos.
• Fuentes web que cambian el tamaño del texto al cargar. Usa font-display y ajusta las métricas de la fuente de respaldo.
• Contenido insertado por encima del que ya se está leyendo. Añádelo debajo o como respuesta a una acción del usuario.

Cómo medirlos

• PageSpeed Insights: datos de campo arriba y diagnóstico de laboratorio abajo, con cada oportunidad de mejora y el ahorro estimado.
• Informe de Core Web Vitals de Search Console: agrupa las URLs de tu web por estado y te avisa cuando un grupo empeora.
• Chrome DevTools, panel de rendimiento: muestra LCP, INP y CLS en vivo mientras navegas por tu propia web.
• La biblioteca web-vitals, si quieres enviar las métricas de tus visitas reales a tu analítica.

Por dónde empezar

1. Abre el informe de Core Web Vitals de Search Console y empieza por el grupo de URLs de móvil en "deficiente".
2. Pasa una URL de ese grupo por PageSpeed Insights y fíjate en qué métrica falla.
3. Si es LCP, identifica el elemento LCP que señala Lighthouse y aplica la lista de arriba.
4. Si es INP, busca tareas largas y scripts de terceros.
5. Si es CLS, busca imágenes sin dimensiones y elementos que se insertan tarde.
6. Tras desplegar el cambio, espera: los datos de campo tardan hasta 28 días en reflejarlo del todo.

Fuentes

• web.dev: Web Vitals
• web.dev: cómo optimizar el LCP
• web.dev: Interaction to Next Paint (INP)
• web.dev: Cumulative Layout Shift (CLS)
• Google Search Central: la experiencia de página en los resultados de la Búsqueda de Google
• Ayuda de Search Console: informe de Core Web Vitals
• Chrome for Developers: Chrome UX Report (CrUX)