Optimizar imágenes en Next.js

Qué hace next/image por ti

El componente Image de Next.js genera automáticamente:

• Un srcset con varios anchos de la imagen.
• Conversión a formatos modernos según el navegador (cabecera Accept).
• loading="lazy" por defecto.
• Atributos width y height para evitar CLS.

Las imágenes se optimizan bajo demanda en el servidor (o en la plataforma de despliegue) y se cachean.

Activa AVIF

Por defecto, Next.js solo sirve WebP. Para servir AVIF a los navegadores que lo soportan, añade el formato en next.config:

// next.config.js
module.exports = {
  images: {
    formats: ["image/avif", "image/webp"],
  },
};

El orden importa: se elige el primer formato aceptado por el navegador. AVIF tarda más en generarse la primera vez, pero después se sirve desde caché.

La imagen principal: preload y prioridad

next/image aplica lazy loading a todas las imágenes salvo que indiques lo contrario. Para la imagen LCP:

<Image src={hero} alt="…" priority sizes="100vw" />

En las versiones más recientes, la propiedad preload (o fetchPriority="high" junto a loading="eager") cumple la misma función que priority. Revisa la documentación de tu versión: la idea es siempre la misma, desactivar lazy y precargar la imagen principal. Más contexto en cómo mejorar el LCP.

sizes: el ajuste más olvidado

Sin sizes, Next.js genera un srcset con descriptores de densidad (1x, 2x) basados en el width que indiques. Con sizes, genera descriptores de ancho y el navegador puede elegir mucho mejor:

<Image
  src="/blog/portada.jpg"
  alt="…"
  width={1600}
  height={900}
  sizes="(min-width: 1024px) 768px, 100vw"
/>

Si usas fill (la imagen ocupa su contenedor), sizes es prácticamente obligatorio; si no, el navegador asume 100vw y descarga imágenes demasiado grandes en diseños de columnas.

Calidad

El valor por defecto es 75. Las versiones recientes exigen declarar en images.qualities las calidades permitidas si usas otras. Para fotografía, 70-80 suele ser suficiente; para imágenes de producto, quizá 85.

¿Optimizar en el servidor o antes del build?

La optimización bajo demanda tiene ventajas (variantes automáticas), pero también costes:

• Primera petición lenta: cada combinación de tamaño y formato se genera la primera vez que alguien la pide.
• Coste o límites de la plataforma: algunos proveedores cobran o limitan las transformaciones de imagen.
• Imágenes estáticas pesadas en el repositorio: si subes fotos de 8 MB, el build y el repositorio crecen.

Una estrategia sensata:

1. Optimiza los originales antes de añadirlos al proyecto. Redimensiona a un máximo razonable (por ejemplo 2560 px) y comprímelos con ImageZap. El repositorio queda ligero y next/image trabaja sobre archivos más pequeños.
2. Para sitios estáticos (output: "export") sin servidor de imágenes, genera tú las variantes AVIF/WebP y usa <picture> directamente o unoptimized.

Imágenes remotas

Para imágenes de un CMS o CDN externo, declara los dominios en images.remotePatterns. Si el CDN ya optimiza y sirve AVIF, puedes usar un loader personalizado para que Next.js genere las URLs del CDN en lugar de reoptimizar.

Lista de comprobación

• formats: ["image/avif", "image/webp"] en la configuración.
• La imagen LCP con priority (o preload) y sin lazy.
• sizes en todas las imágenes responsive y con fill.
• Originales redimensionados antes de añadirlos al repositorio.
• alt descriptivo en cada imagen.

Preguntas frecuentes

¿next/image funciona con exportación estática?

La optimización integrada necesita un servidor. Con output: "export" debes usar unoptimized o un loader externo.

¿Por qué mis imágenes tardan la primera vez?

Porque se están generando. Las siguientes peticiones salen de la caché.

¿Debo usar next/image para SVG?

No aporta nada: los SVG no se optimizan como mapas de bits. Usa un <img> normal o el SVG en línea.

¿Puedo usar los archivos generados por ImageZap con next/image?

Sí. Puedes importar los AVIF o WebP directamente o usar el código JSX generado con <picture> si prefieres controlar tú los formatos.