decoding y fetchpriority: los dos atributos que casi nadie pone

Una imagen no cuesta solo lo que pesa. Cuesta también el lugar que ocupa en la cola de descargas del navegador y el tiempo de CPU que tarda en convertirse de bytes comprimidos a un mapa de píxeles. fetchpriority actúa sobre lo primero y decoding sobre lo segundo, y ninguno de los dos cambia un solo byte del fichero. Son ajustes de planificación, y por eso son de las pocas optimizaciones que se pueden aplicar sin regenerar nada.

La cola de prioridades que ya existe

El navegador no descarga los recursos en el orden en que aparecen. Los mete en una cola con prioridades y las asigna por tipo, por posición y por atributos. En Chromium las categorías son cinco —desde muy alta hasta muy baja— y para imágenes el comportamiento por defecto es este:

La fila que importa es la segunda. Una imagen visible arranca en prioridad baja y solo sube a alta después del primer layout. Ese es el hueco que fetchpriority viene a tapar: durante los primeros cientos de milisegundos, la imagen que va a determinar tu LCP compite en la cola de baja prioridad con todas las demás imágenes de la página, incluidas las del pie. Chromium limita el número de descargas simultáneas de baja prioridad mientras el documento no ha terminado de parsearse, así que tu imagen del hero puede estar literalmente esperando su turno detrás de un icono decorativo.

fetchpriority="high" corrige eso en el instante del escaneo de precarga, antes de que exista layout:

<img src="hero-1400.avif"
     srcset="hero-900.avif 900w, hero-1400.avif 1400w, hero-2000.avif 2000w"
     sizes="100vw" width="2000" height="1000"
     alt="Fachada del mercado central al atardecer"
     fetchpriority="high" decoding="async">

El atributo acepta high, low y auto, y funciona sobre <img>, <link>, <script> e <iframe>, además de existir como opción priority en fetch(). Está disponible en Chromium desde la versión 101, en Safari desde 17.2 y en Firefox desde la 132, de octubre de 2024. En un navegador que no lo entienda, el atributo se ignora sin efectos secundarios y la heurística por defecto sigue funcionando: es seguro ponerlo sin detección de características ni respaldo.

La mejora típica en el LCP de una página cuyo elemento mayor es una imagen sobre el pliegue está entre 100 y 500 milisegundos en condiciones de red móvil, y sube mucho más si la página tiene muchas imágenes compitiendo. Es el tipo de mejora que no consigues comprimiendo el fichero otra vez.

Bajar la prioridad también es una herramienta

La otra mitad del atributo se usa menos y a veces rinde más. fetchpriority="low" sirve para apartar de la cola recursos que están dentro del viewport pero no importan.

El caso canónico es un carrusel. Las tres o cuatro diapositivas de un carrusel están todas en el viewport según el layout, así que todas suben a prioridad alta y todas compiten con la primera, que es la única que el usuario va a ver. Marcar la primera con high y el resto con low reordena la cola de forma que la visible llega antes:

<div class="carrusel">
  <img src="d1.avif" width="1200" height="675" alt="Sala principal" fetchpriority="high">
  <img src="d2.avif" width="1200" height="675" alt="Terraza" fetchpriority="low" loading="lazy">
  <img src="d3.avif" width="1200" height="675" alt="Cocina" fetchpriority="low" loading="lazy">
</div>

El mismo razonamiento vale para logotipos de patrocinadores en la cabecera, iconos decorativos y avatares: están arriba, pero nadie mide su tiempo de carga.

decoding: sacar el trabajo de píxeles del camino

Descargar una imagen y decodificarla son dos cosas distintas. La decodificación convierte los bytes comprimidos en un mapa de píxeles en memoria, y es una operación de CPU que escala con el número de píxeles del fichero, no con su peso comprimido. Una imagen de 2000 por 1000 son dos millones de píxeles, y decodificarla en un móvil de gama media cuesta del orden de 20 a 60 milisegundos. Un AVIF cuesta más que un JPEG del mismo tamaño, porque el formato es computacionalmente más caro de decodificar a cambio de comprimir mejor.

El atributo decoding tiene tres valores y controla si el navegador puede hacer ese trabajo fuera del hilo principal:

• sync: decodifica en el hilo principal antes de presentar el siguiente fotograma. Bloquea, pero garantiza que la imagen aparece en el mismo pintado que el resto del contenido.
• async: permite decodificar fuera del hilo principal y presentar el contenido sin esperar. La imagen puede aparecer un fotograma más tarde.
• auto: por defecto. El navegador decide, y en la práctica hace algo muy parecido a async en la mayoría de los casos modernos.

La diferencia práctica entre auto y async es pequeña hoy, y en muchas mediciones no se distingue. Donde async sí paga es en inserciones de imágenes durante la interacción: cuando el usuario abre una galería, filtra un listado o navega en un cliente, insertar diez <img> con decoding="sync" puede meter cien milisegundos de decodificación en el hilo principal justo en el fotograma de respuesta, y eso sale directamente en el INP.

Para ese caso hay una herramienta mejor que el atributo, y es el método decode(), que devuelve una promesa que se resuelve cuando la imagen está lista para pintarse sin bloquear:

async function mostrarSinParpadeo(url, contenedor) {
  const img = new Image();
  img.src = url;
  img.decoding = 'async';
  try {
    await img.decode();          // decodifica fuera del hilo principal
  } catch {
    return;                       // fallo de red o formato no soportado
  }
  contenedor.replaceChildren(img); // insertar ya decodificada: cero trabajo en el pintado
}

Este patrón resuelve a la vez dos problemas: no bloquea el hilo al insertar, y evita el parpadeo de un elemento que aparece vacío y se rellena un fotograma después. Es la forma correcta de cambiar la imagen grande de un visor o de un carrusel.