En bref : un placeholder flou n'est pas de la décoration — c'est une correction du Cumulative Layout Shift déguisée en effet de chargement, puisqu'un placeholder correctement dimensionné réserve l'espace exact de l'image avant l'arrivée du fichier réel. Associez ce guide à Character Counter, Encoding Converter, Text Difference et AI Hidden Characters.

LQIP (Low Quality Image Placeholder) est une version minuscule et fortement compressée de l'image réelle — souvent 20×20 pixels ou moins, quelques centaines d'octets — affichée floue et agrandie pendant que le fichier en pleine résolution se charge.

Le vrai problème que résout LQIP : le décalage de mise en page, pas l'esthétique

Sans un placeholder qui réserve les dimensions finales de l'image, la page se rend sans espace pour l'image, puis pousse tout ce qui se trouve en dessous vers le bas au moment où le fichier arrive — le Cumulative Layout Shift (CLS), l'une des Core Web Vitals de Google, pénalise exactement cela. Un placeholder au même ratio d'aspect (flou ou non) occupe le bon espace dès le premier rendu, donc rien ne bouge quand l'image réelle se charge — le flou est un plus par-dessus la vraie correction, qui est de réserver l'espace.

Comment une image minuscule est intégrée instantanément

Les placeholders LQIP sont généralement intégrés en tant qu'URI de données encodées en base64 directement dans le HTML — <img src="data:image/jpeg;base64,..."> — de sorte que le placeholder se rend avec zéro requête réseau supplémentaire, ce qui compte car tout l'intérêt est de montrer quelque chose avant même que la requête de l'image réelle ne se résolve. Comme l'image source est minuscule (souvent moins d'1 Ko avant encodage), la surcharge du base64 — environ 33% plus grand que les octets bruts — est négligeable pour un placeholder malgré son gaspillage pour une image en pleine taille.

LQIP vs. un placeholder à couleur dominante unie

Une micro-miniature floue porte plus d'information visuelle (formes approximatives, distribution des couleurs) qu'un simple rectangle à couleur dominante, mais cela signifie aussi plus de travail de configuration — générer et stocker une petite image par photo, contre calculer une seule couleur moyenne. Pour une galerie photo dense où l'image elle-même est le sujet, la fidélité supplémentaire de LQIP en vaut généralement la peine ; pour des images d'interface plus petites ou des icônes, un placeholder à couleur unie fait le travail de prévention du CLS avec moins de surcharge.

Un flux de travail pour ajouter des placeholders correctement

  1. Définissez un width et height explicites (ou un aspect-ratio CSS) sur chaque balise image — c'est ce qui réserve réellement l'espace ; l'image placeholder elle-même ne le fait pas seule.
  2. Générez le placeholder minuscule au vrai ratio d'aspect de l'image, pas à une taille fixe qui ne correspond pas — un ratio incompatible produit un décalage quand l'image réelle la remplace.
  3. Intégrez le placeholder en tant qu'URI de données base64 pour un chargement à zéro requête, réservé uniquement aux images placeholder vraiment petites.
  4. Testez avec la limitation de débit réseau du navigateur — la valeur d'un placeholder n'apparaît que quand l'image réelle met du temps à arriver.

Erreurs courantes à éviter

  • Ajouter un effet de flou sans aussi définir des dimensions explicites — le flou seul ne fait rien pour le décalage de mise en page.
  • Utiliser un placeholder avec un ratio d'aspect différent de l'image réelle, ce qui cause un décalage de toute façon quand elle est remplacée.
  • Intégrer en base64 une image en pleine taille "pour la cohérence", gonflant le poids de la page sans aucun bénéfice de placeholder.
  • Traiter LQIP purement comme un effet visuel et manquer que son vrai travail est de réserver l'espace de mise en page.

Le flou est ce que les utilisateurs remarquent ; la réservation de dimensions en dessous est ce qui protège réellement votre score Core Web Vitals.