Handsum : le format de placeholder d'image ultra-léger pour votre LCP

Nigel Tao, développeur connu pour son travail sur les décodeurs d'image du langage Go (les paquets image/webp et image/jpeg de la bibliothèque standard) et sur le format WebP2 chez Google, a publié en 2026 sur son blog personnel un article détaillant un nouveau format de placeholder d'image baptisé Handsum. Son objectif : afficher un aperçu flou quasi instantané pendant que votre image en haute résolution charge en arrière-plan, avec une contrainte inédite chez les formats LQIP : une taille en octets fixe et garantie.

LQIP, LCP : de quoi parle-t-on exactement

Pour ceux qui découvrent le sujet, un LQIP (Low Quality Image Placeholder) est une miniature volontairement dégradée, à la fois minuscule en dimensions (quelques dizaines de pixels) et en poids (quelques dizaines d'octets), que l'on encode en base64 pour l'injecter directement dans le HTML ou le CSS de la page. Aucune requête réseau supplémentaire, un rendu immédiat pendant que le fichier définitif se télécharge, et une sensation de rapidité pour le visiteur même sur une connexion mobile médiocre. Les techniques les plus répandues aujourd'hui sont Blurhash et Thumbhash, deux formats propriétaires dédiés au flou, ainsi que la méthode plus artisanale consistant à générer un JPEG ou un WebP de très basse qualité et de très petites dimensions.

Le LCP (Largest Contentful Paint), l'un des trois Core Web Vitals surveillés par Google, mesure le temps nécessaire pour afficher le plus gros élément visible de la page, très souvent une image héro ou une photo de produit. Un LQIP ne réduit pas ce chiffre en soi puisque l'image définitive doit toujours finir de se charger. Ce qu'il change, c'est la perception : le visiteur voit une forme, des couleurs, une composition dès la première peinture de la page, plutôt qu'un rectangle vide ou un décalage brutal de mise en page au moment où l'image apparaît. Sur un site e-commerce ou un portfolio qui affiche des dizaines de vignettes, cet effet cumulé pèse lourd dans l'expérience perçue, même si les outils d'audit ne le chiffrent pas directement dans le score LCP.

Comment Handsum fabrique ses 147 octets

Handsum repose sur la Transformée en Cosinus Discrète (DCT), la même brique mathématique qu'utilisent Blurhash, Thumbhash et le JPEG lui-même. L'encodage se déroule en plusieurs étapes successives :

• Redimensionnement. L'image source est réduite dans un carré de 16x16 pixels, ce qui donne 768 octets de données en RGB brut (3 octets par pixel).
• Conversion YCbCr. Les mêmes formules que le JPEG et la norme BT.601 séparent la luminance (Y) de la chrominance (Cb, Cr). Cette transformation est, en théorie, sans perte.
• Sous-échantillonnage de la chrominance. L'œil humain est bien moins sensible à la couleur qu'à la luminosité. Handsum supprime 75% des deux canaux de chrominance (le format 4:2:0, déjà utilisé par le WebP et une majorité de JPEG), ce qui fait retomber le total de 768 à 384 octets, une économie de 50%.
• DCT et quantification. Les données restantes passent par la transformée DCT puis une quantification qui ajuste la précision selon le niveau de qualité choisi, jusqu'à atteindre la taille finale fixe visée.

Le fichier final ajoute un en-tête de 3 octets (une signature de 15 bits, un mode couleur sur 2 bits, un niveau de qualité sur 2 bits et un ratio d'aspect sur 5 bits). Résultat : un fichier Handsum pèse exactement 48 octets au niveau de qualité le plus bas (q=1), 75 octets (q=2), 123 octets (q=3) ou 147 octets au niveau le plus élevé (q=4), quelle que soit l'image d'origine. Le format gère aussi trois modes de couleur : niveaux de gris, RGB/YCbCr classique, et RGB avec canal alpha.

Face à Thumbhash, WebP, ETC2 et JPEG

Dans son article, Nigel Tao compare Handsum à cinq autres approches sur dix images célèbres (le portrait de Lincoln, la Joconde, la Jeune Fille à la perle, la Grande Vague, entre autres), toutes réduites dans un carré de 32x32 pixels. Le résultat est parlant : Thumbhash produit des fichiers extrêmement compacts, entre 24 et 27 octets, mais la qualité visuelle reste très approximative. Au niveau de qualité le plus bas (q=1, 48 octets), Handsum reste comparable en poids, avec une différence de l'ordre de 24 octets seulement, mais offre une image nettement plus reconnaissable, en particulier sur des portraits comme la Joconde ou la Jeune Fille à la perle. Au niveau de qualité le plus élevé (q=4, 147 octets), Handsum devient comparable en qualité au WebP en mode lossy ou à l'ETC2 (le format de compression de texture utilisé par les GPU), pour un budget d'octets équivalent.

L'argument qui change tout pour les catalogues : une taille fixe garantie

C'est là que Handsum trouve sa véritable niche. Imaginez une application (catalogue d'œuvres d'art, fiches produit, base de morceaux audio) où chaque entrée dispose d'un budget fixe de 256 octets : 50 octets pour le nom de l'artiste, 50 pour le titre de l'œuvre, quelques octets de métadonnées, et environ 150 octets restants pour la miniature. Avec le WebP, dont les encodeurs n'exposent qu'un réglage de qualité et jamais un budget d'octets cible, obtenir une image sous les 150 octets à chaque fois demande des tâtonnements : on encode, on mesure, on réajuste la qualité, on recommence. Avec Handsum au niveau q=4, vous obtenez 147 octets à chaque fois, sans exception. Pour qui stocke ses miniatures dans une colonne de base de données à taille fixe, ce déterminisme facilite grandement l'itération et la lecture des données.

Tester le format dès maintenant

Nigel Tao propose une démonstration web du format, avec un décodeur Handsum écrit en C et compilé en WebAssembly. Le format n'est volontairement pas généraliste : la dimension la plus longue de l'image décodée fait toujours 16 pixels, l'autre dimension étant déduite de l'aspect ratio stocké dans l'en-tête. Handsum n'a donc pas vocation à remplacer vos images de contenu, uniquement leurs miniatures et leurs placeholders.

Notre lecture chez CZSyn

Sur les projets que nous accompagnons à Marseille, la plupart des sites (vitrines, e-commerce, blogs) utilisent déjà des solutions bien rodées comme Thumbhash ou les mécanismes de blur intégrés aux frameworks JavaScript pour ce genre d'effet, et elles font très bien le travail. L'intérêt de Handsum n'est donc pas de remplacer ces outils sur un site marketing classique, mais de répondre à un besoin plus spécifique : les catalogues volumineux (galeries immobilières, places de marché, applications de gestion documentaire) où l'on stocke des milliers de miniatures et où une taille de fichier prévisible simplifie réellement le schéma de base de données et les performances d'itération.

Le format reste très jeune : à ce stade, la référence est un décodeur en C compilé en Wasm, sans package npm officiel ni intégration native dans les frameworks JavaScript courants. Avant de l'intégrer en production, nous recommandons de suivre la maturité de son écosystème d'outils, et de continuer à vous appuyer sur Thumbhash ou Blurhash, aujourd'hui largement supportés, pour vos projets du quotidien. Mais si vous développez une application avec un vrai enjeu de stockage massif de miniatures, Handsum mérite clairement un test.

Sources primaires

• Nigel Tao, « Handsum: An LQIP Image File Format », blog personnel, 2026.
• Documentation officielle du format Blurhash, blurha.sh.
• Documentation officielle du format Thumbhash, evanw.github.io/thumbhash.