Es un proceso sistemático qué mide cada métrica, identificar cuál falla y aplicar las correcciones. Google los usa como señal de ranking.
Qué son los Core Web Vitals y por qué Google los mide
Son un conjunto de métricas para cuantificar la experiencia del usuario al cargar y usar una página web. Miden si la página carga rápido, responde a las interacciones y si los elementos visuales se mantienen estables durante la carga.
Un competidor con contenido similar pero mejor experiencia técnica sirve mejor al usuario, y Google premia eso con mejor posición.
Los datos que Google usa para evaluar estas métricas provienen del Chrome User Experience Report (CrUX). Tu sitio puede pasar todos los tests y aun así tener problemas si el rendimiento para móviles es deficiente.
Las tres métricas: qué mide cada una y cuáles son los umbrales
LCP — Largest Contentful Paint
El LCP mide cuánto tiempo tarda en renderizarse el elemento visual más grande en el viewport inicial de la página. Es la métrica más cercana a “¿cuándo el usuario ve algo útil?”
Umbrales de referencia:
- Bueno: menos de 2.5 segundos
- Necesita mejora: entre 2.5 y 4 segundos
- Malo: más de 4 segundos
INP — Interaction to Next Paint
En marzo de 2024, Google reemplazó el FID (First Input Delay) por el INP (Interaction to Next Paint) como métrica oficial de Core Web Vitals. Mientras el FID medía solo la primera interacción del usuario, el INP mide la capacidad de respuesta durante toda la sesión, registrando el tiempo que tarda la página en responder visualmente a cualquier interacción.
Umbrales de referencia:
- Bueno: menos de 200 milisegundos
- Necesita mejora: entre 200 y 500 milisegundos
- Malo: más de 500 milisegundos
CLS — Cumulative Layout Shift
El CLS mide la estabilidad visual de la página durante la carga: cuánto se desplazan los elementos en pantalla mientras el contenido termina de cargarse. Es lo que ocurre cuando intentas hacer clic en un botón y en el último momento un banner publicitario aparece encima y el botón se desplaza, haciendo que hagas clic en el lugar incorrecto.
Umbrales de referencia:
- Bueno: menos de 0.1
- Necesita mejora: entre 0.1 y 0.25
- Malo: más de 0.25
El CLS alto genera una experiencia de frustración específica que el usuario identifica como inestabilidad o poco profesionalismo del sitio.
Cómo medir tus Core Web Vitals actuales
Antes de optimizar, necesitas saber exactamente dónde está el problema. Estas herramientas cubren el diagnóstico completo.
Google Search Console — datos de campo reales
Search Console → Experiencia → Core Web Vitals es el punto de partida obligatorio. Muestra el estado de las métricas para grupos de URLs del sitio, basado en datos de usuarios reales de Chrome.
El informe agrupa las URLs en tres estados: Bueno, Necesita mejora, Malo. Para sitios con muchas URLs, prioriza las páginas con mayor tráfico orgánico.
PageSpeed Insights — diagnóstico por URL
Mejorar PageSpeed Insights empieza por entender lo que la herramienta realmente te dice. Ingresa cualquier URL en pagespeed.web.dev y obtienes: datos de campo (si hay suficiente volumen de usuarios) y datos de laboratorio. Los datos de campo son los que importan para el ranking.
Chrome DevTools — diagnóstico técnico profundo
Para quien necesita entender, el panel de Performance registra una filmación completa de la carga de la página. El waterfall de carga revela exactamente qué recursos bloquean el renderizado, cuánto tiempo toma y en que orden se procesa.
Cómo mejorar el LCP: las acciones con mayor impacto
Optimiza la imagen o elemento LCP
El primer paso es identificar qué elemento es el LCP en tus páginas principales. PageSpeed Insights lo señala explícitamente en el diagnóstico. En la mayoría de sitios empresariales es una imagen de cabecera.
Una vez identificado, aplica estas optimizaciones en orden:
Convierte a formato WebP. Esa reducción de peso tiene impacto directo en el tiempo de descarga y por tanto en el LCP. En WordPress, plugins como ShortPixel o Imagify automatizan la conversión. En desarrollos custom, la conversión se hace en el pipeline de assets o directamente en el servidor.
Agrega fetchpriority="high" al elemento LCP. Este atributo HTML le indica al navegador que descargue ese recurso con prioridad máxima antes que otros elementos.
Usa <link rel="preload"> para el recurso LCP. Hace que el navegador descubra y empiece a descargar el recurso LCP antes de procesar el resto del HTML.
Mejora el TTFB (Time to First Byte)
El TTFB es el tiempo que tarda el servidor en responder la primera solicitud del navegador.
Las causas más frecuentes de TTFB alto: hosting compartido, falta de caché del servidor, consultas de base de datos no optimizadas y ausencia de CDN.
La solución de mayor impacto para la mayoría de sitios WordPress: migrar a hosting administrado con mejor infraestructura y activar Cloudflare como CDN y capa de caché. Esa combinación puede reducir el TTFB de 1,200ms a menos de 200ms sin tocar una línea de código.
Elimina recursos que bloquean el renderizado
JavaScript y CSS cargados de forma sincrónica en el <head> bloquean el renderizado de la página hasta que terminan de descargarse y procesarse. Cada milisegundo de bloqueo se suma directamente al LCP.
La solución estándar: agregar defer o async a los scripts de JavaScript que no son críticos para el renderizado inicial, y cargar el CSS no crítico de forma asíncrona. En WordPress, WP Rocket y LiteSpeed Cache gestionan esto automáticamente con configuración desde el panel. En desarrollos custom, se configura a nivel de plantilla o de bundler.
Cómo mejorar el INP: reducir la latencia de interacción
El INP alto casi siempre apunta a JavaScript que monopoliza el hilo principal durante demasiado tiempo. El diagnóstico específico requiere el informe de Interacciones en PageSpeed Insights o el panel de Performance en DevTools, que muestra exactamente qué funciones de JavaScript se ejecutan durante las interacciones y cuánto tiempo ocupan.
Carga scripts de terceros de forma diferida. Google Tag Manager, el píxel de Meta, Hotjar, chat en vivo, herramientas de heatmaps: cada uno de estos scripts ejecuta código en el hilo principal. Cargarlos con defer o después del evento load de la página reduce su impacto en el INP sin afectar su funcionalidad.
Audita y elimina scripts innecesarios. Muchos sitios acumulan scripts de herramientas que se dejaron de usar pero cuyo código sigue cargando en cada visita. Una auditoría de los scripts activos via la pestaña Network de DevTools revela frecuentemente entre dos y cinco scripts huérfanos que pueden eliminarse sin consecuencias.
Divide las tareas JavaScript largas. Funciones que ejecutan más de 50ms en el hilo principal bloquean la respuesta a las interacciones del usuario durante ese tiempo. La solución técnica es dividirlas en tareas más pequeñas usando setTimeoutcon delay 0 o la API scheduler.yield(), permitiendo al navegador procesar las interacciones del usuario entre cada fragmento.
Cómo mejorar el CLS: estabilidad visual desde la carga
El CLS es la métrica más fácil de mejorar con cambios de HTML y CSS, sin modificaciones de infraestructura ni de arquitectura.
Define siempre dimensiones explícitas en imágenes y videos. El atributo width y height en cada elemento <img> y <video>permite al navegador reservar el espacio correspondiente antes de descargar el recurso, eliminando el salto visual que ocurre cuando el elemento carga y desplaza el contenido circundante.
html
<!-- Mal: sin dimensiones -->
<img src="hero.webp" alt="Descripción">
<!-- Bien: con dimensiones explícitas -->
<img src="hero.webp" alt="Descripción" width="1200" height="600">Preconecta a los orígenes de fuentes web. La etiqueta <link rel="preconnect"> para el dominio de la fuente reduce el tiempo de carga de la tipografía. Combinarla con font-display: swap en el CSS garantiza que el texto sea visible desde el inicio, aunque con la fuente de reserva, y evita que el reemplazo cause un CLS significativo.
Reserva espacio para contenido dinámico. Banners publicitarios, embeds de redes sociales y contenido que se inserta via JavaScript después de la carga inicial deben tener un contenedor con dimensiones mínimas definidas en CSS. Sin ese contenedor, cada inserción dinámica desplaza el contenido existente y suma al CLS.
El impacto real en SEO y conversiones
La relación entre velocidad de carga web y SEO es directa pero no absoluta. Los Core Web Vitals son un desempate: cuando dos sitios tienen contenido y perfil de enlaces equivalentes, el mejor rendimiento técnico obtiene la posición superior. En búsquedas muy competitivas, esa diferencia puede separar la primera posición de la quinta, que en términos de tráfico orgánico puede representar entre tres y diez veces más clics.
El impacto en conversiones es aún más documentado. Google y Deloitte publicaron investigaciones que muestran consistentemente que cada décima de segundo de mejora en el tiempo de carga se correlaciona con incrementos de entre 8% y 12% en tasas de conversión para sitios de ecommerce. Para servicios, el impacto es similar: un sitio que responde rápido transmite competencia y confianza antes de que el usuario lea una sola palabra.
Cuándo el problema es de arquitectura, no de optimización
Hay un límite a lo que las optimizaciones incrementales pueden lograr sobre una base arquitectónica deficiente.
La conversación correcta es evaluar una migración a una arquitectura más eficiente: Next.js con renderizado estático, por ejemplo, entrega puntuaciones de 90+ en Core Web Vitals prácticamente de forma nativa porque genera HTML estático que el navegador puede renderizar sin ejecutar JavaScript en el hilo principal.
En Somos Idle auditamos y optimizamos Core Web Vitals para empresas que necesitan mejorar su posicionamiento y la experiencia de sus usuarios con acciones técnicas concretas, no con reportes llenos de números sin plan de acción. Si quieres saber exactamente qué está frenando el rendimiento de tu sitio y cómo resolverlo, escríbenos en somosidle.com/contacto.