¿Qué son Core Web Vitals?

Conjunto de métricas de Google que miden experiencia real del usuario: LCP (velocidad de carga del contenido principal), CLS (estabilidad visual) e INP (respuesta a interacciones). Son factor de ranking oficial desde mayo 2021.

¿Cómo afectan las imágenes al LCP?

Las imágenes suelen ser el elemento LCP en la mayoría de páginas. Imágenes sin optimizar disparan el LCP por encima del umbral de 2.5s. Optimizar formato (WebP/AVIF), añadir fetchpriority="high" en la hero y usar preload mejora LCP entre 30-60%.

¿Por qué las imágenes causan CLS?

Cuando una imagen carga sin dimensiones declaradas (width y height), el navegador reserva 0 px y luego salta el layout al cargar. Declarar siempre width y height en el HTML elimina el 90% del CLS causado por imágenes.

¿Qué es fetchpriority="high" y cuándo usarlo?

Atributo HTML estándar desde Chrome 101 que sube la prioridad de carga de un recurso. Aplícalo SOLO a la imagen hero (above the fold). Usarlo en múltiples imágenes degrada el rendimiento.

¿Mejor Core Web Vitals mejora el SEO?

Sí. Desde mayo 2021 son factor de ranking oficial de Google. Sitios en "verde" (LCP < 2.5s, CLS < 0.1, INP < 200ms) tienen ventaja competitiva directa en rankings.

Cómo las Imágenes Afectan Core Web Vitals: Guía Técnica Completa

Google cambió las reglas del SEO. Con la introducción de Core Web Vitals como factor de ranking oficial desde 2021 (y actualizado en 2024 con la inclusión de INP), el buscador ya no solo evalúa si tu contenido es relevante, sino si es agradable de consumir. Si tu web es lenta o visualmente inestable, perderás posiciones independientemente de la calidad de tu contenido.

Tras analizar millones de sitios web a través del Chrome User Experience Report (CrUX), el patrón es claro e irrefutable: las imágenes mal gestionadas son responsables del 80% de los suspensos en Core Web Vitals. En este artículo diseccionamos técnicamente cómo tus archivos gráficos impactan LCP (Largest Contentful Paint) y CLS (Cumulative Layout Shift), las dos métricas más afectadas por imágenes, con datos oficiales de web.dev actualizados continuamente por Google. Para una guía completa de optimización de imágenes, consulta nuestro artículo sobre optimización de imágenes para SEO.

Core Web Vitals: Las 3 métricas que determinan tu ranking

Según web.dev (actualizado continuamente por Google), las Core Web Vitals actuales son:

LCP (Largest Contentful Paint): Velocidad de carga del elemento visual más grande
INP (Interaction to Next Paint): Capacidad de respuesta a interacciones (reemplazó a FID en marzo 2024)
CLS (Cumulative Layout Shift): Estabilidad visual del diseño

Dato clave: Google mide el percentil 75 de tus usuarios. Si el 25% de tus visitantes experimenta una web lenta, suspendes la métrica.

Umbrales oficiales Google

Métrica	Bueno	Necesita mejora	Deficiente
LCP	≤2.5s	2.5s - 4.0s	>4.0s
INP	≤200ms	200ms - 500ms	>500ms
CLS	≤0.1	0.1 - 0.25	>0.25

Importante: Para aprobar Core Web Vitals, debes cumplir con las 3 métricas simultáneamente en el percentil 75 de tus visitas.

LCP (Largest Contentful Paint): La primera impresión lo es todo

¿Qué mide exactamente el LCP?

El LCP registra el tiempo que tarda en renderizarse el elemento de contenido más grande visible en el viewport inicial. Según datos de web.dev, en el 90% de los sitios web ese elemento es una imagen:

Elementos candidatos a LCP:

Imágenes <img> (caso más común)
Elementos <image> dentro de <svg>
Elementos <video> (imagen póster o primer frame)
Imágenes de fondo CSS cargadas con url()
Bloques de texto a nivel de bloque

Elementos excluidos automáticamente:

Elementos con opacidad 0 (invisibles)
Imágenes placeholder de baja entropía
Imágenes que cubren 100% del viewport (consideradas fondo)

Anatomía del LCP: Las 4 subpartes críticas

Según web.dev/articles/optimize-lcp (actualizado regularmente), el LCP se descompone en 4 fases:

