Mejorando Core Web Vitals: Optimización de imágenes para LCP

Search Console te notificó a las 7:14 AM con un banner de "Problema de Core Web Vitals detectado". El gráfico muestra que el LCP ha subido de 2.8 segundos a 4.4 segundos en el último mes. Revisas las páginas y notas rápidamente que el equipo de marketing ha estado subiendo fotos principales de 4 MB directamente desde la exportación de Lightroom del fotógrafo. Nadie comprimió nada. El grupo "necesita mejorar" ahora contiene el 60 por ciento del tráfico de tu página de inicio. Cuando termines de leer este artículo, sabrás qué palanca accionar primero para reducir esos números y volver al verde.

El Largest Contentful Paint es la Core Web Vital que castiga más a los sitios lentos en 2026, y el elemento LCP en el 70 por ciento de las páginas es una imagen — la foto principal, la foto del producto, el encabezado del artículo. Mejorar el LCP se trata principalmente de hacer que esa imagen llegue más rápido a la pantalla del usuario, lo que tiene más palancas de las que parece. Aquí está la versión práctica: cómo diagnosticar un LCP deficiente, las conversiones y ajustes de entrega que lo solucionan, y de dónde vienen realmente las victorias rápidas.

Antecedentes: qué es LCP y por qué le importa a Google

LCP mide el tiempo desde la solicitud de página hasta que el elemento de contenido visible más grande termina de renderizarse. Los umbrales de Google son 2.5 segundos para "bueno", 4.0 segundos para "necesita mejorar", y peor que 4.0 para "deficiente". Search Console reporta LCP a partir de datos de campo de usuarios reales — el Chrome User Experience Report — no de pruebas de laboratorio, lo que significa que tu puntuación local de Lighthouse y la puntuación de campo pueden diferir enormemente.

Para la mayoría de los sitios de marketing y editoriales, el elemento LCP es una imagen principal. Para páginas de productos de comercio electrónico, es la foto principal del producto. Para blogs, es la imagen destacada sobre el pliegue. Google hizo de LCP una señal de clasificación en 2021 y ha aumentado su ponderación constantemente desde entonces. Un LCP lento no solo frustra a los usuarios — cuesta posiciones en los rankings.

Paso a paso: arregla LCP en una tarde

1. Identifica el elemento LCP. Usa la pestaña Rendimiento de Chrome DevTools o PageSpeed Insights para encontrar el nodo DOM infractor.
2. Audita el archivo fuente. Verifica las dimensiones y el peso mediante información de imagen. Un JPG de 4,000 px en un contenedor de 1,200 px es el villano más común.
3. Redimensiona la fuente a aproximadamente 2x el ancho de visualización.
4. Convierte a formato moderno mediante JPG a WebP y JPG a AVIF.
5. Comprime agresivamente con Comprimir JPG a calidad 78-82.
6. Envuelve en una etiqueta <picture> con fallbacks a AVIF, WebP y JPG.
7. Añade fetchpriority="high" y precarga en el encabezado del documento.
8. Elimina cualquier loading="lazy" en el elemento LCP.

Paso 1: Identifica el elemento LCP

Abre Chrome DevTools, cambia a la pestaña Rendimiento, graba una carga de página y busca el marcador "LCP" en la línea de tiempo. Haz clic en él y el panel te dirá exactamente qué nodo DOM es el elemento LCP. Nueve de cada diez veces es una etiqueta <img> que apunta a un JPG de 1.8 MB directamente del fotógrafo.

La herramienta gratuita PageSpeed Insights también identifica el elemento LCP. Si no coincide con lo que esperabas, la solución podría ser CSS — tu "principal" podría estar oculta detrás de un banner que el usuario nunca ve, y el LCP real es un logo o una imagen de la barra lateral.

Paso 2: Convierte a un formato moderno

