Guide pratique des tailles et formats de fichiers image pour le web

Chaque image mobilise des ressources réseau, de décodage, de mémoire et de rendu. Un budget utile est propre à la page : il tient compte du rôle de l’image, du public, du cache, du viewport et de la qualité requise. Les plages ci-dessous sont des points de départ à tester, pas des limites universelles de réussite.

Budgets de départ par cas d’usage

Ces plages illustrent un budget de diffusion web raisonnable. Vos résultats JPEG, WebP ou AVIF peuvent être supérieurs ou inférieurs ; adaptez-les à la source, à l’encodeur, à la taille rendue, aux performances terrain et à l’examen visuel.

Transformer les plages de départ en budget

Le rapport de poids des pages du HTTP Archive fournit des données de distribution actuelles, mais une médiane mondiale n’est pas votre public. Le seuil LCP « bon » publié par Google est de 2,5 secondes au 75e centile des visites. Utilisez vos données terrain et une cascade pour répartir le temps disponible entre réponse serveur, découverte de ressource, transfert, décodage et retard de rendu.

Partez d’un budget de transfert pour la page et accordez davantage aux images qui apportent le plus de valeur à l’utilisateur. Réexaminez les plages du tableau si la mise en page, le nombre d’images, le public ou la qualité requise changent.

Le format est une variable majeure

Une même source peut produire des tailles très différentes selon l’encodeur et la qualité visée. Ce tableau présente des comportements à comparer, pas des résultats de référence universels pour une photo de 1200 pixels :

WebP ou AVIF peuvent battre une sortie JPEG dans certaines comparaisons, mais aucun pourcentage fixe ne vaut pour toutes les sources et tous les encodeurs. Ces deux formats modernes prennent en charge la transparence. Consultez notre guide WebP et AVIF.

Vous pouvez créer des candidats avec JPG en WebP, Convertir en AVIF pour les formats d’entrée indiqués, ou la Conversion par lot pour les formats affichés par cet outil.

Les dimensions : le multiplicateur souvent négligé

Le nombre de pixels, le contenu de l’image, la profondeur de bits, les métadonnées, le format, l’encodeur et les réglages influencent la taille. Réduire les dimensions inutiles donne souvent beaucoup moins de données à représenter à l’encodeur.

Une image de 4000 × 3000 contient 12 millions de pixels ; 1200 × 900 en contient 1,08 million, soit 91% de moins. À nombre de canaux et précision identiques, cela réduit fortement les données raster non compressées fournies à l’encodeur, même si le gain final en octets dépend encore du contenu et des réglages.

Règle pratique pour le responsive : proposez des candidats proches des largeurs et densités rendues possibles. Si un emplacement mesure 720 CSS pixels, un candidat de 1440 pixels peut convenir à un écran 2×, mais zoom, recadrage, changements de mise en page et densités supérieures peuvent modifier ce choix. Laissez srcset et sizes décrire les options.

Utilisez l’outil Redimensionner une image de Vizua pour créer un candidat aux dimensions requises par votre mise en page. Testez ensuite le compresseur JPEG ou PNG approprié ; une source déjà optimisée ne sera pas forcément plus petite.

Qualité de compression : trouver le bon équilibre

Une fois votre image aux bonnes dimensions et au bon format, la qualité de compression est le dernier réglage à ajuster. Voici un exemple concret montrant comment ces trois leviers s'articulent :

Flux illustratif : partez d’un master de 4000 × 3000 et conservez-le hors de l’ensemble de diffusion.

1. Redimensionnez vers un candidat tel que 1200 × 900 lorsque cela correspond à l’emplacement et à la densité visés
2. Exportez un candidat WebP à une qualité de départ choisie et inspectez le fichier réel
3. Exportez un candidat AVIF si votre stack le prend en charge, puis comparez taille, aspect et coût d’encodage

Choisissez le plus petit candidat qui répond au cas d’usage. Le gain final et la différence visible viennent de vos véritables sources et sorties, pas uniquement des dimensions de l’exemple.

Pour des recommandations de qualité détaillées par format, consultez notre guide : Comment compresser des images sans perdre en qualité.

Cas particuliers

Pages produits e-commerce

Les photos de produits doivent rester utiles avec le zoom pris en charge par la boutique. Générez des candidats responsives depuis un master protégé, testez les détails fins et fixez des budgets distincts pour la grille, la vue principale et le zoom. Les exigences d’envoi des marketplaces peuvent différer de la diffusion de la boutique.

Portfolios photo

Les portfolios peuvent servir des aperçus responsives et proposer une vue haute résolution intentionnelle lorsque cela convient. Déduisez les dimensions et budgets d’octets de la mise en page et des écrans attendus, puis examinez textures, dégradés et profils colorimétriques.

Partage sur les réseaux sociaux (Open Graph)

Les recommandations et formats acceptés pour les images Open Graph varient selon la plateforme et peuvent changer. Un JPEG ou PNG de 1200 × 630 constitue un point de départ interplateforme courant, mais vérifiez les consignes actuelles et l’aperçu de la destination. Les robots récupèrent ces fichiers indépendamment du chargement différé de la page.

Budget image total par page

Construisez un budget de page à partir de votre objectif de performance. Une première répartition possible à tester est :

• 1 image hero : ~150 Ko
• 3 à 4 images de contenu : ~100 Ko chacune, soit 300 à 400 Ko au total
• Miniatures, avatars, icônes : ~50 Ko combinés

Cet exemple ne garantit pas la vitesse. Les galeries et grilles de produits peuvent différer les images adaptées hors écran, mais les ressources chargées paresseusement consomment tout de même des données lorsqu’elles sont demandées et peuvent affecter le défilement. Mesurez les performances initiales et d’interaction sur des appareils et réseaux représentatifs.

Questions fréquentes