Fase	% Tiempo óptimo	Descripción
TTFB (Time to First Byte)	~40%	Tiempo hasta recibir primer byte HTML
Retraso carga recursos	<10%	Tiempo entre TTFB y inicio descarga imagen LCP
Duración carga recursos	~40%	Tiempo de descarga de la imagen LCP
Retraso renderización	<10%	Tiempo entre fin descarga y renderización

Conclusión: Un LCP óptimo dedica el 80% del tiempo a las solicitudes de red (TTFB + descarga) y menos del 20% a retrasos evitables.

Soluciones técnicas para optimizar el LCP causado por imágenes

1. Comprime agresivamente: WebP/AVIF son obligatorios

Datos oficiales:

WebP: 25-34% más pequeño que JPEG (developers.google.com/speed/webp)
AVIF: 50%+ más pequeño que JPEG (web.dev/articles/compress-images-avif)

Para una comparativa técnica detallada entre estos formatos, consulta nuestro análisis completo WebP vs AVIF vs JPEG.

<!-- Recomendación: AVIF + WebP + JPEG fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="Descripción" width="1920" height="1080">
</picture>

2. NUNCA uses lazy loading en la imagen hero

Error crítico detectado en el 60% de sitios con LCP mayor a 4 segundos:

<!-- ❌ INCORRECTO: Lazy loading retrasa descarga LCP -->
<img src="hero.jpg" loading="lazy" alt="Hero">

<!-- ✅ CORRECTO: Carga eager + fetchpriority -->
<img src="hero.webp" loading="eager" fetchpriority="high" alt="Hero" width="1920" height="1080">

Por qué funciona: El atributo fetchpriority="high" instruye al navegador a descargar la imagen hero antes que hojas de estilo o JavaScript, reduciendo el "Retraso carga recursos" de 400ms a <50ms.

3. Preload para imágenes de fondo CSS

Si tu LCP es una background-image en CSS, debes usar <link rel="preload">:

<head>
  <!-- Carga hoja de estilo -->
  <link rel="stylesheet" href="styles.css">
  
  <!-- Preload imagen de fondo LCP -->
  <link rel="preload" as="image" href="hero-bg.webp" fetchpriority="high">
</head>

Impacto medido: Reduce "Retraso carga recursos" de 600ms (esperar a parsear CSS) a 0ms (descarga paralela con CSS).

4. Sirve imágenes desde el mismo origen

Problema: Imágenes en CDN de terceros (Cloudinary, Imgix) añaden 200-500ms extra por negociación TLS.

Solución: Usa CDN con proxy desde tu dominio:

# Nginx proxy_pass (ejemplo Cloudflare)
location /cdn-images/ {
    proxy_pass https://mycdn.cloudflare.com/;
    proxy_ssl_server_name on;
}

Beneficio: El navegador reutiliza la conexión HTTP/2 existente, eliminando el handshake adicional.

5. Optimiza el TTFB: Servidor edge y cache-control

El TTFB representa el 40% del LCP. Recomendaciones oficiales web.dev:

CDN edge: Sirve HTML desde ubicación geográfica cercana al usuario
Cache-Control: max-age=31536000 para imágenes (con hashing de archivos)
103 Early Hints: Envía headers Link: <image.webp>; rel=preload ANTES del HTML completo

CLS (Cumulative Layout Shift): Estabilidad visual ante todo

¿Qué mide el CLS?

CLS cuantifica la magnitud de cambios de diseño inesperados durante la vida de la página. Se calcula con la fórmula:

layout shift score = impact fraction × distance fraction

Ejemplo real:

Fracción de impacto: 75% del viewport afectado por el cambio
Fracción de distancia: Elemento se movió 25% de la altura del viewport
Puntuación: 0.75 × 0.25 = 0.1875 (suspenso, umbral 0.1)

Estabilidad visual (CLS) - Cambio diseño acumulativo web imágenes sin dimensiones saltos layout viewport estabilidad

La causa #1 de CLS: Imágenes sin dimensiones

Escenario típico:

<!-- ❌ Imagen sin width/height -->
<img src="producto.jpg" alt="Producto">

Qué pasa:

Navegador reserva 0px de altura (no conoce tamaño de la imagen)
Usuario empieza a leer contenido debajo
Imagen se descarga (300KB, 2 segundos)
Navegador descubre que mide 600px de alto
Todo el contenido se desplaza 600px hacia abajo (CLS = 0.45)

Solución técnica definitiva: Always set width/height

<!-- ✅ CORRECTO: Navegador reserva espacio antes de descargar -->
<img src="producto.jpg" alt="Producto" width="800" height="600">