La mayor ganancia individual, en la mayoría de los casos, es convertir el JPG de LCP a WebP o AVIF. Un JPG de 1.8 MB con calidad típica se comprime a 700 KB como WebP o 450 KB como AVIF sin pérdida visible. Eso es entre 1.1 MB y 1.35 MB eliminados de la ruta crítica. En una conexión móvil de 5 Mbps, eso ahorra de 1.8 a 2.2 segundos.

Convierte mediante JPG a WebP o JPG a AVIF. Usa un elemento <picture> para servir formatos modernos con un fallback a JPG:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="600">
</picture>

Paso 3: Redimensiona para las dimensiones reales mostradas

El pecado más común de LCP es servir una imagen de 4,000 px de ancho en un contenedor de 1,200 px de ancho. El navegador descarga todos los 4,000 px de datos y luego los reduce. Redimensiona la fuente a aproximadamente 2x el ancho máximo de visualización — así que 2,400 px para un contenedor de 1,200 px — y envía un JPG con dimensiones adecuadas.

Para diseños responsivos, genera múltiples tamaños y usa srcset:

<img srcset="hero-800.webp 800w, hero-1200.webp 1200w, hero-2400.webp 2400w"
     sizes="(max-width: 800px) 100vw, 1200px"
     src="hero-1200.webp" alt="...">

Paso 4: Comprime agresivamente pero sin pérdida visible

Incluso después de la conversión de formato, las exportaciones predeterminadas tienen calidad excesiva. Pasa el resultado por Comprimir JPG a calidad 78 a 82 para imágenes principales. La mayoría de los espectadores no pueden distinguir la calidad 82 de la calidad 95 a distancias de visualización típicas, y el archivo es un 40 por ciento más pequeño.

Para imágenes de fondo a pantalla completa que están ligeramente desenfocadas o tienen una superposición de color aplicada, puedes bajar a calidad 65 a 70 sin diferencia percibida. El desenfoque oculta los artefactos JPEG.

Paso 5: Añade fetchpriority y precarga

Incluso con un archivo pequeño, el navegador puede no comenzar a descargar la imagen LCP hasta que haya analizado el HTML y el diseño esté en progreso. Dos etiquetas solucionan eso:

• <img fetchpriority="high"> le dice al navegador que esta imagen es crítica. Compatible en Chrome, Edge y Safari 17+.
• <link rel="preload" as="image" href="hero.webp"> en el <head> inicia la descarga antes.

Ten cuidado de no aplicar fetchpriority="high" a múltiples imágenes en la página — pierde significado y puede incluso perjudicar el LCP al competir con la imagen principal real.

Paso 6: Elimina el error loading="lazy"

La carga diferida es maravillosa para imágenes debajo del pliegue. Es catastrófica para el elemento LCP. Audita tus imágenes principales en busca de loading="lazy" y elimina el atributo (o establécela explícitamente en eager). El navegador no descargará una imagen con carga diferida hasta que se calcule el diseño, lo que añade de 300 a 800 ms al LCP.

Paso 7: Sirve desde un CDN con HTTP/2 o HTTP/3

Las imágenes servidas desde el origen añaden latencia innecesaria. Cloudflare, Fastly, BunnyCDN e ImageKit reducen el tiempo de entrega en un promedio de 200 a 400 ms en comparación con el origen. Combinado con la multiplexación HTTP/3, las solicitudes de imágenes adicionales en la página no bloquean la imagen principal.

Paso 8: Establece ancho y alto explícitos

El desplazamiento de diseño (CLS, otro Core Web Vital) ocurre cuando las imágenes se cargan sin espacio reservado, moviendo el contenido. Establece atributos width y height explícitos en cada imagen. El navegador los usa para calcular la relación de aspecto y reservar espacio de diseño antes de que llegue la imagen. Usa la calculadora de relación de aspecto para confirmar que las proporciones coincidan.

Errores comunes y sus soluciones

