Glissez une image ou cliquez pour sélectionner
PNG, JPEG, WebP, GIF, BMP, AVIF
Comment ça marche
Un espace réservé est ce qui prend la place d'une image pendant son téléchargement. Il sert à deux choses distinctes : réserver l'espace exact qu'elle occupera, afin que le texte alentour ne saute pas quand elle apparaît, et montrer quelque chose de proche du contenu final pour que l'attente paraisse plus courte que face à un rectangle gris.
Il existe trois familles de solutions. Les hachages compacts (BlurHash et ThumbHash) résument l'image en une chaîne de texte si courte que vous pouvez la stocker dans une colonne de la base de données avec le reste de l'enregistrement ; le navigateur la décode et dessine le flou. Les data URI (la miniature LQIP et le SVG) transportent l'image déjà encodée dans le HTML ou le CSS, ils n'ont donc besoin d'aucun JavaScript. Et la couleur unie est l'espace réservé le moins coûteux de tous : sept caractères.
Le choix dépend de l'origine du HTML. Si les images proviennent d'une base de données et que vous les listez par centaines, le hachage est le plus léger par enregistrement. Si vous générez des pages statiques ou utilisez un framework qui gère déjà les espaces réservés, le data URI évite d'ajouter du code de décodage. Toutes les valeurs affichées ici sont calculées dans votre navigateur : l'image n'est envoyée à aucun serveur.
Exemples
blurhash 4 × 3LGHC162?|cKNqSWDjtaghVfjfQfjLa longueur d'un BlurHash ne dépend que du nombre de composantes, ni de la taille ni du contenu de l'image : avec 4 × 3 ce sont toujours 28 caractères, avec 3 × 3 c'est 22 et avec 5 × 4 c'est 44.thumbhash3wcKNZpwh3eAiIh3iHiIiHCAB/eHUn ThumbHash occupe entre 17 et 25 octets, soit 24 à 36 caractères en Base64. La taille exacte dépend du rapport d'aspect de l'image et de la présence ou non de transparence, car le format encode aussi le canal alpha.lqip 24 px webpdata:image/webp;base64,UklGRi…Une miniature WebP de 24 px de large reste généralement sous 1 Ko. Étant intégrée au HTML, elle ne génère pas de requête supplémentaire, mais elle alourdit le document, qui n'est pas mis en cache séparément.Cas d'usage
- Stocker un BlurHash ou un ThumbHash dans la table des images pour qu'une liste ou un fil à défilement infini affiche quelque chose dès le premier instant.
- Renseigner l'attribut blurDataURL de next/image ou le placeholder de NgOptimizedImage lorsque l'image n'est pas un import statique.
- Éviter le décalage de mise en page (CLS) dans les cartes produit ou article en combinant l'espace réservé avec les attributs width et height.
- Intégrer un espace réservé dans du HTML statique, un e-mail ou un modèle où vous ne pouvez pas exécuter de JavaScript de décodage.
- Réutiliser le même BlurHash sur le web et dans les applications mobiles, qui disposent de décodeurs en Swift, Kotlin et Flutter.
- Utiliser la couleur moyenne comme fond de conteneur quand le budget en octets ne permet même pas une miniature.
Questions fréquentes
BlurHash ou ThumbHash ?
ThumbHash reproduit l'image plus fidèlement en moins d'octets, préserve la transparence et enregistre le rapport d'aspect : vous n'avez même pas besoin de connaître la taille d'origine pour le dessiner. BlurHash est antérieur et moins précis, mais il dispose d'implémentations pour bien plus de plateformes et de langages. Si vous partez de zéro, ThumbHash ; si vous avez déjà des décodeurs BlurHash dans votre stack, aucune raison de migrer.
Est-ce que cela améliore le LCP ?
Pas directement. L'espace réservé améliore la perception de la vitesse et, avec width et height, supprime le décalage de mise en page, mais la métrique LCP reste mesurée à la fin du rendu de l'image réelle. Mieux : si l'image principale est l'élément LCP, ne lui mettez pas loading="lazy" et ne la différez pas derrière un espace réservé ; marquez-la plutôt avec fetchpriority="high" pour que le navigateur la demande plus tôt. Les espaces réservés sont destinés aux images situées hors du premier écran.
Combien de composantes utiliser pour un BlurHash ?
Quatre par trois fonctionne bien pour les images en paysage et trois par quatre pour les portraits. Chaque composante supplémentaire ajoute deux caractères et un peu plus de détail, mais au-delà de six ou sept la différence cesse d'être perceptible à l'œil nu, puisque le résultat est de toute façon affiché flou.
Hachage ou data URI ?
Le hachage occupe quelques dizaines d'octets par image et convient parfaitement quand il y en a beaucoup sur la même page, mais il exige du code côté client pour le décoder. Le data URI n'a besoin de rien, même s'il pèse dix à cinquante fois plus et voyage dans le HTML, qui n'est pas mis en cache séparément. Avec quelques images mises en avant, préférez le data URI ; avec de longues listes, le hachage.
Pourquoi utiliser le SVG plutôt que la miniature directement ?
Parce que le flou est appliqué par le navigateur au moment de dessiner le SVG. Cela vous permet de partir d'une miniature bien plus petite sans que les blocs de pixels apparaissent à l'agrandissement, et le rendu reste tout aussi lisse à n'importe quelle taille. Le SVG force également l'alpha à opaque, pour que le flou ne rende pas les bords transparents.
Existe-t-il une limite de taille pour l'espace réservé ?
Cela dépend de l'outil. Le NgOptimizedImage d'Angular affiche un avertissement dans la console quand le data URI de l'espace réservé dépasse 4000 caractères, car au-delà le poids du HTML l'emporte sur le bénéfice. C'est une bonne référence générale : si votre miniature dépasse cette valeur, réduisez la largeur ou la qualité.