Un site qui met trois secondes à s’afficher, c’est trois secondes pendant lesquelles vos visiteurs hésitent. Beaucoup ferment l’onglet avant même d’avoir lu votre première phrase. Les ventes en pâtissent, les inscriptions à la newsletter aussi, et Google le voit — il fait reculer le site dans ses résultats. Dans l’immense majorité des cas, le coupable principal n’est ni le développeur, ni un serveur sous-dimensionné. Ce sont les images.
C’est la première chose qu’on regarde quand on prend en main un site, et c’est aussi la première qu’on corrige. Pas parce que c’est facile — parce que c’est rentable. Un visuel de page d’accueil mal exporté peut peser dix fois plus que nécessaire et, à lui seul, faire perdre une seconde entière au temps d’affichage. À l’inverse, une fois bien traité, il devient invisible pour le visiteur : la page s’ouvre, et personne ne se demande pourquoi c’est rapide.
Cet article décrit la méthode qu’on applique systématiquement chez Rankea — choix du format, taille à respecter avant la mise en ligne, automatisation côté WordPress — et les trois outils qu’on garde épinglés dans le navigateur, dont une extension Chrome qu’on a fini par développer parce que rien d’existant ne couvrait notre besoin.
On commence toujours par poser la même question
« Quand vous exportez une image depuis Photoshop, Canva ou Figma, quel format obtenez-vous ? »
Si la réponse est « JPEG, parce que c’est ce que Photoshop propose par défaut », on a déjà identifié l’essentiel du problème. Un JPEG, même proprement compressé, restera plus lourd qu’un AVIF de qualité équivalente. Et le PNG qu’on retrouve souvent sur des photographies — parce qu’un contributeur a entendu un jour que « c’est mieux pour la qualité » — pèse facilement trois fois plus pour un rendu strictement identique à l’œil nu.
Notre standard en 2026 tient en une phrase : AVIF en source, WebP en fallback, servis ensemble via la balise <picture>. Le JPEG ne ressort que quand le client ne peut pas produire d’AVIF, typiquement une équipe marketing qui exporte depuis Canva ou Figma sans étape intermédiaire. Le PNG, on le garde pour les transparences strictes. Le SVG pour les logos et pictos, toujours passé par SVGO — sinon Illustrator y laisse une couche de métadonnées dont personne n’a besoin en production.
Cette décision-là plafonne tout le reste. Aucun plugin d’optimisation, aucun CDN, ne rattrapera un format mal choisi à la source.
Le vrai poids, c’est avant l’upload
L’autre erreur que l’on rencontre une fois sur deux : un export Photoshop volumineux uploadé directement dans la médiathèque, en espérant que WordPress se charge du nettoyage.
WordPress ne fait pas ça. Il génère des sous-tailles (medium, large, full), mais celles-ci héritent du même grain de compression que l’original. Et l’original, jamais affiché publiquement, occupe quand même la place sur le serveur — ou sur votre S3, Cellar… Peu importe le backend, c’est de l’espace payé pour rien.
D’où une règle simple : compresser avant l’upload, à la taille maximale réellement affichée. Pas plus. Une zone qui fait 1200 px sur desktop ne justifie jamais un upload en 3000 px « pour anticiper la Retina ». Les écrans haute densité, on les traite avec srcset, pas en gonflant le fichier source.
Nos cibles, à atteindre avant que l’image ne touche la médiathèque :
- Image hero pleine largeur (1920 px) : sous 180 Ko en AVIF, 260 Ko en WebP
- Visuel d’article ou vignette (1200 px) : sous 100 Ko en AVIF
- Miniature de carte ou de liste (600 px) : sous 40 Ko en AVIF
- Icône ou pictogramme : SVG inline, ou PNG sous 5 Ko
Au-dessus, on ne cherche pas à compenser. On retourne dans l’outil de conversion. Compresser plus loin après l’upload rend toujours un peu — jamais assez pour rattraper un format mal choisi ou une dimension trois fois trop grande.
Trois outils qu’on garde épinglés
L’efficacité du workflow tient à un détail : avoir toujours les bons outils. Pas dix onglets ouverts, pas un outil par cas d’usage. Trois — un pour chaque moment de la chaîne.
ConvertTo — pour les lots, en local
Pendant longtemps, on a cherché une extension qui ferait juste ce qu’on voulait : convertir un dossier d’images en AVIF ou WebP, en quelques clics, sans uploader vers un serveur tiers et sans créer de compte. Tout ce qu’on trouvait coinçait sur au moins un de ces trois critères : upload obligatoire, traitement unitaire, ou watermark imposé.
On a fini par publier la nôtre. ConvertTo est une extension Chrome qui traite les images directement dans le navigateur — elles ne quittent jamais la machine — et exporte en AVIF, WebP, JPEG ou PNG. Notre cas d’usage principal : préparer tous les visuels d’un article ou d’une livraison avant de toucher à la médiathèque.
Squoosh — quand chaque kilo-octet compte
Pour les images où le rendu est aussi important que le poids — l’image hero, la photo produit phare, le visuel de campagne — on bascule sur Squoosh, développé par Chrome Labs (Google).
Son slider visuel avant/après est insurpassable pour ajuster un WebP qualité 80 contre 85 quand on cherche à descendre sous un seuil précis sans casser un dégradé. Tous les encodeurs modernes y sont : MozJPEG, AVIF, WebP, JPEG… La limite est assumée — c’est unitaire. Pour vingt images, on revient à ConvertTo. Les deux outils sont complémentaires, jamais substituables.
Imagify — pour rattraper ce qu’on ne contrôle pas
Tous les contributeurs d’un site ne sont pas formés à la question des poids d’image. Un rédacteur freelance qui colle un visuel Adobe Stock, une équipe marketing pressée, un stagiaire qui upload un screenshot 4K — on ne va pas leur faire une formation AVIF.
Pour cette couche-là, Imagify reste notre choix par défaut sur le marché francophone. Compression à l’upload, conversion WebP et AVIF automatique via <picture>, traitement par lots sur l’existant. Le plan gratuit suffit pour un blog calme ; les plans payants restent abordables pour un site éditorial régulier.
On a évalué EWWW, ShortPixel, Smush et Optimole avant. Imagify est le seul qu’on a gardé en production sur l’ensemble de nos sites clients. Le ratio compression / simplicité d’administration / prix penche clairement en sa faveur.
Notre routine, étape par étape
Mis bout à bout, voilà ce qu’on fait quand on prépare un article ou qu’on reprend la médiathèque d’un site existant :
Avant l’upload
ConvertTo pour le lot d’images d’un article, Squoosh pour la hero ou tout visuel critique. Cible : les seuils de poids définis plus haut.
Upload
À la taille maximale réellement affichée, jamais plus.
Filet automatique
Imagify activé, configuré sur AVIF + WebP, pour rattraper les contributions externes.
Audit régulier
PageSpeed Insights ou WebPageTest sur les pages les plus visitées. Toute image qui dégrade le LCP remonte au rédacteur concerné.
Cette combinaison — contrôle manuel sur ce qui compte, automatisation sur le reste — couvre la majorité des projets qu’on accompagne. Au-delà d’une certaine échelle (e-commerce avec des dizaines de milliers de visuels, presse à fort trafic), un CDN d’images dédié sur un S3 devient économiquement rentable. C’est rarement le bon premier réflexe, et c’est un autre sujet.
L’image, c’est presque toujours par là qu’on commence. Pas par habitude — parce que c’est là que se cache le gain le plus rapide qu’on puisse obtenir sans toucher au code applicatif.