Optimisation des images web : protocole vérifiable, formats, LCP et qualité perceptive

Le poids seul ne suffit pas. Une image de 5 Ko peut être une réussite sur une vignette et un échec sur un écran haute densité. À l’inverse, un fichier plus lourd peut être le bon choix s’il est l’élément LCP, s’affiche en grand et conserve des détails essentiels. La décision relie donc six variables : rôle, dimensions rendues, densité de pixels, format, qualité perceptive et moment de chargement.

Le Web Almanac 2025 observe que les images constituent l’élément LCP sur 85,3 % des pages desktop et 76 % des pages mobile de son échantillon. Son chapitre sur le poids des pages relève environ 1 059 Ko d’images au desktop et 911 Ko au mobile pour la page médiane. Ce sont des repères de contexte, pas des budgets à copier.

Le 22 août 2026, l’image principale publique de cet article sélectionnait un AVIF de 600×400 px et 4 794 octets. L’élément HTML ne proposait ni srcset ni sizes, alors que l’image occupait jusqu’à environ 445 px CSS dans la mise en page desktop. Sur un écran à densité 2, la définition utile approchait donc 890 px. Le chargement était correctement priorisé — loading="eager", fetchpriority="high" — mais la ressource sélectionnée pouvait manquer de définition.

Nous avons comparé cet AVIF à son propre master JPEG conservé en 1000×667, redimensionné en 600×400 avec Lanczos pour isoler l’encodage. Le score SSIMULACRA2 obtenu est 62,4404. La nouvelle édition change aussi de direction visuelle : ses dérivés sont donc comparés à un nouveau master PNG 1536×1024, jamais directement à l’ancien visuel. Ces deux séries établissent la fidélité de chaque encodage à sa propre référence ; elles ne constituent pas un test A/B artistique.

Le protocole a été rejoué sur la page publique avec Playwright, de 390 à 1440 px et de DPR 1 à DPR 2. Chaque scénario conserve l’URL finale, le statut HTTP, la boîte CSS, currentSrc, les dimensions naturelles, les octets transférés, le nombre de contrôles visibles et les erreurs de console. Les candidats réellement observés sont les AVIF de 600×400 et 900×600 : le navigateur ne télécharge donc pas systématiquement le plus grand fichier disponible.

Le même état public a été mesuré avec Lighthouse. En laboratoire, le profil mobile obtient 99/100 en performance, 100/100 en accessibilité et un LCP à 1,9 s ; le profil desktop obtient 100/100 en performance et un LCP à 0,4 s. Ces valeurs décrivent un passage daté, sans cache utilisateur ni distribution terrain.

Chaque contrôle possède un identifiant stable IMGxx, une méthode, une preuve attendue, un accès requis, une sévérité et un niveau d’automatisation. Les statuts sont limités à Non testé, Conforme, Non conforme et Non applicable. Une image décorative sans alternative textuelle pertinente n’est pas « moins bonne » qu’une image informative : elle répond à une autre décision.

Le protocole n’additionne pas les lignes. Un alt vide sur une image fonctionnelle, une image LCP lazy loadée ou un traceur tiers déclenché avant consentement peuvent bloquer une publication même si tous les autres contrôles réussissent.

Une première approximation utile est : largeur du fichier nécessaire ≈ largeur rendue × DPR. Une image affichée à 445 px sur un écran 2× appelle environ 890 px. Ce calcul ne constitue pas un ordre absolu : la texture, le niveau de zoom, le format et la qualité modifient la perception. Il évite néanmoins deux erreurs opposées : servir 2000 px à une vignette de 240 px, ou 600 px à une héroïne de 445 px sur écran Retina.

Dans un descripteur en largeur, chaque valeur de srcset doit décrire la largeur réelle du fichier. sizes décrit ensuite l’espace que l’image occupe dans la mise en page. Le navigateur combine viewport, DPR et candidats pour choisir une ressource ; il peut conserver un candidat déjà en cache.

