Core Web Vitals en 2026: checklist real para auditar tu web

Qué son LCP, CLS e INP, qué umbrales importan de verdad y cómo auditar el rendimiento de tu web paso a paso, sin depender solo de herramientas automáticas.

Cada vez que audito una web nueva, hay una conversación que se repite: «la web va rápido, la he probado yo mismo». El problema es que «rápido para mí» y «rápido según las métricas que Google usa para posicionar» son cosas completamente distintas. Los Core Web Vitals no miden si tu conexión es buena — miden la experiencia real que va a tener la mayoría de tus visitantes, con sus dispositivos y sus conexiones, no la tuya.

Esto es lo que de verdad hay que revisar, y en qué orden.

Qué son los Core Web Vitals (y por qué son factor de ranking directo)

Son tres métricas que Google usa para medir la experiencia de carga y de interacción de una página, y las tres influyen directamente en el posicionamiento, no solo en la percepción del usuario:

  • LCP (Largest Contentful Paint): tiempo hasta que se carga el elemento visual más grande de la pantalla (normalmente una imagen o un bloque de texto). Umbral: por debajo de 2,5 segundos.
  • CLS (Cumulative Layout Shift): cuánto «salta» el contenido mientras carga la página (por ejemplo, cuando un botón se mueve porque un anuncio carga tarde). Umbral: por debajo de 0,1.
  • INP (Interaction to Next Paint): tiempo que tarda la página en responder tras una interacción del usuario (clic, tap). Umbral: por debajo de 200 milisegundos.

Estas métricas sustituyeron a FID (First Input Delay) en 2024 — si sigues viendo referencias a FID en herramientas o artículos, es información desactualizada.

Por qué «se ve rápido» no significa que cumpla los umbrales

Tu percepción al navegar por tu propia web está sesgada por varios factores que no representan a la mayoría de tus visitantes:

  • Tu conexión a internet probablemente es mejor que la media de tus usuarios
  • Tu navegador puede tener contenido cacheado de visitas anteriores
  • Es fácil no notar un CLS pequeño si ya sabes dónde va a aparecer cada elemento

Por eso la auditoría no puede basarse en «he entrado y me ha parecido rápido» — necesita datos medidos, no percepción.

Checklist de auditoría, paso a paso

1. Mide con datos de campo, no solo de laboratorio

PageSpeed Insights y Search Console → Core Web Vitals te dan datos de campo (usuarios reales, con sus dispositivos y conexiones reales) — son los que realmente afectan al ranking. Herramientas como Lighthouse dan datos de laboratorio (una simulación en condiciones controladas) — útiles para diagnosticar, pero no son lo que Google usa para posicionar.

2. Identifica qué está causando un LCP alto

Las causas más comunes, en orden de frecuencia:

  • Imágenes sin comprimir o sin formato moderno (usa WebP o AVIF en vez de JPG/PNG sin optimizar)
  • Fuentes web que bloquean el renderizado hasta que cargan
  • Scripts de terceros (chats, píxeles de tracking, widgets) que se cargan antes que el contenido principal
  • Servidor de hosting lento en el primer byte de respuesta (TTFB)

3. Revisa qué causa saltos de layout (CLS)

  • Imágenes o vídeos sin dimensiones (width/height) definidas en el HTML, que hacen que el espacio se ajuste cuando terminan de cargar
  • Anuncios o banners insertados dinámicamente sin reservar su espacio de antemano
  • Fuentes web que sustituyen a una fuente de sistema y cambian el tamaño del texto al cargar

4. Diagnostica la interactividad (INP)

  • JavaScript excesivo o mal optimizado que bloquea el hilo principal del navegador
  • Demasiados scripts de terceros ejecutándose simultáneamente
  • Animaciones o efectos visuales pesados que consumen recursos justo cuando el usuario interactúa

5. Prioriza por impacto, no por facilidad

No arregles primero lo que sea más fácil de tocar — arregla primero lo que más usuarios reales estén experimentando mal, según los datos de campo de Search Console. Un problema de CLS que solo afecta al 2% de las sesiones no es la prioridad si tu LCP falla en el 40% de las visitas móviles.

Errores comunes en las auditorías de rendimiento

  1. Optimizar solo la home y no las páginas de destino de campañas de pago o las de mayor tráfico orgánico.
  2. Medir solo en escritorio cuando la mayoría del tráfico suele ser móvil, y móvil casi siempre tiene peores métricas.
  3. Instalar un plugin de «optimización» sin medir el antes y el después — algunos ayudan, otros añaden más peso del que quitan.
  4. Confundir una puntuación alta en Lighthouse con buen rendimiento real — repito el punto porque es el error más frecuente que veo: Lighthouse es un dato de laboratorio, no de campo.

Los Core Web Vitals no se arreglan con una única acción — se diagnostican midiendo con datos reales de usuarios, se priorizan según impacto real, y se corrigen atacando la causa (imágenes, scripts de terceros, JavaScript) en vez de síntomas superficiales. Es una de las pocas áreas de SEO donde una auditoría técnica bien hecha puede mostrar mejoras medibles en semanas, no meses.

Si quieres ver cómo conecto el rendimiento técnico con el resto de la estrategia de adquisición, puedes leer la guía completa de SEO o escribirme directamente.

Deja un comentario