Optimiser les images d’une landing page : formats, poids et chargement

Sur la plupart des landing pages, les images représentent la majeure partie du poids téléchargé : davantage que le HTML, le CSS et le JavaScript réunis. C’est aussi le poste sur lequel on gagne le plus vite — une image mal exportée se corrige en quelques minutes. Nous avons traité ailleurs la vitesse de chargement dans son ensemble ; cet article ne parle que d’images, mais en détail.

Pourquoi le poids des images décide de la vitesse ressentie

Une landing page contient rarement plus de quelques centaines de lignes de texte, mais souvent une photo hero pleine largeur, trois captures produit, une grille de logos et une série de portraits. Et la plus grande de ces images est, presque toujours, l’élément qui déclenche la mesure du LCP (Largest Contentful Paint). Optimiser les images, ce n’est donc pas gratter des kilo-octets par principe : c’est agir sur la métrique que Google utilise pour juger la page, et sur le moment où le visiteur voit enfin votre promesse.

Le budget d’attente est court. Une étude de Fiona Nah publiée en 2004 dans Behaviour & Information Technology a mesuré le « temps d’attente tolérable » des internautes pour récupérer une information : il se situe autour de 2 secondes, et un retour visuel pendant le chargement allonge sensiblement cette tolérance (étude sur Google Scholar). Deux secondes, c’est le temps qu’une seule photo exportée telle quelle depuis un appareil met à arriver sur une connexion mobile moyenne.

Choisir le bon format : le tableau de décision

La première question n’est pas « comment compresser » mais « quel format ». Un mauvais format condamne l’image à peser lourd quel que soit le réglage ensuite : un PNG utilisé pour une photo part avec un handicap qu’aucun outil ne rattrapera.

À qualité perçue équivalente, WebP et AVIF produisent des fichiers plus légers que le JPEG et le PNG dont ils prennent la succession — c’est la raison même de leur existence, et le gain réel dépend de chaque image. La règle pratique tient en trois lignes : le vectoriel part en SVG (un logo en PNG est presque toujours une erreur), le photographique part en WebP, et on passe en AVIF les rares images qui restent lourdes, servies via une balise <picture> avec repli JPEG. Dernier réflexe : pour montrer une interface en mouvement, une vidéo MP4 muette en boucle pèse bien moins lourd que le GIF équivalent.

Dimensionner à la taille réellement affichée

C’est le gaspillage le plus courant et le plus facile à corriger : une photo de 4 000 pixels de large servie dans un bloc qui en fait 600. Le navigateur télécharge tout le fichier, puis le réduit — le visiteur paie le poids complet pour un détail qu’il ne verra jamais. Redimensionnez chaque image à la largeur maximale à laquelle elle est réellement affichée, écrans à haute densité compris (multipliez par deux, rarement plus). Mais un même visuel n’a pas la même taille sur mobile et sur grand écran : c’est le rôle de srcset et sizes.

• srcset liste les variantes avec leur largeur réelle (hero-640.webp 640w, hero-1280.webp 1280w, hero-1920.webp 1920w).
• sizes décrit la largeur d’affichage prévue selon le contexte ((max-width: 768px) 100vw, 640px), pour que le navigateur décide avant d’avoir lu le CSS.
• Trois à quatre variantes suffisent ; en générer dix complique la maintenance sans bénéfice mesurable.
• Un bandeau décoratif gagne souvent à être recadré pour le mobile plutôt que réduit : un cadrage vertical pèse moins lourd et raconte mieux.

Le point est décisif parce que l’essentiel du trafic publicitaire arrive sur mobile, comme nous le détaillons dans notre article sur la conception mobile-first : servir à un téléphone en 4G une image pensée pour un écran 27 pouces, c’est faire payer au visiteur le plus contraint la version la plus lourde.

Compresser : avec ou sans perte

La compression sans perte réduit le poids sans modifier un pixel : elle convient aux logos, pictogrammes et captures d’écran, où le moindre flou sur un texte se voit. La compression avec perte supprime de l’information que l’œil ne perçoit pas ou peu ; c’est elle qui produit les gains sur les photographies. Une qualité entre 75 et 85 est le point de départ habituel en WebP ou JPEG, mais la bonne méthode n’est pas de retenir un chiffre : comparez l’original et la version compressée à la taille d’affichage, et descendez jusqu’au point juste avant que la différence devienne visible.

• Supprimez les métadonnées (EXIF, données GPS, profil colorimétrique) : elles n’apportent rien sur le web et alourdissent chaque fichier sorti d’un appareil photo.
• Nettoyez les SVG exportés depuis un outil de design : calques masqués et métadonnées d’éditeur multiplient souvent leur taille.
• Automatisez plutôt que de compresser à la main : un script au build garantit que personne n’oubliera l’étape.
• Ne recompressez jamais un fichier déjà compressé : repartez de l’original, sous peine d’empiler les artefacts.

Les trois attributs qui décident du premier écran

Une fois le format et le poids réglés, il reste à dire au navigateur quand et dans quel ordre télécharger. C’est là que se jouent la plupart des points perdus sur PageSpeed Insights.

loading="lazy" : indispensable en bas de page, à proscrire sur le hero

