On reçoit un site e-commerce avec des fiches produit qui mettent plus de quatre secondes à s’afficher. On ouvre l’inspecteur réseau : une seule photo de sneaker pèse autant que le reste de la page. Optimiser les images pour le web reste le levier le plus rentable pour accélérer le chargement d’un site, à condition de ne pas se limiter à la compression.
L’erreur du lazy loading appliqué partout, y compris sur l’image LCP
Beaucoup de CMS et de plugins appliquent loading= »lazy » de manière globale à toutes les images. Sur le papier, c’est logique : on diffère le téléchargement de ce qui n’est pas visible. En pratique, c’est une catastrophe quand l’image principale de la page, celle qui détermine le Largest Contentful Paint (LCP), se retrouve elle aussi en lazy loading.
A lire également : Qu'est-ce qu'un site Web blockchain ?
Google le rappelle sans détour : lazy-loader l’image LCP dégrade systématiquement cette métrique, et donc les Core Web Vitals. On l’a constaté sur plusieurs sites où le simple retrait de l’attribut loading="lazy" sur le visuel au-dessus de la ligne de flottaison a suffi à faire passer le LCP sous le seuil des 2,5 secondes.
La règle opérationnelle est simple. On identifie l’image la plus grande dans la zone visible au premier chargement, on lui retire le lazy loading, et on ajoute l’attribut fetchpriority="high". Cette combinaison indique au navigateur de télécharger ce visuel en priorité.
A voir aussi : Comprendre les performances d'un site grâce aux outils de mesure
Peu de sites exploitent fetchpriority aujourd’hui. C’est un quick win encore sous-utilisé, alors qu’il ne demande qu’une ligne de code.
Format d’image : WebP, AVIF et le piège du PNG par défaut
On voit encore des sites servir des PNG pour des photographies de produits ou des visuels de blog. Le PNG conserve une qualité parfaite, mais son poids est disproportionné pour une photo. Le format JPEG reste plus adapté aux photographies, et les formats modernes vont plus loin.
WebP et AVIF réduisent le poids de manière significative à qualité visuelle équivalente par rapport au JPEG classique. AVIF pousse la compression encore plus loin que WebP, mais son encodage est plus lent, ce qui peut poser problème si on génère les images à la volée côté serveur. Les retours varient sur ce point selon l’infrastructure.
Choisir le bon format selon le contenu visuel
- Photographies (produits, portraits, paysages) : WebP ou AVIF en priorité, JPEG en fallback. Le PNG est à éviter sauf besoin de transparence.
- Illustrations, logos, icônes avec aplats de couleur : SVG quand c’est vectoriel, PNG uniquement si la transparence est nécessaire sur un visuel bitmap.
- Visuels décoratifs ou d’ambiance : WebP avec une compression agressive, la perte de détail passe inaperçue sur ce type de contenu.
La balise <picture> avec des sources multiples permet de servir AVIF aux navigateurs compatibles, WebP aux autres, et JPEG en dernier recours. On ne choisit pas un format unique pour tout le site : chaque type de visuel appelle un format différent.
Redimensionner avant de compresser : l’ordre compte
Compresser une image de 4 000 pixels de large pour l’afficher dans un conteneur de 800 pixels, c’est gaspiller de la bande passante. Le navigateur télécharge la totalité du fichier avant de le réduire à l’écran. On perd des secondes de chargement sur mobile, où la connexion est souvent plus lente.
Servir la bonne dimension via l’attribut srcset change la donne. On génère plusieurs tailles du même visuel (400, 800, 1 200 pixels par exemple) et on laisse le navigateur choisir celle qui correspond à la largeur réelle du viewport. Sur un téléphone, il récupère la version légère. Sur un écran large, la version haute définition.
Ce travail de redimensionnement se fait avant la compression. Réduire d’abord la taille en pixels, puis compresser le fichier résultant. Inverser l’ordre produit un fichier plus lourd pour un résultat visuel identique.
Les outils pour automatiser le pipeline
Sur WordPress, des extensions comme ShortPixel ou Imagify gèrent la conversion en WebP et le redimensionnement automatique à l’upload. Pour les sites sur mesure, un script en ligne de commande avec Sharp (Node.js) ou libvips traite des centaines d’images en quelques secondes.
L’automatisation évite le scénario classique : un contributeur charge une photo brute de plusieurs mégaoctets, personne ne la retouche, et elle reste en ligne pendant des mois.
Dimensions déclarées et CLS : un problème d’image invisible
Le Cumulative Layout Shift (CLS) mesure les décalages visuels qui perturbent la lecture. Quand le navigateur ne connaît pas les dimensions d’une image avant de la charger, il réserve zéro pixel, puis pousse le texte vers le bas une fois l’image affichée. Ce saut agace les visiteurs et dégrade la note Core Web Vitals.
Déclarer la largeur et la hauteur dans le HTML (attributs width et height) ou via un ratio CSS (aspect-ratio) permet au navigateur de réserver l’espace avant le téléchargement. C’est une ligne de code, aucun impact sur le poids de la page, et un gain direct sur le CLS.
On le vérifie facilement dans PageSpeed Insights ou Lighthouse : si le rapport signale des éléments sans dimensions explicites, ce sont presque toujours des images.
Mesurer l’impact réel sur la performance du site
Optimiser sans mesurer, c’est naviguer à l’aveugle. On compare le poids total de la page et les métriques Core Web Vitals (LCP, CLS) avant et après intervention. Les outils de Google (PageSpeed Insights, Search Console) fournissent des données de terrain, pas seulement des simulations en laboratoire.
- Vérifier que l’image LCP n’est pas en lazy loading et qu’elle porte fetchpriority= »high ».
- Contrôler que chaque image est servie dans un format moderne (WebP ou AVIF) et à la bonne dimension.
- S’assurer que toutes les images déclarent leurs dimensions pour éviter les décalages de mise en page.
L’optimisation des images seule ne règle pas tout. Le JavaScript bloquant, les polices non optimisées et le temps serveur pèsent aussi. L’image reste le premier levier parce que c’est souvent le poste le plus lourd sur la page, mais elle s’inscrit dans un travail de performance global. Commencer par les images permet d’obtenir des résultats visibles rapidement, puis d’attaquer les autres fronts avec des métriques de référence fiables.