PSNR, SSIM, SSIMULACRA2 ou Butteraugli peuvent aider à comparer des variantes, mais aucune métrique ne remplace le cadrage, le sens ni la validation de zones sensibles. Un protocole publiable indique au minimum le master, la mise à l’échelle, l’encodeur et sa version, les paramètres, le score, le poids et les limites de lecture.

Le score de cette page a été calculé à taille identique. Comparer directement un dérivé à un master d’une autre taille aurait mélangé l’effet du redimensionnement et celui de l’encodage. Chaque variante est donc comparée à une référence PNG issue de son propre master, redimensionnée avec Lanczos aux mêmes dimensions. Le changement de création entre l’ancienne et la nouvelle édition interdit toute comparaison directe des deux scores.

Google et web.dev insistent sur trois leviers : rendre la ressource découvrable depuis le HTML initial, éviter le lazy loading pour l’élément LCP et augmenter sa priorité avec discernement. Un preload peut aider lorsque l’image est découverte tardivement — image CSS, composant ou rendu particulier — mais un preload redondant peut consommer de la bande passante et provoquer un double téléchargement si ses candidats ne correspondent pas.

Une image de premier écran n’est pas automatiquement le LCP de tous les utilisateurs. Le LCP peut varier selon viewport, consentement, contenu et cache. Le contrôle terrain observe la distribution ; le laboratoire sert à identifier la chaîne de découverte et la ressource réellement choisie.

L’arbre de décision du W3C distingue notamment images informatives, fonctionnelles, complexes, textuelles et décoratives. Une même photo peut nécessiter une alternative sur une page produit et un alt="" dans une composition purement décorative. Répéter la légende ou le paragraphe voisin dans alt alourdit l’expérience sans ajouter d’information.

Une capture d’écran ou un graphique complexe ne devient pas accessible grâce à une phrase vague. Il faut transmettre l’information utile dans le texte adjacent, une légende, une description longue ou un tableau de données. L’automatisation peut repérer un attribut manquant ; elle ne peut pas décider seule si l’alternative est pertinente.

La documentation Google recommande des images de qualité placées près d’un texte pertinent, des noms et alternatives descriptifs, ainsi que des URL accessibles. Google découvre les images référencées par <img src>, y compris à l’intérieur de <picture>, mais pas les images uniquement déclarées en arrière-plan CSS pour Google Images.

Un sitemap image peut révéler des URL difficiles à découvrir. Si les images sont servies depuis un CDN ou un autre domaine, Google recommande de vérifier ce domaine dans Search Console. Les données structurées peuvent relier primaryImageOfPage, ImageObject, licence et créateur lorsque ces informations existent réellement ; elles ne compensent ni un fichier bloqué ni un contexte éditorial faible.

Une ressource nommée par contenu — hash ou version immuable — peut recevoir une durée de cache longue. Une URL stable remplacée en place exige une stratégie d’invalidation différente. Le contrôle relève Cache-Control, ETag, Age, négociation éventuelle et comportement du CDN au lieu de supposer qu’un cache « actif » est correct.

Les dérivés publics ne devraient pas conserver par défaut coordonnées GPS, informations d’appareil ou métadonnées éditoriales inutiles. Le pipeline documente ce qui est retiré et ce qui est conservé — profil colorimétrique compris — puis génère toutes les variantes depuis un master, jamais depuis un WebP ou AVIF déjà dégradé.

Le rapport produit respecte un schéma JSON public. Son statut initial reste Non testé : collecter une valeur ne suffit pas à conclure. L’auditeur relie ensuite chaque observation à un identifiant IMGxx, ajoute les accès non publics nécessaires et signe la décision.

Référence recommandée : Morel, Bertrand (2026). « Optimisation des images web : protocole vérifiable, grille de 36 contrôles et collecteur de preuves ». Edikka, version 1.1, 23 août 2026, CC BY 4.0. Le fichier CITATION.cff fournit les champs structurés. Aucun DOI n’est attribué à cette édition : l’URL canonique, la version et la date sont les clés de citation publiées.