Pour alléger une image sur mobile, commencez par vérifier le fichier que le navigateur charge réellement. Réduire sa largeur avec du CSS ne réduit pas le poids de ce fichier. Préparez ensuite des variantes adaptées à l’espace d’affichage, vérifiez la source sélectionnée et comparez la page dans les mêmes conditions. Une image plus légère est un résultat mesurable; une page plus rapide doit encore être testée.
Cette méthode convient à une PME dont la photo d’accueil, de service ou de produit semble arriver tard sur téléphone. Elle permet aussi de remettre un problème précis à la personne qui entretient le site, avec l’URL du fichier et des observations vérifiables.
Reconnaître le problème sans accuser la mauvaise image
Une photo peut rester vide quelques instants, apparaître après le titre ou déplacer le bouton de demande de soumission. Ce sont des symptômes, pas une cause confirmée. Un serveur lent, une ressource découverte tardivement ou du travail JavaScript peuvent aussi retarder l’affichage. Le guide web.dev sur le LCP distingue justement les différentes parties de ce délai.
Relevez la page, la taille de fenêtre, le navigateur et les conditions réseau. Dans les outils de développement, consultez la requête de l’image : URL, statut HTTP, taille et chronologie. Une erreur HTTP ou une attente serveur appelle une vérification des journaux correspondants; une compression ne corrige pas toutes les causes. Ne concluez pas à une panne à partir d’une seule capture.
Préparer une correction réversible
- Conservez le fichier original, ses droits d’utilisation et une copie de la page avant modification.
- Travaillez sur une prévisualisation ou un environnement de test, avec accès au gabarit ou à la personne qui le maintient.
- Utilisez un outil d’export permettant de choisir les dimensions et la qualité, puis de comparer visuellement le résultat.
- Notez la largeur d’affichage prévue et le cadrage à conserver : produit, visage, détail technique ou texte essentiel.
Les outils de développement du navigateur et un éditeur d’images gratuit peuvent suffire. L’intégration au CMS, les essais et une éventuelle licence photo demandent toutefois du temps ou un budget. Aucun abonnement d’optimisation n’est nécessaire pour commencer ce diagnostic. Le bon niveau de compression dépend de la photo et de son usage, pas d’un nombre universel.
Vérifier ce qui est réellement téléchargé
- Ouvrez l’onglet Réseau, gardez les outils ouverts et rechargez la page. Filtrez les images pour retrouver la photo concernée.
- Pour un essai sans réutilisation du cache du navigateur, cochez
Disable cachependant que les outils sont ouverts. Rechargez de nouveau après avoir coché cette option. Consignez ce réglage et le profil réseau; le cache d’un CDN reste une autre variable. - Relevez l’adresse et la taille de la réponse. Distinguez le poids du fichier, la taille de la ressource et les octets transférés observés : une réponse venant du cache peut rendre la comparaison trompeuse.
- Mesurez la place occupée par l’image dans la page. Une photo affichée sur 360 pixels CSS n’a pas forcément besoin d’un fichier de 6 000 pixels de large.
La documentation Réseau de Chrome décrit ces contrôles. Si plusieurs variantes existent, la propriété currentSrc indique l’URL choisie. Elle ne prouve pas que le téléchargement a réussi : vérifiez aussi le rendu et le décodage de l’image. Voir MDN sur currentSrc.
Exporter des variantes et les relier au bon affichage
Recadrez d’abord une copie, puis exportez des largeurs utiles. Dans l’exemple ci-dessous, les fichiers font exactement 640 × 360 et 1 280 × 720 pixels. La photo occupe la largeur de la fenêtre moins 32 pixels, jusqu’à un maximum de 640 pixels CSS. Les chemins sont illustratifs : remplacez-les par ceux de vos vrais fichiers.
<img class="photo"
src="/img/photo-1280.webp"
srcset="
/img/photo-640.webp 640w,
/img/photo-1280.webp 1280w"
sizes="
(max-width: 672px)
calc(100vw - 32px),
640px"
width="1280" height="720"
alt="Téléphone et portable">img.photo {
width: calc(100vw - 32px);
max-width: 640px;
height: auto;
}Le premier bloc va dans le gabarit HTML; le second dans sa feuille de styles. L’attribut srcset décrit les fichiers disponibles et leurs largeurs réelles. sizes décrit la place prévue dans cette mise en page. Le navigateur choisit une source selon le contexte, notamment la densité de l’écran; « téléphone » ne signifie donc pas systématiquement « fichier de 640 pixels ». La méthode des images adaptatives de MDN explique ce fonctionnement.
Les attributs width et height donnent le ratio; le CSS conserve une hauteur proportionnelle. Cela aide à réserver l’espace avant l’affichage. Adaptez ensemble les dimensions, le ratio et sizes si votre gabarit change. Voir la référence MDN de l’élément img. Dans WordPress, vérifiez le HTML finalement rendu par votre thème ou votre application : importer des variantes dans la médiathèque ne garantit pas que le site les utilise.
Éviter de retarder la grande image d’accueil
Si la photo est l’élément LCP — le plus grand contenu visible retenu par cette mesure — ne lui appliquez pas loading="lazy". L’attribut fetchpriority="high" peut indiquer une priorité élevée pour une image importante identifiée; l’ajouter partout retire son intérêt. Le guide LCP de web.dev recommande aussi de rendre cette ressource découvrable tôt. Le petit exemple ci-dessus n’impose aucune priorité élevée : identifiez d’abord le rôle de l’image dans votre page.
Exemple illustratif : une photo de café mesurée localement
Imaginons un café qui présente son espace sur sa page d’accueil. Ce scénario n’est pas un mandat client. Pour illustrer la méthode, nous avons utilisé une vraie photographie sous licence et exécuté un essai local le 31 octobre 2026. Le JPEG source a été recadré en 16:9 vers le bas, redimensionné et exporté en WebP, qualité 82. L’original était affiché avec le même cadrage visible. Aucune génération ni retouche par IA n’a été utilisée.
| Fichier | Dimensions | Poids mesuré |
|---|---|---|
| JPEG original | 6 720 × 4 480 | 4 863 903 octets |
| WebP compact | 640 × 360 | 40 126 octets |
| WebP large | 1 280 × 720 | 100 536 octets |
Dans Chrome, une fenêtre de 390 pixels CSS avec une densité simulée de 1 a sélectionné le WebP de 640 pixels, affiché sur 358 pixels de large. Dans la fenêtre de bureau de 1 272 pixels, avec une densité de 2, le navigateur a sélectionné le WebP de 1 280 pixels pour un affichage de 640 pixels. Le décodage a réussi dans les deux cas; le cadrage a été inspecté.
Ces chiffres décrivent les fichiers et les sources sélectionnées dans ce test. Aucun volume de transfert réseau, temps de chargement ou LCP n’a été mesuré. Le cache du navigateur n’a pas été contrôlé, le réseau n’a pas été ralenti et aucun téléphone physique n’a été testé. La réduction combine recadrage, dimensions et compression : elle ne peut pas être attribuée au seul format WebP.
Vérifier la page et décider si la correction suffit
Refaites l’essai avant/après avec la même fenêtre, la même densité, le même profil réseau et la même politique de cache. Répétez les mesures pour éviter de choisir un passage exceptionnel. Si vous comparez le LCP, relevez aussi quel élément le déclenche : une autre ressource peut devenir le facteur limitant. Les données des visiteurs et les tests de laboratoire répondent à des questions différentes; un essai local ne remplace pas le suivi en conditions réelles.
Examinez la netteté, les détails utiles, le cadrage et les déplacements de contenu sur plusieurs largeurs. Testez aussi le bouton de contact, les liens et le parcours de consentement après intégration, sans modifier les réglages de suivi pour embellir un résultat. Une recette utilisateur avec des critères précis aide à formaliser cette vérification.
Si le navigateur continue à charger l’ancien fichier, contrôlez d’abord son URL et le HTML rendu, puis les caches concernés. Si le fichier est plus léger mais que l’affichage reste tardif, examinez la chronologie plutôt que de compresser encore. Revenez à la version précédente si le détail nécessaire au client devient illisible.
Checklist avant mise en ligne
- Original conservé et droits vérifiés.
- Dimensions réelles, ratio et cadrage cohérents.
- Source sélectionnée et chargement réussi vérifiés sur petit et grand écran.
- Poids des fichiers consigné, sans promesse de vitesse non mesurée.
- Grande image d’accueil sans chargement différé inadapté.
- Netteté, liens, contact et consentement vérifiés; retour arrière possible.
Pour faire vérifier vos images dans le contexte complet du site, notre offre de conception et amélioration de sites web dans le Grand Montréal permet de relier l’optimisation aux pages et aux demandes de vos clients.