• Error: optimizar solo la imagen LCP e ignorar CLS. Solución: también establece width/height en todas las demás imágenes para evitar el desplazamiento de diseño.
• Error: servir WebP pero sin respaldo JPG en un <picture>. Solución: incluye el respaldo JPG para la pequeña parte de navegadores que aún lo necesitan.
• Error: AVIF codificado con calidad predeterminada 90+, produciendo archivos más grandes que WebP. Solución: apunta a calidad AVIF 65-75 para uso hero.
• Error: precargar la imagen incorrecta porque el LCP cambió. Solución: vuelve a auditar después de cambios de diseño; un nuevo banner puede haber tomado el estado LCP.
• Error: fetchpriority=high en el logo además del hero. Solución: solo un elemento debe ser de alta prioridad por página.
• Error: confiar en puntuaciones Lighthouse de laboratorio cuando los datos de campo discrepan. Solución: confía en los números CrUX de Search Console para decisiones de ranking.

Ejemplos reales

Smashing Magazine realizó una auditoría LCP pública en 2023 y redujo la mediana LCP de 4.6 segundos a 1.9 segundos en sus páginas de artículo convirtiendo imágenes hero a AVIF, precargando el LCP y podando scripts de terceros.

El equipo de página de producto de Etsy lanzó una migración srcset en 2024 que redimensionó las imágenes hero de producto a las dimensiones reales mostradas para cada viewport. El LCP móvil mejoró en 1.4 segundos en datos de campo CrUX.

Los temas de Shopify desde 2026 vienen con generación <picture> incorporada y fetchpriority="high" en la primera imagen de producto. Los temas que optan por no usarlo frecuentemente ven regresiones LCP reportadas en cuentas de Search Console de comerciantes.

Comparación de formatos para imágenes hero

Formato	Tamaño típico (hero de 1200px)	Soporte del navegador 2026	Tiempo de codificación	Impacto en LCP
JPG (q92)	1.8 MB	Universal	Rápida	Referencia
JPG (q82)	900 KB	Universal	Rápida	-0.4 s
WebP (q80)	600 KB	99%+	Rápida	-0.9 s
AVIF (q70)	400 KB	96%+	Lento (10x)	-1.3 s

Las ganancias esperadas, cuantificadas

Un estado "antes" típico para una página LCP fallida: 1.8 MB JPG, sin srcset, carga diferida, servido desde origen. LCP de página: 5.2 segundos en 4G.

Estado "después": 480 KB AVIF (con respaldos WebP y JPG), srcset en tres tamaños, fetchpriority alta, servido desde CDN. LCP de página: 1.9 segundos en 4G.

Eso es una mejora de 3.3 segundos de un trabajo que toma una tarde. Search Console reflejará el cambio en datos de campo después de aproximadamente 28 días a medida que se actualice la ventana móvil.

Consejos avanzados

1. Incrusta un marcador de posición de imagen de baja calidad (LQIP) como un data URI base64 en el HTML para que algo se pinte antes de que llegue el hero de alta resolución.
2. Genera CSS de color dominante mediante paleta de colores y úsalo como fondo de la imagen; reduce el tiempo en blanco percibido.
3. Usa decoding="async" en imágenes que no sean LCP para que no bloqueen el pintado.
4. Difiere scripts de terceros no críticos hasta después de onload — incluso imágenes hero rápidas pueden perder contra JS que bloquea el renderizado.
5. Usa HTTP/3 con sugerencias de priorización para que el hero obtenga prioridad de flujo sobre el favicon.
6. Omite el intermediario WebP en Safari 16.1+: sirve AVIF directamente mediante el orden de fuente <picture>.
7. Observa el percentil 75 de CrUX, no la mediana. Google rankea en el percentil 75, que es donde viven las conexiones lentas.

Preguntas frecuentes

¿Cuánto tiempo después de arreglar se actualizan los números de Search Console?

Aproximadamente 28 días, porque CrUX usa una ventana móvil de 28 días.

