Core Web Vitals: las métricas que Google usa para rankear
Web Hosting
3

Velocidad percibida como factor de posicionamiento

Google asumió hace años que un sitio lento no es un buen sitio, por bueno que sea su contenido. Para medir eso de forma objetiva creó los Core Web Vitals, un conjunto de métricas que cuantifican la experiencia real del usuario: qué tan rápido aparece el contenido, qué tan estable es visualmente y qué tan ágil responde a las interacciones.

LCP — Largest Contentful Paint

Mide cuánto tarda en renderizarse el elemento visible más grande dentro del viewport. Suele ser una imagen hero, un banner o un bloque de texto destacado. Representa la percepción del usuario de "ya cargó la página".

  • Bueno: menos de 2,5 segundos.
  • Necesita mejora: entre 2,5 y 4 segundos.
  • Pobre: más de 4 segundos.

Para mejorarlo: optimiza imágenes (WebP o AVIF), precarga recursos críticos con <link rel="preload">, usa un CDN y reduce el tiempo de respuesta del servidor (TTFB).

CLS — Cumulative Layout Shift

Mide la estabilidad visual. Cuantifica cuánto se mueven los elementos después de cargarse. Es esa sensación frustrante de ir a pulsar un botón y que un anuncio aparezca justo encima desplazando todo.

  • Bueno: menor a 0,1.
  • Necesita mejora: entre 0,1 y 0,25.
  • Pobre: mayor a 0,25.

Para mejorarlo: define explícitamente width y height en imágenes y videos, reserva espacio para anuncios o iframes, evita inyectar contenido encima del existente y carga fuentes con font-display: optional o swap bien configurado.

INP — Interaction to Next Paint

Reemplazó al FID (First Input Delay) en marzo de 2024. Mide el retraso entre que el usuario interactúa (click, tap, tecla) y la siguiente vez que la pantalla se actualiza mostrando una respuesta. Refleja qué tan ágil siente el usuario tu sitio.

  • Bueno: menor a 200 milisegundos.
  • Necesita mejora: entre 200 y 500 ms.
  • Pobre: mayor a 500 ms.

Para mejorarlo: reduce el JavaScript que bloquea el hilo principal, divide tareas largas con requestIdleCallback o setTimeout, elimina librerías pesadas que no usas y aplica code splitting para cargar solo el JS necesario en cada vista.

Cómo medir estas métricas

  • PageSpeed Insights: pega tu URL y obtienes un informe con datos de campo (usuarios reales del último mes) y de laboratorio (simulación). Es el punto de partida recomendado.
  • Chrome DevTools: el panel Performance te permite grabar una navegación y ver el desglose exacto de LCP, CLS y tareas largas. Ideal para depurar.
  • Lighthouse: integrado en DevTools. Te da una puntuación y sugerencias accionables.
  • CrUX (Chrome User Experience Report): la base de datos pública con mediciones reales de usuarios de Chrome. PageSpeed lo consulta por detrás.
  • Search Console: en el informe de Experiencia de la página verás qué URLs fallan y por qué, agrupadas por patrón.

Datos de campo vs datos de laboratorio

Los datos de laboratorio son reproducibles y útiles para depurar, pero los que Google usa para rankear son los de campo, recolectados de usuarios reales con distintas conexiones y dispositivos. Siempre prioriza mejorar los datos de campo, aunque tu Lighthouse local diga que todo está perfecto.

Prioriza la experiencia móvil

Google usa principalmente los datos móviles para rankear. Un sitio que carga en 1 segundo en escritorio pero en 8 en móvil tiene problemas reales. Prueba siempre con throttling de red 4G y CPU media para acercarte a la experiencia de tus usuarios.