Image decoding en un thread dedicado

¿Tiene sentido? ¿Cuándo es necesario hacerlo? ¿Por qué sibarita es tan rica?

El proceso de image decoding sucede luego de descargar una imagen cuando el browser obtiene la información de los colores de cada pixel para saber cómo dibujarla en la pantalla (rasterización).

El tiempo y uso de memoria de este proceso varia según el peso y tamaño de la imagen por lo que puede llegar a penalizar el renderizado general. Un punto para ver de cerca en Web Performance.

Si enviamos esta tarea a otro thread podemos llegar a beneficiarnos y destrabar el render de elementos más importantes, como por ejemplo texto.

HTML ofrece la propiedad decoding que permite indicarle al browser si hacerlo de manera "sync" o "async".

<img decoding="async" src="foo.png"/>

Desde JavaScript podemos utilizar el método decode(), antes de agregar una imagen al DOM, para realizar esta tarea en un nuevo thread dedicado.

// Image decoding en un thread dedicado
const img = new Image();
img.src = 'foo.png';
img.decode().then(() => {
  document.body.appendChild(img);
}).catch(() => {
  throw new Error('Oops!');
});

De esta manera, la decodificación no bloquea el thread principal del render.

El engine Blink tiene un thread especial para todo lo relacionado al rasterizado llamado Compositor Thread y el proceso de image decoding sucede allí, a través de los raster threads.

Hay que tener en cuenta la arquitectura de cada browser para entender en dónde ocurre y cómo se puede optimizar.

Contestando las preguntas iniciales:

¿Tiene sentido?

Si.

¿Cuándo es necesario hacerlo?

Creo que el escenario se da cuando tenemos muchas imágenes o pocas pero con un peso importante, y el decoding puede competir con el render de otros elementos. Hay que analizar cada caso!

¿Por qué sibarita es tan rica?

Una pregunta que nunca tendrá respuesta. Ok, polilla.

Chao. 🚀