El impacto real de los Core Web Vitals en su facturación

Los Core Web Vitals suelen debatirse casi exclusivamente como un aspecto de SEO. Ese enfoque desvirtúa su verdadero valor: como señal de posicionamiento son un factor secundario —Google lo ha confirmado expresamente y una página más lenta pero con la respuesta más relevante superará a una página rápida con contenido deficiente.

La razón fundamental para optimizarlos es la conversión. Un usuario que abandona el sitio web antes de que la página termine de renderizarse convierte al 0%, y ninguna posición en buscadores puede compensar esa pérdida.

A continuación, analizamos qué miden estas tres métricas, cuáles son las causas reales de puntuaciones deficientes y qué optimizaciones conviene priorizar.

Las tres métricas clave

Largest Contentful Paint (LCP)

El momento en que el elemento visible más grande finaliza su renderizado. Habitualmente es la imagen principal (hero), el encabezado H1 o un bloque de texto destacado.

• Excelente: menos de 2,5 segundos
• Requiere mejora: entre 2,5 y 4,0 segundos
• Deficiente: más de 4,0 segundos

El LCP es el indicador más fiel de cuándo una página resulta útil para el usuario. Es la primera métrica que debe optimizarse.

Cumulative Layout Shift (CLS)

La estabilidad visual del contenido durante la carga. Una experiencia habitual: va a pulsar un enlace, se carga un anuncio superior de forma tardía, el contenido se desplaza y termina haciendo clic en un elemento no deseado.

• Excelente: inferior a 0,1
• Deficiente: superior a 0,25

El CLS suele ser la métrica más económica y rápida de corregir, ya que sus causas están perfectamente identificadas.

Interaction to Next Paint (INP)

El tiempo que tarda la página en responder visualmente tras la interacción del usuario. Sustituyó al First Input Delay (FID) en marzo de 2024 y su estándar es más estricto: mide todas las interacciones a lo largo de la sesión y no solo el primer clic.

• Excelente: menos de 200 ms
• Deficiente: más de 500 ms

Un mal resultado en INP casi siempre se debe a una sobrecarga de JavaScript que satura el hilo principal del navegador.

Datos de laboratorio frente a datos de campo

Esta diferencia genera confusión frecuente, por lo que conviene ser técnicamente precisos:

Datos de laboratorio (Lab data): es una simulación de carga en un entorno controlado (lo que ofrece Lighthouse en las Chrome DevTools). Son reproducibles y muy útiles para depurar código, pero no son los datos que Google utiliza para evaluar el posicionamiento.

Datos de campo (Field data): proceden del informe Chrome UX Report (CrUX), que recopila mediciones de usuarios reales de Chrome en una ventana móvil de 28 días. Estos son los datos que Google utiliza en sus algoritmos y los que se reflejan en Google Search Console.

Ambos suelen discrepar y, cuando lo hacen, los datos de campo representan la realidad. Un sitio web puede obtener una puntuación de 95 en Lighthouse en el equipo potente de un desarrollador y suspender en los datos de campo si la mayoría de los usuarios reales acceden desde dispositivos móviles de gama media bajo redes móviles congestionadas.

Conclusión práctica: optimice en función de los datos de campo y depure con datos de laboratorio. Recuerde que los datos de campo tienen inercia: una mejora técnica tardará hasta 28 días en reflejarse plenamente.

Nuestra herramienta gratuita de auditoría SEO analiza ambas dimensiones directamente desde la API oficial de Google PageSpeed Insights, permitiéndole contrastar dónde divergen en su dominio.

Causas principales de un LCP deficiente

Ordenadas por frecuencia habitual de incidencia:

1. Optimización y entrega de imágenes

En la mayoría de páginas, el elemento LCP es una imagen y suele tener un peso desproporcionado.

El patrón de error típico: un archivo JPEG de 700 KB a 3000 píxeles de ancho, mostrado en pantalla a 640 píxeles, servido sin atributos de prioridad y sin formatos de compresión modernos.

La solución técnica:

<picture>
  <source srcset="/hero-640.avif 640w, /hero-1280.avif 1280w" type="image/avif" />
  <source srcset="/hero-640.webp 640w, /hero-1280.webp 1280w" type="image/webp" />
  <img src="/hero-640.jpg" alt="…"
       width="640" height="480"
       fetchpriority="high" decoding="async" />
</picture>

Esta implementación resuelve cuatro factores críticos: AVIF y WebP reducen el tamaño del archivo entre un 50% y un 80% frente a JPEG manteniendo la calidad; srcset sirve a cada dispositivo el tamaño adecuado; width y height reservan el espacio en el layout (evitando también problemas de CLS); y fetchpriority="high" indica al navegador que descargue esta imagen de forma prioritaria sobre otros recursos secundarios.

Este último atributo suele ser el cambio individual con mayor retorno en una página web y no supone coste de infraestructura.

Nunca aplique loading="lazy" a la imagen que constituye el LCP. La carga diferida pospone la descarga, lo que perjudica directamente el elemento que se está midiendo. Aplique carga diferida únicamente a los recursos situados por debajo de la línea de flotación (below the fold) y cargue el elemento principal de forma inmediata.

2. Recursos que bloquean el renderizado

Cada hoja de estilo en el <head> bloquea la representación de la página hasta que se descarga y procesa. Lo mismo ocurre con los scripts síncronos.

El fallo recurrente son las peticiones en cadena:

