Ver contenido
Guía de Precarga de Imágenes: Implementación Práctica para Reducir el LCP
Introducción
Esta guía cubre cómo identificar tu imagen LCP, implementar rel="preload" y fetchpriority="high" correctamente, precargar imágenes responsivas con srcset, y evitar los errores que anulan el beneficio de estas técnicas. El UXR SEO Analyzer reporta si la imagen LCP detectada carece de señales de prioridad.
Si necesitas el contexto conceptual primero, revisa Precarga de Imágenes Explicada.
Paso 1: Identificar la Imagen LCP
Usa el panel Performance de Chrome DevTools o el reporte de Lighthouse para identificar qué elemento se marca como Largest Contentful Paint. En la mayoría de páginas de contenido es la imagen hero o la imagen destacada del artículo.
Paso 2: Preload Básico para Imagen en HTML
<head>
<link rel="preload" as="image" href="/hero.jpg" fetchpriority="high">
</head>
<body>
<img src="/hero.jpg" fetchpriority="high" width="1200" height="600" alt="Descripción de la imagen">
</body>Nota que declaramos fetchpriority="high" tanto en el <link rel="preload"> como en la etiqueta <img> para maximizar la señal de prioridad en ambos puntos del pipeline de carga.
Paso 3: Preload de Imágenes Responsivas
Cuando la imagen LCP usa srcset/sizes, el preload debe replicar esos mismos atributos usando imagesrcset e imagesizes para que el navegador precargue la variante correcta:
<link
rel="preload"
as="image"
href="/hero-800.jpg"
imagesrcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1200.jpg 1200w"
imagesizes="(max-width: 600px) 100vw, 800px"
fetchpriority="high">Sin imagesrcset/imagesizes, el navegador podría precargar una variante distinta a la que finalmente usa el <img>, desperdiciando el ancho de banda de esa descarga temprana.
Paso 4: Preload de Imagen de Fondo CSS
Si el elemento LCP es un background-image definido en CSS, el navegador no lo descubre hasta que procesa esa regla CSS—por eso el preload en el <head> es indispensable para el descubrimiento temprano:
<link rel="preload" as="image" href="/hero-bg.jpg" fetchpriority="high">
<style>
.hero { background-image: url('/hero-bg.jpg'); }
</style>Paso 5: Verificar el Resultado
- Abre las DevTools → panel Network y confirma que
hero.jpgaparece entre las primeras solicitudes, con prioridad "High". - Ejecuta Lighthouse y compara el timestamp de LCP antes/después del cambio.
- Confirma que no hay
loading="lazy"en la misma imagen—es el error que anula el efecto del preload.
Errores Comunes
| Error | Consecuencia | Corrección |
|---|---|---|
Preload con href distinto al src real | El navegador descarga un recurso que nunca se usa, y no acelera nada | Sincronizar exactamente la URL del preload con la del <img> |
| Precargar más de una imagen como "high" | Se diluye la prioridad y compite con la imagen LCP real | Reservar fetchpriority="high" solo para el elemento LCP |
Combinar preload con loading="lazy" | Señales contradictorias; el navegador puede ignorar el preload | Nunca usar lazy loading en la imagen LCP |
Preload sin atributo as="image" | El navegador no asigna la prioridad correcta al recurso | Siempre declarar as="image" |
Implementación en Frameworks
Next.js
El componente next/image expone una prop priority que, al aplicarse a la imagen LCP, genera automáticamente tanto el <link rel="preload"> correspondiente en el <head> como el atributo fetchpriority="high" en el elemento renderizado, y además desactiva el lazy loading para esa imagen específica:
import Image from 'next/image';
export default function Hero() {
return (
<Image
src="/hero.jpg"
width={1200}
height={600}
alt="Descripción de la imagen"
priority
/>
);
}Nuxt / Vue
El componente <NuxtImg> de @nuxt/image acepta una prop preload equivalente que genera el mismo par de señales (link preload + fetchpriority) durante el renderizado del lado del servidor.
HTML Estático / Astro
En sitios sin framework de imágenes integrado, la implementación manual mostrada en los pasos anteriores es la única opción, por lo que vale la pena encapsularla en un componente o partial reutilizable para no repetir el patrón en cada plantilla.
Precarga de Múltiples Candidatos LCP
En sitios con contenido dinámico (por ejemplo, un feed donde el primer elemento cambia según el usuario), puede que no sepas en tiempo de build cuál imagen exacta será el LCP. Una estrategia común es precargar la imagen del primer elemento del feed en el servidor, ya que estadísticamente es la más probable candidata a LCP, y aceptar que en casos atípicos el beneficio sea menor.
Monitoreo Continuo del LCP tras la Implementación
Una vez implementado el preload, valida el impacto real (no solo en laboratorio) integrando la métrica de campo con la librería web-vitals:
import { onLCP } from 'web-vitals';
onLCP((metric) => {
console.log('LCP real de este usuario:', metric.value, 'ms');
// envía el valor a tu sistema de analítica junto con la URL de la página
});Compara la distribución de LCP de campo antes y después del cambio durante al menos una semana, ya que las condiciones de red variables entre usuarios pueden ocultar mejoras que sí son consistentes en el agregado.
Precarga de Fuentes vs. Precarga de Imágenes
Es común que un sitio ya use rel="preload" para fuentes web críticas, pero no lo extienda a la imagen LCP. Ambos recursos compiten por el mismo presupuesto de ancho de banda inicial, así que agregar un preload de imagen sin revisar cuántos preloads ya existen puede diluir la prioridad de todos ellos. Como regla general, limita los preloads críticos (fuente principal + imagen LCP) a un máximo de 2-3 recursos por página; agregar más preloads de los que realmente son críticos para el renderizado inicial reduce el beneficio de cada uno.
Preload Condicional según el Viewport
En layouts donde la imagen LCP cambia entre móvil y escritorio (por ejemplo, un hero distinto por breakpoint), puedes usar el atributo media en el <link rel="preload"> para que el navegador solo descargue la variante relevante según el ancho de viewport, evitando descargar ambas imágenes innecesariamente:
<link rel="preload" as="image" href="/hero-mobile.jpg" media="(max-width: 600px)" fetchpriority="high">
<link rel="preload" as="image" href="/hero-desktop.jpg" media="(min-width: 601px)" fetchpriority="high">Resumen de Decisión Rápida
| Pregunta | Respuesta |
|---|---|
| ¿Es esta la imagen LCP de la página? | Sí → aplica preload + fetchpriority. No → no la toques. |
| ¿La imagen LCP está en un fondo CSS? | Sí → preload es obligatorio para el descubrimiento temprano. |
| ¿Ya hay 2-3 preloads críticos en la página? | Sí → evalúa si realmente necesitas agregar uno más. |
¿La imagen tiene loading="lazy"? | Sí → elimínalo si es la imagen LCP. |
Trabajando junto a una Content Security Policy
Los sitios con una Content Security Policy estricta a veces bloquean las señales de preload sin querer si la directiva img-src no cubre el dominio del CDN donde vive la imagen precargada. Si un preload parece no tener efecto, revisa la consola del navegador en busca de advertencias de violación de CSP antes de asumir que la técnica en sí falló—esta es una de las razones más comunes por las que una etiqueta de preload correctamente escrita no acelera nada en producción.
Artículos Relacionados
- Precarga de Imágenes Explicada - Conceptos y por qué importa
- Guía de Optimización de LCP - Estrategia completa de Largest Contentful Paint
- Guía de Optimización de Fetchpriority - Priorización de recursos en detalle
Referencias
- web.dev - Preload critical assets to improve loading speed
- web.dev - Optimize resource loading with the Fetch Priority API
- web.dev - Preload responsive images
- web.dev - Optimize Largest Contentful Paint
- Chrome Developers - LCP request discovery
- Chrome Developers - Avoid chaining critical requests