Cuando alguien dice “mi página va lenta”, normalmente está describiendo una sensación, no una métrica. Core Web Vitals existe justamente para convertir esa sensación en tres números que se pueden medir, comparar y arreglar. Si tu sitio pierde visitantes antes de que cargue el contenido principal, este es el punto de partida.
Las tres métricas que importan hoy
Según la documentación oficial de Google en web.dev, Core Web Vitals está compuesto actualmente por tres métricas, cada una con un umbral de “bueno”:
| Métrica | Qué mide | Umbral bueno |
|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en pintarse el elemento visible más grande (normalmente la imagen o el titular principal) | ≤ 2,5 segundos |
| INP (Interaction to Next Paint) | Cuánto tarda la página en responder visualmente a los clics, toques y pulsaciones del usuario | ≤ 200 milisegundos |
| CLS (Cumulative Layout Shift) | Cuánto se mueve el contenido de forma inesperada mientras se carga | ≤ 0,1 |
Dos aclaraciones que evitan malentendidos frecuentes:
- INP reemplazó a FID en marzo de 2024. Si tu agencia todavía te entrega informes con “First Input Delay”, está midiendo algo que Google ya retiró. INP es bastante más exigente: no mira solo el primer clic, sino la latencia de prácticamente todas las interacciones de la visita.
- Los umbrales se evalúan en el percentil 75 de las visitas reales. No basta con que cargue rápido en tu computador con fibra óptica; tiene que cargar rápido para 3 de cada 4 usuarios, incluyendo los que entran con un gama media por datos móviles.
Datos de laboratorio vs. datos de campo
Esta distinción es la que más confusión genera, y es la que decide si tu optimización sirvió o no.
- Datos de laboratorio (lab): una simulación. Lighthouse abre tu página en un entorno controlado y te da un puntaje. Es reproducible y sirve para diagnosticar, pero es una ficción: un solo dispositivo, una sola red, sin caché, sin extensiones.
- Datos de campo (field): mediciones reales de usuarios de Chrome que aceptaron compartir estadísticas, agregadas en el Chrome UX Report (CrUX). Es lo que Google usa para evaluar tu sitio.
El CrUX trabaja con una ventana móvil de 28 días. Eso significa que después de desplegar una mejora real no verás el cambio reflejado de inmediato: toma semanas que los datos nuevos desplacen a los viejos. Es normal y no es señal de que el trabajo haya fallado.
Por eso un puntaje de 100 en Lighthouse con datos de campo en rojo no es un éxito, es una alerta: estás optimizando para el simulador, no para tus usuarios.
Cómo medir sin complicarte
- PageSpeed Insights: pega tu URL y te muestra ambas cosas: datos de campo arriba (si tu sitio tiene tráfico suficiente para figurar en CrUX) y diagnóstico de laboratorio abajo. Empieza siempre aquí.
- Search Console → informe de Core Web Vitals: agrupa tus URLs por patrones y te dice qué plantillas completas están fallando. Mucho más útil que auditar página por página.
- La extensión Web Vitals de Chrome: te muestra las métricas mientras navegas tu propio sitio. Es la forma más rápida de detectar qué elemento concreto está causando el CLS.
Un consejo de trinchera: mide siempre en modo incógnito y con la red limitada (DevTools → Network → “Slow 4G”). Tu sitio cacheado en tu navegador habitual te va a mentir.
Qué arreglar primero, en orden de impacto real
No todas las correcciones valen lo mismo. Este es el orden que nos ha resultado más eficiente en proyectos de rediseño:
1. La imagen hero (ataca LCP)
En la mayoría de sitios corporativos y landings, el elemento LCP es la imagen grande de la cabecera. Tres acciones que suelen bastar:
- Servirla en WebP o AVIF, no en JPG de 2 MB exportado de Canva.
- Dimensionarla al tamaño en que realmente se muestra, con
srcsetpara móvil y escritorio. - No aplicarle
loading="lazy". Es el error más común: el lazy loading es excelente para todo lo que está debajo del pliegue, y contraproducente para la imagen principal, porque retrasa justo lo que define tu LCP. Para esa imagen usafetchpriority="high".
2. Reservar espacio para todo lo que carga después (ataca CLS)
El contenido que “salta” casi siempre viene de: imágenes sin atributos width y height, banners de cookies que se inyectan sobre el contenido, fuentes web que cambian el tamaño del texto al cargar, y anuncios o widgets de terceros.
Soluciones: define siempre dimensiones o aspect-ratio en CSS, usa font-display: swap con una fuente de respaldo de métricas similares, y reserva el contenedor de cualquier widget antes de que llegue.
3. Auditar el JavaScript de terceros (ataca INP)
INP es la métrica donde más sitios se caen hoy, y el culpable rara vez es tu código: son los scripts de terceros. Píxeles de seguimiento, chats en vivo, mapas de calor, tres herramientas de analítica distintas porque nadie quiso quitar la anterior.
Cada uno de esos scripts bloquea el hilo principal y retrasa la respuesta a los clics del usuario. Haz el inventario honesto: ¿alguien revisó en los últimos seis meses los datos de ese mapa de calor? Si la respuesta es no, bórralo. Lo que quede, cárgalo con defer o diferido hasta la primera interacción.
4. El servidor y el hosting
Si tu TTFB (tiempo hasta el primer byte) supera los 800 ms, ninguna optimización de frontend te va a salvar: estás empezando la carrera con casi un segundo de retraso. Aquí entran caché del lado del servidor, una CDN para servir estáticos desde un nodo cercano al usuario, y en muchos casos simplemente dejar un hosting compartido saturado.
¿Esto realmente mejora mi posicionamiento?
Seamos precisos, porque hay mucha exageración vendiéndose por ahí.
Google documenta en su guía de page experience que la experiencia de página —incluidos los Core Web Vitals— es una señal que su sistema considera, pero insiste en que el contenido relevante y de calidad sigue siendo lo determinante. Una página rapidísima que no responde a la intención de búsqueda no va a superar a una página más lenta que sí la responde.
Dónde sí hay un efecto directo e inmediato: en la conversión. Cada segundo de espera antes de que aparezca el contenido es una ventana para que el usuario vuelva a los resultados de búsqueda. Si inviertes en tráfico pagado, una web lenta significa que estás pagando por clics que nunca llegan a ver tu propuesta.
La forma correcta de plantearlo: la velocidad es un multiplicador del trabajo de contenido y SEO que ya estás haciendo, no un sustituto.
Un orden de trabajo realista
- Mide el estado actual en PageSpeed Insights y guarda la captura, con fecha. Sin línea base no hay forma de demostrar la mejora.
- Identifica en Search Console qué tipos de página fallan (plantilla de producto, blog, home), no URLs sueltas.
- Ataca primero imagen hero y CLS: es el mejor retorno por hora invertida.
- Haz la limpieza de scripts de terceros. Suele ser la decisión más incómoda y la más rentable.
- Vuelve a medir a las 4 semanas, cuando la ventana de CrUX ya refleje los cambios.
Cómo lo abordamos en MagicTools
En nuestros proyectos de diseño web a la medida tratamos el rendimiento como un requisito de construcción, no como un parche posterior. Es considerablemente más barato elegir desde el principio una arquitectura ligera, un sistema de imágenes bien resuelto y un stack de terceros mínimo, que rescatar después un sitio construido a punta de plantillas premium con doce plugins encima.
Si ya tienes un sitio en producción y sospechas que la velocidad te está costando clientes, el primer paso es honesto y gratuito: pasa tu URL por PageSpeed Insights y mira los datos de campo. Si están en rojo, ya sabes por dónde empezar la conversación.
¿Quieres que revisemos tu caso? Escríbenos con la URL de tu sitio y te decimos qué está frenando la carga y qué tan profundo es el arreglo, antes de que inviertas en un rediseño completo.