loading="lazy" demande au navigateur de ne télécharger l’image que lorsqu’elle approche de la zone visible : un gain net pour les témoignages, captures secondaires et logos de pied de page. Appliqué au hero, il produit l’effet exactement inverse — le navigateur attend d’avoir calculé la mise en page pour décider que l’image est visible, puis seulement lance le téléchargement. Vous ajoutez un aller-retour sur l’élément qui détermine votre LCP. La règle est sans exception : jamais de lazy loading sur ce qui est visible sans scroller. Les thèmes qui l’activent « sur toutes les images » d’un seul réglage sont une cause fréquente de LCP dégradé.

width et height : la parade au décalage de mise en page

Une image sans dimensions déclarées occupe zéro pixel de hauteur tant qu’elle n’est pas chargée, puis pousse brutalement le contenu qui la suit vers le bas. C’est la première cause de CLS (Cumulative Layout Shift) sur une landing page, et la plus agaçante : le bouton qu’on s’apprêtait à toucher se déplace au moment du clic. Renseignez systématiquement width et height avec les dimensions réelles du fichier — même si le CSS redimensionne ensuite, le navigateur en déduit le rapport d’aspect et réserve la bonne place dès le premier rendu.

fetchpriority="high" : passer devant tout le reste

Par défaut, le navigateur découvre les images au fil du HTML et les traite avec une priorité modérée, derrière le CSS et certains scripts. fetchpriority="high" sur l’image du hero indique que ce fichier-là passe en tête de file. C’est un attribut à utiliser une seule fois par page : si tout est prioritaire, plus rien ne l’est. Combiné à l’absence de lazy loading et à un format moderne, c’est souvent ce qui fait basculer un LCP du bon côté des 2,5 secondes.

Les cas particuliers qui échappent aux règles

Les images d’arrière-plan CSS sont découvertes tardivement : le navigateur doit analyser la feuille de style avant de comprendre qu’il lui faut ce fichier. Sans importance pour un bandeau décoratif en bas de page ; handicap structurel pour le hero, car un background-image n’accepte ni srcset, ni fetchpriority, ni width. Repassez en balise <img> positionnée derrière le contenu, ou préchargez le fichier avec un <link rel="preload" as="image">.

Les captures d’écran d’interface contiennent du texte fin, des bordures nettes et des aplats : exactement ce que la compression avec perte dégrade en premier. Capturez à la résolution finale plutôt que de réduire une capture Retina, recadrez sur ce qui compte et vérifiez la lisibilité sur téléphone. Notre article sur l’image hero détaille quand une capture est le bon choix face à une photo.

Les photos de portrait, enfin, sont les plus nombreuses et les plus mal traitées : affichées dans un cercle de 48 à 96 pixels, mais chargées en fichiers de 1 500 pixels sortis d’une séance photo. Dix avatars ainsi traités peuvent peser plus lourd que le hero. Redimensionnez, convertissez en WebP, et différez le chargement de ceux des témoignages. Pensez aussi à l’image de partage, qui obéit à d’autres contraintes — voir notre article sur l’image Open Graph.

Diagnostiquer et prioriser : la méthode

L’ordre compte autant que les techniques : traiter d’abord ce qui pèse sur le premier écran donne des résultats visibles là où les autres corrections ne se voient nulle part.

1. Ouvrez l’onglet Réseau des DevTools, filtrez sur « Img », rechargez en vidant le cache et triez par taille décroissante : en trente secondes, vous avez vos coupables classés par gravité.
2. Comparez la taille du fichier à sa taille d’affichage : l’inspecteur indique au survol les dimensions intrinsèques et rendues. Un écart de facteur trois signale un redimensionnement à faire.
3. Lancez PageSpeed Insights en version mobile et lisez la section « Opportunités » : elle nomme les images à convertir, redimensionner ou différer, et identifie l’élément LCP sur une capture.
4. Traitez d’abord l’élément LCP : bon format, bonne taille, pas de lazy loading, fetchpriority="high". Une seule image, et le meilleur rapport effort/résultat de la liste.
5. Passez aux dix images les plus lourdes du reste de la page, en activant le lazy loading sur tout ce qui est sous la ligne de flottaison.
6. Remesurez en conditions réelles, téléphone en 4G plutôt qu’en wifi de bureau, en vérifiant que le score CLS n’a pas bougé.

Ce travail a une contrepartie commerciale. Une étude de Wojciech Stadnik et Ziemowit Nowak, publiée en 2018 dans les actes de la conférence ISAT, a suivi le comportement réel des visiteurs d’une boutique en ligne et conclu que le temps de chargement moyen des pages a un effet direct sur le taux de conversion et la satisfaction mesurée des clients (étude sur Google Scholar). Les kilo-octets économisés ne restent pas dans le rapport technique : ils ressortent dans le nombre de formulaires envoyés.

Reste que tout ceci peut être automatisé. Le composant next/image de Next.js génère les variantes de tailles, sert du WebP ou de l’AVIF selon ce que le navigateur accepte, impose width et height (donc protège du CLS par construction) et active le lazy loading par défaut — avec la propriété priority pour l’en dispenser sur le hero. C’est l’une des raisons de l’écart constaté dans notre comparatif Next.js contre WordPress, et la configuration est détaillée dans notre article sur le déploiement d’une landing page Next.js sur Vercel.

C’est aussi le parti pris des templates LanderKit : images déjà dimensionnées, converties et hiérarchisées, hero exclu du chargement différé, dimensions déclarées partout. Sur une page comme notre template e-commerce produit, où le visuel est l’argument de vente principal, cela évite le compromis entre une page riche visuellement et une page rapide. L’objectif n’est pas la page la plus légère possible, mais celle qui montre le plus vite ce qui la fait vendre.