¿Debería convertir todas las imágenes a AVIF o solo el hero?

Solo el hero LCP más las imágenes sobre el pliegue. Las que están bajo el pliegue pueden permanecer en WebP ya que la codificación AVIF es lenta.

¿Funciona fetchpriority=high en Firefox?

Desde 2026, sí — Firefox añadió soporte en 2023.

¿Qué pasa si mi LCP es texto, no una imagen?

Entonces el cuello de botella es la fuente, no la imagen. Precarga el woff2 y usa font-display: swap.

¿Puedo omitir la alternativa JPG si dejo de dar soporte a IE11?

Básicamente sí: todos los navegadores 2026 son compatibles con WebP. La alternativa JPG ahora es principalmente para bots antiguos y la representación en correos electrónicos.

¿Establecer fetchpriority perjudica a otros recursos?

Solo en una pequeña medida; el navegador igual carga todo, solo que en un orden diferente.

¿Debería precargar AVIF o WebP si tengo ambos?

Precarga el formato que realmente le sirves al visitante actual; usa imagesrcset en la etiqueta de precarga para configuraciones responsivas.

Casos especiales que vale la pena conocer

• Los banners de consentimiento de cookies pueden convertirse en el LCP. Si el banner de GDPR es el elemento visible más grande, el héroe real nunca se mide. Dale al banner un estilo más pequeño que el héroe.
• Google Fonts puede retrasar el LCP si bloquea el primer pintado. Usa font-display: swap y precarga el woff2.
• LCP de imágenes de fondo. Las imágenes establecidas mediante CSS background-image cuentan como elementos LCP, pero no pueden usar srcset. Conviértelas a etiquetas <img> con posicionamiento absoluto si necesitas la optimización.

Plan de acción de una tarde

1. Identifica el elemento LCP mediante PageSpeed Insights.
2. Conviértelo mediante JPG a AVIF y JPG a WebP.
3. Compresión mediante Comprimir JPG para verificar que la calidad 80 es suficiente.
4. Envuélvelo en un elemento <picture> con srcset.
5. Añade fetchpriority="high" y una etiqueta de precarga.
6. Elimina cualquier loading="lazy" de las imágenes que están sobre el pliegue.
7. Súbelo a staging, vuelve a ejecutar PageSpeed, súbelo a producción.

Si quieres una comprobación rápida de antes y después, pasa la imagen héroe actual por comprimir imagen y compara el resultado renderizado lado a lado. Si el archivo más pequeño se ve idéntico, tienes tu prueba — y el resto del trabajo anterior es solo fontanería. Combínalo con el convertidor de imágenes para cualquier cambio de formato y la calculadora de tamaño de archivo de imagen para presupuestar tus recuentos de bytes.

LCP y el percentil 75

Google clasifica según el percentil 75 de los datos de campo de CrUX, no la mediana. Eso significa que tu usuario "promedio" móvil puede ser rápido mientras tu ranking aún sufre porque el cuarto lento de tu audiencia está lastrando la métrica. El cuarto lento generalmente vive en teléfonos Android antiguos, redes móviles congestionadas o geografías lejanas. Optimizar solo para tus condiciones de desarrollador los pasa por alto por completo.

Para ver la realidad del percentil 75, usa herramientas de monitoreo de usuario real (RUM) como SpeedCurve, Calibre o Vercel Analytics. Estas informan la distribución completa, no solo la mediana, para que puedas apuntar explícitamente a la cola lenta. Una vez que arreglas la cola lenta, la métrica del percentil 75 baja y Search Console refleja la mejora después del próximo cambio de CrUX.

El costo oculto de las etiquetas de terceros

LCP no se trata solo de imágenes. El JavaScript que bloquea la renderización de análisis, pruebas A/B, etiquetas de marketing y widgets de chat puede retrasar el inicio de cualquier descarga, incluido tu héroe perfectamente optimizado. Audita tu <head> en busca de scripts sincrónicos de terceros y aplaza todo lo que no necesite ejecutarse antes del pintado.

