Google resume la experiencia de usuario de una página en tres métricas llamadas Core Web Vitals: cuánto tarda en verse el contenido principal (LCP), cuánto tarda en reaccionar cuando el usuario interactúa (INP) y cuánto se mueve el diseño mientras carga (CLS). Forman parte de las señales de experiencia de página que usa el buscador y, sobre todo, se correlacionan con algo que importa a cualquier negocio: que el visitante no se vaya. En esta guía verás qué mide cada una, cuáles son los umbrales vigentes y cómo corregir los problemas más frecuentes.
Las tres métricas y sus umbrales
| Métrica | Mide | Bueno | Necesita mejorar | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Carga del elemento principal | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP (Interaction to Next Paint) | Respuesta a interacciones | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Una página «aprueba» cuando el 75 % de las visitas (percentil 75) está en la zona buena en las tres métricas. Google lo evalúa por separado para móvil y ordenador. El INP sustituyó al antiguo FID en marzo de 2024.
Datos de campo frente a datos de laboratorio
- Campo (RUM): medidos en navegadores Chrome de usuarios reales y publicados en el informe CrUX durante una ventana de 28 días. Son los que usa Google. Los ves en PageSpeed Insights (sección superior) y en el informe «Métricas web principales» de Search Console.
- Laboratorio: una simulación con un dispositivo y una red concretos (Lighthouse, PageSpeed Insights en su parte inferior, nuestro test de velocidad web). Sirven para diagnosticar y comprobar cambios al momento.
Es normal que no coincidan. Un laboratorio no puede medir el INP real porque no hay usuario haciendo clic; en su lugar muestra el TBT (Total Blocking Time), que es un buen indicador aproximado.
LCP: que el contenido principal aparezca rápido
El elemento LCP suele ser la imagen de cabecera, la foto del producto o el primer bloque grande de texto. El tiempo total se reparte en cuatro fases: respuesta del servidor (TTFB), retraso hasta que empieza a descargarse el recurso, descarga del recurso y renderizado.
Cómo mejorarlo:
- Reduce el TTFB: caché de página, buen hosting, CDN.
- Descubre pronto la imagen: debe estar en el HTML como
<img>, no como fondo CSS ni cargada por JavaScript. - Dale prioridad:
fetchpriority="high"y sinloading="lazy". - Hazla ligera: tamaño correcto, WebP o AVIF,
srcsetpara móviles. - Evita CSS y JS que bloqueen el renderizado antes de que se pinte.
<img src="/img/hero-800.avif"
srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
sizes="100vw" width="1600" height="900"
fetchpriority="high" alt="Taller de carpintería en Valencia">INP: que la página responda al instante
El INP mide el tiempo desde que el usuario hace clic, toca o pulsa una tecla hasta que el navegador muestra el siguiente fotograma. Toma una de las peores interacciones de la visita, así que un solo menú lento lo estropea.
Causas típicas: JavaScript pesado en el hilo principal, scripts de terceros (chat, publicidad, mapas de calor), manejadores de eventos que hacen demasiado trabajo, y DOM enorme (miles de nodos, típico de page builders).
Cómo mejorarlo:
- Elimina o retrasa scripts de terceros que no aportan.
- Divide las tareas largas (más de 50 ms) y cede el control al navegador entre partes, por ejemplo con
await scheduler.yield()donde esté disponible o consetTimeout. - Da una respuesta visual inmediata (abrir el menú) y deja el trabajo pesado (analítica, peticiones) para después.
- Reduce el tamaño del DOM y evita recalcular el diseño en cada interacción.
CLS: que nada salte mientras carga
El CLS suma los desplazamientos inesperados del diseño. El caso clásico: vas a pulsar un botón y justo baja porque ha aparecido un banner encima.
Cómo mejorarlo:
- Pon
widthyheight(oaspect-ratio) en imágenes, vídeos e iframes. - Reserva espacio para anuncios, banners de cookies y widgets incrustados.
- No insertes contenido encima de lo ya visible salvo como respuesta a una acción del usuario.
- Usa
font-display: swapcon una fuente de reserva de métricas parecidas, osize-adjust, para que el cambio de fuente no mueva el texto. - Anima con
transformyopacity, no contop,heightomargin.
Cómo diagnosticar paso a paso
- Abre Search Console → Métricas web principales y localiza los grupos de URL con problemas (por ejemplo, todas las fichas de producto).
- Analiza una URL representativa en PageSpeed Insights: arriba los datos de campo, abajo las recomendaciones.
- Para INP, usa la extensión Web Vitals o el panel Performance de Chrome DevTools e interactúa con la página para ver qué interacción es lenta.
- Corrige primero lo que afecta a plantillas enteras (cabecera, ficha de producto), no a una sola página.
- Tras publicar, usa «Validar corrección» en Search Console y espera los 28 días de la ventana de datos.
Errores frecuentes
- Perseguir la nota de Lighthouse en lugar de los datos de campo.
- Aplicar lazy loading a la imagen principal.
- Ocultar el contenido hasta que carga una animación o un slider.
- Añadir un banner de cookies que empuja la página hacia abajo.
- Pensar que una web rápida en la fibra de la oficina lo es en un móvil de gama media con 4G.
Lista de comprobación
- LCP: imagen principal en HTML, con
fetchpriority="high", sin lazy loading y en formato moderno. - TTFB bajo gracias a caché y buen hosting.
- INP: scripts de terceros auditados, tareas largas divididas, DOM razonable.
- CLS: dimensiones en todos los medios, espacio reservado para banners, fuentes estables.
- Revisión mensual del informe de Search Console.
Para una visión más amplia de la optimización, consulta cómo acelerar una web y la guía de optimización de imágenes.