/* en styles.css — genera una cadena bloqueante */
@import url('https://fonts.googleapis.com/css2?family=…');

El navegador debe descargar styles.css, procesarlo, descubrir la directiva @import, descargar el CSS de las fuentes tipográficas, procesarlo y, finalmente, descargar los archivos de las fuentes. Cuatro viajes de red (round trips) secuenciales antes de mostrar texto legible.

Incluya la llamada a las fuentes directamente en el <head> del HTML con directivas preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=…&display=swap" />

El parámetro display=swap es esencial: muestra el texto de inmediato con una tipografía del sistema de respaldo mientras se descarga la fuente web, evitando bloques de texto invisibles.

3. Tiempo de respuesta del servidor (TTFB)

Si el Time To First Byte (TTFB) supera los 600 ms, ningún ajuste posterior conseguirá una carga rápida. Las causas suelen ser predecibles: ausencia de capas de caché, servidores infradimensionados, consultas lentas a bases de datos en cada petición o una red CDN mal configurada que no sirve contenido estático desde el borde.

Para sitios web corporativos y de marketing, la generación estática (SSG) es la mejor solución: si el contenido no cambia por usuario, debe servirse como archivo estático desde disco o CDN y no ensamblarse en cada petición.

4. Sobrecarga de JavaScript

Un framework que descarga 400 KB de JavaScript para renderizar un documento de texto impone un coste innecesario. En un dispositivo móvil de gama media, el análisis y ejecución de ese volumen de código puede demorar más de un segundo antes de que la pantalla responda.

No se trata de prescindir de frameworks, sino de evitar frameworks renderizados íntegramente en cliente para contenidos que deberían servirse como HTML estático.

Causas principales de un CLS deficiente

Tres factores concentran prácticamente todos los problemas de desplazamiento visual:

Imágenes sin dimensiones explícitas. Sin los atributos width y height, el navegador no puede reservar el espacio en pantalla antes de descargar la imagen, provocando un salto brusco de todo el contenido inferior. Defina siempre ambos atributos en el HTML y configure height: auto en CSS para preservar la adaptabilidad responsiva.

Cambio de fuentes tipográficas (FOUT / FOIT). El texto se renderiza inicialmente con la fuente del sistema y, al descargarse la fuente web con métricas distintas, los párrafos se recolocan. Puede mitigarse con font-display: swap combinado con size-adjust en @font-face, o seleccionando tipografías de respaldo con proporciones geométricas equivalentes.

Contenido inyectado dinámicamente. Banners de cookies, barras promocionales o anuncios que se insertan en la parte superior del documento empujan el contenido hacia abajo. Reserve el espacio mediante contenedores con altura fija o sitúe estos avisos como capas superpuestas fijas fuera del flujo del documento.

Causas principales de un INP deficiente

El INP se degrada cuando el hilo principal del navegador está bloqueado por tareas pesadas:

• Tareas largas (Long Tasks): cualquier ejecución de JavaScript que supere los 50 ms bloquea la respuesta a eventos del usuario.
• Manejadores de eventos sobrecargados: lógica compleja ejecutada directamente dentro de eventos click o input.
• Scripts de terceros: herramientas analíticas, widgets de chat, mapas de calor y scripts de testing A/B compitiendo simultáneamente por el hilo principal.
• Re-renderizados excesivos: aplicaciones web que vuelven a procesar árboles de componentes completos ante cada pulsación de tecla.

Estrategias de corrección por orden de impacto:

1. Auditar scripts de terceros. La mayoría de webs conservan etiquetas analíticas obsoletas. Elimine los scripts que no aporten valor medible y cargue los restantes con defer o tras la interacción inicial del usuario.
2. Dividir tareas largas. Ceda el control al hilo principal mediante scheduler.yield() o setTimeout(…, 0) en operaciones complejas.
3. Aplicar debounce y throttle a manejadores de eventos. Especialmente en eventos input y scroll.
4. Trasladar cálculos pesados a Web Workers.

Plan de acción prioritario

Si dispone de tiempo limitado, ejecute las optimizaciones en este orden:

1. Comprimir y dimensionar la imagen LCP, añadiendo fetchpriority="high". Suele aportar la mayor mejora individual con apenas una hora de trabajo.
2. Añadir width y height a todas las imágenes. Resuelve la mayor parte de los problemas de CLS de inmediato.
3. Eliminar cadenas de @import bloqueantes. Mueva las tipografías al <head> con directivas preconnect.
4. Auditar y limpiar scripts de terceros no utilizados. Mejora simultáneamente INP y LCP.
5. Implementar carga diferida (loading="lazy") en imágenes secundarias. Nunca en el elemento hero.
6. Optimizar el TTFB si supera los 600 ms mediante caché o CDN.

Una consideración honesta sobre las puntuaciones

Obsesionarse con alcanzar una puntuación perfecta de 100 en Lighthouse suele ser un uso ineficiente de los recursos técnicos. La diferencia entre 85 y 100 rara vez modifica el comportamiento del usuario; la diferencia entre 35 y 75 transforma radicalmente la conversión y la facturación.

Alcance los umbrales «buenos» en los datos de campo para las tres métricas y dedique los esfuerzos posteriores a optimizar su embudo de conversión. El rendimiento técnico es un medio para generar ingresos, no un fin en sí mismo: una página extremadamente rápida con una propuesta comercial deficiente seguirá sin convertir.