Por qué funciona: El navegador calcula el aspect-ratio (800/600 = 1.333) y reserva el espacio exacto en el layout ANTES de descargar la imagen.

Importante: Los valores width y height no fuerzan el tamaño visual (CSS tiene prioridad), solo informan al navegador del aspect ratio.

Otras causas de CLS relacionadas con imágenes

1. Anuncios/embeds que cargan tarde

Problema común: Anuncio de 300x250px se inserta dinámicamente empujando contenido.

Solución: Reserva espacio con min-height:

.ad-container {
  min-height: 250px; /* Altura mínima del anuncio */
  background: #f0f0f0; /* Placeholder visual */
}

2. Fuentes web que cambian tamaño de texto

Aunque no son imágenes, las fuentes web causan CLS cuando el texto renderizado con fuente del sistema (Fallback) tiene altura diferente a la fuente web final.

Solución: Usa font-display: optional o ajusta métricas con @font-face size-adjust:

@font-face {
  font-family: 'Roboto';
  src: url('roboto.woff2') format('woff2');
  font-display: optional; /* No bloquea renderización */
  size-adjust: 97%; /* Ajusta tamaño para igualar Arial */
}

3. Transformaciones CSS que afectan layout

❌ Evita estas propiedades en animaciones:

top, left, width, height → Causan reflow

✅ Usa propiedades compositor:

transform, opacity → No causan CLS

/* ❌ INCORRECTO: Animar top causa CLS */
.box {
  animation: slide 1s;
}
@keyframes slide {
  from { top: 0; }
  to { top: 100px; }
}

/* ✅ CORRECTO: Animar transform NO causa CLS */
.box {
  animation: slide 1s;
}
@keyframes slide {
  from { transform: translateY(0); }
  to { transform: translateY(100px); }
}

El impacto crítico en dispositivos móviles

Por qué Core Web Vitals son peores en móviles

Datos CrUX (Chrome User Experience Report):

Factor	Desktop	Mobile	Impacto en LCP
CPU	8 cores, 3.5GHz	4 cores, 2.0GHz	+60% tiempo procesamiento
Conexión	100 Mbps WiFi	4G (15 Mbps)	+300% tiempo descarga
Viewport	1920x1080	375x667	Imagen hero sigue pesando igual

Conclusión: Una imagen que carga en 1.5s en desktop puede tardar 4.5s en móvil, suspendiendo el LCP.

Estrategia responsive para Core Web Vitals

1. Sirve imágenes a tamaño correcto

Error común: Enviar imagen 1920px a viewport 375px:

<!-- ❌ Desperdicia 75% del ancho de banda en móvil -->
<img src="hero-1920w.jpg" alt="Hero">

Solución con srcset:

<img 
  src="hero-800w.jpg"
  srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1920w.jpg 1920w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1920px"
  alt="Hero"
  width="1920"
  height="1080"
>

Beneficio: Móvil descarga 60KB (400w) en lugar de 300KB (1920w) → LCP mejora de 4.5s a 1.8s.

2. Lazy loading estratégico

Regla de oro: Lazy load TODO excepto imágenes above-the-fold (primeras 2-3 imágenes):

<!-- Primera imagen (hero): NO lazy -->
<img src="hero.webp" loading="eager" fetchpriority="high" alt="Hero" width="1920" height="1080">

<!-- Segunda imagen (visible sin scroll): NO lazy -->
<img src="intro.webp" loading="eager" alt="Intro" width="800" height="600">

<!-- Tercera imagen en adelante: SÍ lazy -->
<img src="producto-1.webp" loading="lazy" alt="Producto 1" width="600" height="400">

Impacto medido: Reduce ancho de banda inicial de 2MB a 400KB → LCP mejora 30%, INP mejora (menos trabajo de red = CPU liberada).

3. Prioriza Critical CSS para móviles

En móvil, cada KB extra de CSS bloquea la renderización. Inline Critical CSS:

<head>
  <style>
    /* Inline: Solo estilos above-the-fold */
    .hero { display: block; max-width: 100%; height: auto; }
    body { font-family: Arial, sans-serif; margin: 0; }
  </style>
  
  <!-- Defer: Resto de estilos -->
  <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

Herramientas de medición y monitorización

Herramientas de campo (Real User Monitoring)

1. Chrome User Experience Report (CrUX)

Qué es: Dataset público con datos reales de millones de usuarios Chrome
Acceso: PageSpeed Insights, Search Console, BigQuery
Ventaja: Datos de usuarios reales, no simulaciones
Limitación: Requiere tráfico mínimo (~1,000 visitas/mes)

