Optimisez les images en choisissant un format adapté, en générant des variantes utiles et en laissant le navigateur sélectionner celle qui correspond à la mise en page. Réservez leur espace, différez celles réellement hors écran et chargez rapidement l’image susceptible de devenir LCP. La compression ne suffit pas : une variante trop grande ou une requête tardive peut annuler le bénéfice d’un meilleur encodeur.
Commencez par l’image réellement téléchargée
Avant de modifier l’export, inspectez une page représentative dans Network. Rechargez-la avec une fenêtre mobile puis de bureau. Notez l’URL demandée, le poids transféré, les dimensions affichées et intrinsèques et le début de la requête. Une petite vignette peut recevoir l’original alors que le CMS a créé des variantes adaptées.
Repérez l’image LCP pour chaque disposition. Ce peut être une photographie principale sur un écran et une image produit sur un autre. Le guide d’optimisation du LCP distingue découverte, transfert et rendu pour éviter de tout traiter comme un problème de compression.
Conservez les originaux séparément des fichiers diffusés afin de régénérer les variantes sans recompresser une image déjà dégradée. Testez photographies, captures, illustrations, transparences et texte intégré. Un réglage acceptable pour un paysage peut abîmer une étiquette produit ou un diagramme.
Distinguez contenu et décoration. Les images significatives nécessitent un texte alternatif décrivant leur fonction ; les décoratives peuvent avoir une alternative vide. Ne remplacez pas une image sémantique par un fond CSS pour modifier un audit. Les fonds conviennent à la décoration mais changent découverte et accessibilité. Si une image constitue seule un lien, son nom accessible doit expliquer la destination. Vérifiez ces points avec dimensions et chargement.
Établissez une référence avant une conversion générale. Sauvegardez des captures et notez les requêtes précédant le contenu principal. C’est une méthode d’inspection, pas un benchmark : une nouvelle extension ne garantit aucun pourcentage universel d’économie.
Adaptez le format au contenu
Choisissez selon l’image et les besoins de diffusion. AVIF et WebP sont utiles, mais leur résultat dépend du motif, de l’encodeur, des réglages et des navigateurs visés. JPEG et PNG conservent des usages pertinents ; SVG répond à un autre besoin que la compression matricielle.
Utilisez ce tableau comme point de départ, puis comparez les fichiers produits.
| Format | Usage initial pertinent | Points à examiner |
|---|---|---|
| AVIF | Photographies et images complexes acceptant des pertes | Détails, dégradés, durée d’encodage et compatibilité |
| WebP | Photographies, illustrations, variantes avec ou sans perte | Contours, transparence et gain à qualité acceptable |
| JPEG | Photographies et solution de repli compatible | Blocs, halos et dégradation après réencodages |
| PNG | Images sans perte, certaines captures et transparences | Variante moderne plus légère sans perte ou visuellement acceptable |
| SVG | Icônes, logos et illustrations géométriques vectorielles | Complexité, raster intégré et sécurité des fichiers importés |
Une photographie encapsulée dans SVG ne devient pas une illustration vectorielle compacte. Un format sans perte ne corrige pas non plus des dimensions excessives. Examinez l’image avant d’accuser son extension.
Les nombres de qualité dépendent de l’encodeur. Un réglage 70 n’équivaut pas objectivement à 70 ailleurs, et aucun réglage ne garantit des pertes invisibles pour tous les contenus. Comparez à la taille prévue et à densité supérieure. Examinez cheveux, texte, contours, dégradés et détails produit. Fixez une qualité défendable avant de minimiser les octets.
Retirez les métadonnées superflues des dérivés publics lorsque cela convient, tout en préservant attribution et gestion des couleurs nécessaires. Gardez la source avec son profil colorimétrique. Vérifiez le résultat dans les navigateurs cibles : l’éditeur et la chaîne de production peuvent afficher différemment.
Décrivez les largeurs disponibles avec srcset
La largeur CSS n’est pas nécessairement le nombre de pixels physiques requis. La densité compte. Pour une image affichée sur 600 pixels CSS, un écran dense peut justifier une source plus large. N’imposez pas que la largeur intrinsèque reste toujours inférieure à la largeur CSS.
Avec les descripteurs de largeur, srcset indique les fichiers disponibles et leur largeur réelle. sizes décrit la largeur d’affichage attendue selon les conditions média. Le navigateur combine cela avec le contexte de navigation et garde le choix final ; le balisage n’ordonne pas une URL précise à chaque rupture.
Cet exemple correspond à des marges latérales de 16 pixels sous 992 pixels et à une largeur maximale de 960 pixels au-delà. Les variantes doivent exister aux dimensions déclarées.
<style>
.article-image {
display: block;
width: min(100%, 960px);
height: auto;
}
.article-content {
width: calc(100% - 32px);
max-width: 960px;
margin-inline: auto;
}
</style>
<div class="article-content">
<img class="article-image"
src="/images/coast-960.webp"
srcset="/images/coast-480.webp 480w,
/images/coast-960.webp 960w,
/images/coast-1920.webp 1920w"
sizes="(max-width: 991px) calc(100vw - 32px), 960px"
width="1920" height="1080"
alt="Rocky coastline beside a calm blue sea">
</div>Le seuil suit la géométrie : 992 moins 32 donne 960. Gardez CSS et sizes cohérents lors des changements de design. Un sizes="100vw" incorrect sur une carte étroite peut entraîner un fichier inutilement lourd.
Inspectez currentSrc pour connaître la sélection. Testez après une nouvelle navigation : au redimensionnement, le navigateur peut réutiliser un grand candidat en cache plutôt qu’en télécharger un petit. Incluez des densités réalistes, pas seulement des largeurs de fenêtre.
Utilisez picture pour les formats et les cadrages
picture ajoute des règles explicites. Il sert aux formats et à la direction artistique, lorsqu’un recadrage mobile modifie la composition plutôt que les seuls pixels. L’élément img obligatoire porte toujours l’alternative textuelle et la source de repli.
Cet exemple propose deux encodages modernes puis JPEG pour la même composition et le même rapport de dimensions.
<picture>
<source type="image/avif"
srcset="/images/garden-800.avif 800w,
/images/garden-1600.avif 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<source type="image/webp"
srcset="/images/garden-800.webp 800w,
/images/garden-1600.webp 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<img src="/images/garden-800.jpg"
srcset="/images/garden-800.jpg 800w,
/images/garden-1600.jpg 1600w"
sizes="(max-width: 800px) 100vw, 800px"
width="1600" height="1000"
style="display:block;width:min(100%,800px);height:auto"
alt="Raised garden beds arranged along a stone path">
</picture>Le navigateur parcourt les sources dans l’ordre et retient la première option compatible correspondante. N’ajoutez pas des formats uniquement pour allonger le code : génération, stockage et invalidation doivent être justifiés par les images et le public.
Pour un cadrage spécifique, ajoutez media à une source. Si le rapport change, réservez le bon espace au seuil correspondant avec les dimensions de source ou CSS. Un rapport de bureau appliqué à un recadrage vertical peut produire mouvement ou espace vide. Vérifiez position du sujet, texte et détails produit dans chaque cadrage.
Réservez l’espace et avancez la requête LCP
width et height permettent de déduire un rapport avant l’arrivée du fichier. Le CSS responsive peut continuer à redimensionner l’image. Ces attributs ne forcent pas ses dimensions d’affichage ; ils renseignent la mise en page avant décodage.
Sans dimensions, le contenu inférieur peut bouger à l’arrivée de l’image. Le guide des décalages de mise en page détaille ce problème. Inspectez aussi conteneurs, carrousels et espaces réservés : un img correct peut se déplacer si son parent change de hauteur après initialisation JavaScript.
Utilisez loading="lazy" pour les images suffisamment éloignées du premier écran. Le chargement différé natif suit des heuristiques et ne signifie pas exactement « télécharger seulement une fois visible ». Le navigateur peut anticiper pour éviter un vide pendant le défilement.
Cet exemple situé plus bas réserve l’espace et autorise le décodage asynchrone.
<img src="/images/workshop-960.webp"
width="960" height="640"
loading="lazy" decoding="async"
style="max-width:100%;height:auto"
alt="Hand tools organized on a workshop wall">Ne différez pas l’image LCP probable. Rendez son URL réelle découvrable dans le HTML initial, si possible, plutôt que seulement dans un attribut de données lu par JavaScript. fetchpriority="high" signale une priorité, mais ne résout pas une ressource encore introuvable.
Cette image principale demande un chargement immédiat et une priorité élevée.
<img src="/images/hero-1600.webp"
srcset="/images/hero-800.webp 800w,
/images/hero-1600.webp 1600w"
sizes="100vw"
width="1600" height="900"
loading="eager" fetchpriority="high"
style="display:block;width:100%;height:auto"
alt="Sunlight falling across a quiet mountain valley">decoding="async" est une indication de coordination entre décodage et présentation, pas un réglage de compression ni une garantie de meilleur LCP. Évaluez le contexte visuel et la trace. Évitez la priorité élevée partout : les requêtes partagent toujours bande passante et traitement.
Inspectez le HTML produit
CMS, thème et extension peuvent chacun modifier les attributs. Contrôlez la réponse finale et la requête choisie, pas seulement le modèle édité.
Rendez la chaîne de traitement reproductible
Un CDN d’images peut générer tailles, recadrages et encodages, puis les livrer par des caches distribués. Cela aide seulement si les modèles demandent les bonnes variantes. Rapprocher géographiquement l’original ne corrige pas automatiquement une mauvaise taille responsive.
Définissez une famille limitée de largeurs correspondant aux mises en page récurrentes. Générer chaque largeur entière complique cache, traitement et stockage. Incluez format et transformations dans l’identité de cache et vérifiez la mise en cache correcte des réponses négociées selon le format pour différents clients.
Prévoyez le repli si une transformation échoue. Testez nouveaux et anciens fichiers, transparences, proportions atypiques et médias protégés. Ne rendez pas un original privé accessible par une URL publique en réutilisant le circuit public. Utilisez les restrictions d’origine et URL signées documentées lorsqu’elles sont pertinentes.
L’automatisation du CMS doit générer fichiers et balisage exact. Une médiathèque peut produire plusieurs largeurs alors qu’un modèle livre toujours l’original. Inversement, un modèle peut appeler des variantes non régénérées après un réglage. Il peut en résulter un repli caché, une image cassée ou une réponse excessive.
Pour WordPress, consultez le guide Core Web Vitals avant d’ajouter une extension. Pour Shopify, suivez le guide de vitesse de boutique et inspectez les balises du thème. Préservez une stratégie cohérente pour éviter deux recompressions successives du même dérivé.
Auditez les pages dans un ordre utile
Consignez modèle, fenêtre, densité de pixels, URL et réglages à côté de la comparaison visuelle pour qu’un autre éditeur ou développeur puisse la reproduire. Incluez une longue légende et un exemple sans légende : la disposition environnante peut modifier l’espace de l’image. Attribuez les responsabilités de l’import original, des dérivés et du balisage afin de localiser les futurs problèmes. Si le design change la largeur, actualisez le relevé et contrôlez de nouveau le HTML. Conservez la paire original et dérivé approuvée comme référence pour les réglages futurs. Vous pourrez ainsi repérer les régressions sans dépendre du souvenir de l’ancien affichage.
Commencez par un modèle représentatif fréquenté et son image LCP. Corrigez URL réelle absente, chargement différé accidentel et mauvais dimensionnement avant les gains marginaux de compression. Examinez ensuite les vignettes répétées et galeries plus basses : une modification du modèle peut affecter de nombreuses pages.
Comparez original et dérivé dans le calculateur d’économie d’images avec leurs vrais poids. Le calcul décrit des octets, pas un gain de temps garanti. Réseau, cache, décodage et concurrence déterminent l’effet sur une visite.
Contrôlez écrans étroits et larges, cache vide et revisite. Faites défiler toute la page pour inspecter les images différées. Vérifiez alternatives, cadrages, transparence et stabilité. Si le fichier allégé arrive plus tard, réexaminez découverte et priorité.
Intégrez ce processus à l’optimisation de vitesse : préserver les originaux, produire les dérivés, émettre un balisage exact et vérifier les ressources après modification des modèles. Le prochain résultat utile est une chaîne vérifiée pour un modèle, dont qualité et comportement réseau sont suffisamment documentés pour être reproduits.