La auditoría "Uso de terceros" de Lighthouse enumera los dominios infractores. Los culpables comunes: Google Tag Manager cargado sincrónicamente, Hotjar incrustado en línea, widget de Intercom inicializado con entusiasmo. Cada uno añade 100 a 500 ms de retraso de LCP en móvil. Aplazar o inicializar de forma perezosa después del primer pintado casi no tiene costo en el impacto de la función y puede recuperar segundos.

LCP de imagen en aplicaciones de una sola página

Las SPA (React, Vue, Svelte) tienen un problema único de LCP: la página renderiza HTML vacío, luego JavaScript obtiene los datos, luego aparece la imagen. El "pintado de contenido más grande" puede ocurrir 3 a 5 segundos después del inicio de la navegación porque el framework tiene que arrancar antes de que la imagen siquiera se solicite.

La solución es la renderización del lado del servidor (SSR) o la generación estática (SSG), que entregan el HTML — incluido el <img src> — en la primera respuesta. El navegador comienza a descargar la imagen inmediatamente, en paralelo con el arranque de JavaScript. Next.js, Remix, SvelteKit y Nuxt tienen SSR o SSG por defecto y producen un LCP mucho mejor que las SPA renderizadas por el cliente.

Si debes ejecutar renderizado por el cliente, precarga la URL de la imagen héroe desde el HTML estático para que el navegador comience la descarga antes de que React se hidrate. Este es uno de los pocos casos en los que una etiqueta <link rel="preload"> es realmente necesaria.

Monitoreo de regresiones de LCP en CI

Una vez que tienes un LCP saludable, el siguiente problema es mantenerlo saludable. Marketing sube un héroe de 4 MB, un desarrollador envía una nueva fuente que retrasa el pintado, se añade un script de análisis. Sin monitoreo, la métrica se desvía hacia el rojo durante meses.

Integra una ejecución de Lighthouse en tu pipeline de CI. Herramientas como Lighthouse CI, Calibre o SpeedCurve hacen fallar la compilación si el LCP supera un umbral objetivo. Establece el umbral ajustado (2.0 s para móvil) para que las regresiones se detecten en el momento del PR en lugar de descubrirse en Search Console 28 días después. El costo es aproximadamente 30 segundos por PR — barato en comparación con una caída de ranking.

Combina la verificación de laboratorio de CI con datos de campo RUM. El laboratorio detecta regresiones obvias; el campo detecta la cola lenta que los simuladores de laboratorio pasan por alto. Ambos juntos cubren los casos que afectan al ranking.

LCP de imagen y flujos de trabajo de gestión de contenido

La fuente más común de regresión de LCP es un editor de contenido que sube una imagen héroe que pasa por alto tu pipeline de optimización. El CMS acepta un JPG de 4,000 px del correo del fotógrafo, lo incrusta en la publicación y lo envía. El rendimiento cae 1.5 segundos; nadie se da cuenta durante un mes.

Soluciona aplicando restricciones en el momento de la subida. Rechaza imágenes que superen una dimensión máxima (digamos 2,500 px), ejecuta automáticamente la conversión mediante JPG a WebP en la recepción y muestra el tamaño del archivo en la interfaz del editor para que los editores vean "este héroe es de 1.8 MB" antes de que pulsen publicar. La mayoría de las plataformas CMS headless modernas (Sanity, Contentful, Strapi) exponen hooks para la validación de subidas; WordPress puede hacer lo mismo mediante el filtro wp_handle_upload o un plugin.

La educación editorial también importa. Una sesión de entrenamiento de 15 minutos que muestre cómo se ve un héroe de 380 KB junto a uno de 4 MB — son idénticos — convence a los editores no técnicos de que la compresión no es un compromiso de calidad. Después del entrenamiento, las regresiones impulsadas por editores caen aproximadamente un 70 por ciento.