2. PageSpeed Insights

URL: https://pagespeed.web.dev
Qué muestra: CrUX (campo) + Lighthouse (lab) + diagnósticos
Uso: Analiza URL específicas o origen completo

3. Search Console (Core Web Vitals Report)

Qué muestra: URLs agrupadas por estado (bueno/necesita mejora/deficiente)
Ventaja: Identifica páginas prioritarias a optimizar

Herramientas de laboratorio

1. Lighthouse (Chrome DevTools)

Acceso: DevTools > Lighthouse tab
Métricas: LCP, CLS, TBT (proxy de INP)
Uso: Pruebas locales con condiciones controladas

2. WebPageTest

URL: https://webpagetest.org
Ventaja: Prueba desde múltiples ubicaciones geográficas y dispositivos
Uso avanzado: Filmstrip visual del LCP frame-by-frame

3. Chrome DevTools Performance Panel

Acceso: DevTools > Performance > Record
Qué muestra: Desglose EXACTO de las 4 subpartes del LCP
Uso: Diagnóstico preciso de qué fase está fallando

Checklist de optimización de imágenes para Core Web Vitals

Antes de subir imágenes a producción

☐ Formato: Convertir a WebP/AVIF con fallback JPEG
☐ Compresión: Calidad 85% (WebP) o cq-level 18 (AVIF)
☐ Dimensiones: Generar versiones 400w, 800w, 1920w
☐ Metadatos: Eliminar EXIF innecesarios (reduce ~30KB/imagen)

En el HTML

☐ Atributos dimensionales: Siempre incluir width y height
☐ Lazy loading: Solo desde tercera imagen en adelante
☐ fetchpriority: high en imagen hero, low en carrusel fuera de vista
☐ Alt text: Descriptivo para SEO y accesibilidad

Hero image (LCP crítico)

☐ loading="eager": NUNCA lazy
☐ fetchpriority="high": Prioridad máxima
☐ Preload (si es background-image): <link rel="preload"> en <head>
☐ Tamaño optimizado: Máximo 150KB para LCP <2.5s en 4G

CDN y servidor

☐ Cache-Control: max-age=31536000, immutable para imágenes
☐ CDN edge: Cloudflare, Cloudinary o similar con cobertura global
☐ HTTP/2 o HTTP/3: Multiplexación de conexiones
☐ Brotli/gzip: Compresión adicional de respuestas HTML

Caso de estudio real: E-commerce mejora LCP de 4.8s a 1.9s

Sitio: Tienda online de moda con 50,000 productos

Problema inicial (medición CrUX):

LCP: 4.8s (percentil 75 móvil) - Suspenso
CLS: 0.23 - Necesita mejora
INP: 320ms - Necesita mejora

Cambios implementados:

Conversión WebP: 300KB JPEGs → 95KB WebP (68% reducción)
srcset responsive: 3 tamaños (400w/800w/1920w) según viewport
fetchpriority="high": En imagen producto principal
width/height: Añadidos a las 50,000 imágenes (script batch)
Lazy loading: Desde tercera imagen galería producto

Resultados (tras 3 meses de implementación):

LCP: 1.9s → Aprobado (mejora 60%)
CLS: 0.08 → Aprobado (mejora 65%)
INP: 185ms → Aprobado (mejora 42%)

Impacto SEO:

+23% tráfico orgánico (3 meses post-optimización)
+15% conversión (menor abandono por carga lenta)
+8 posiciones promedio en keywords transaccionales

Conclusión: Core Web Vitals son ventaja competitiva, no solo SEO

Optimizar tus imágenes para Core Web Vitals no es solo cumplir una métrica de Google. Es respetar el tiempo y datos de tus usuarios. Un sitio que carga en 2 segundos en lugar de 5 no solo rankea mejor, convierte más porque la experiencia es fluida.

Tres acciones inmediatas:

Mide tu estado actual: PageSpeed Insights en tus 10 URLs más visitadas
Convierte a WebP/AVIF: Usa FormatVault para batch processing con procesamiento 100% local
Añade width/height: Script automatizado si tienes miles de imágenes

Recuerda: Google actualiza Core Web Vitals anualmente. Manténte al día con web.dev y actúa rápido. Tus competidores ya están optimizando.

Fuentes oficiales:

web.dev/articles/lcp
web.dev/articles/cls
web.dev/articles/vitals
web.dev/articles/optimize-lcp
developers.google.com/search/docs/appearance/core-web-vitals