Ce que fait un CDN d'images
Un CDN garde des copies de vos fichiers sur des serveurs proches de vos visiteurs et les leur envoie depuis là. Pour la plupart des fichiers, c'est tout : les octets qui sortent de la périphérie sont ceux que votre origine a servis. Un CDN d'images ajoute une étape. Entre son cache et le visiteur, il peut modifier l'image elle-même, pour quatre raisons.
Le format. Sur les photos, le WebP et l'AVIF sont généralement bien plus légers que le JPEG que vous avez envoyé : dans notre mesure, une photo d'actualité de 262 025 octets est passée à 113 860 octets en WebP et à 86 936 en AVIF. Le CDN d'images convertit chaque image dans un format que le navigateur du visiteur accepte : un navigateur qui gère l'AVIF reçoit de l'AVIF, et un navigateur plus ancien reçoit toujours une image qu'il sait afficher.
La taille. Un téléphone qui affiche une photo sur 400 pixels de large n'a pas besoin du fichier de 2 400 pixels que vous avez téléversé. Avec une largeur ou une hauteur dans l'URL, le CDN d'images réduit l'image à ce que la page affiche réellement.
La compression. Même sans changer de format, réencoder à une qualité raisonnable et retirer les données que l'écran n'utilise jamais allège la plupart des fichiers : la même photo d'actualité, réencodée en JPEG, est passée de 262 025 à 186 137 octets.
Le cache. Chaque résultat est stocké en périphérie. La conversion a lieu une fois par variante, et chaque visiteur suivant reçoit la copie stockée à la vitesse normale du CDN.
Vos originaux restent où ils sont : vous téléversez un seul fichier de bonne qualité, et chaque variante en est tirée sur le chemin de diffusion. Rien n'est à réexporter quand un nouveau format arrive ou qu'une mise en page change de taille.
Une URL, plusieurs formats : Accept et Vary
Chaque requête d'image qu'envoie un navigateur porte un en-tête Accept qui liste les formats qu'il sait afficher. Chrome envoie image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 ; un navigateur sans AVIF omet image/avif. Le CDN d'images lit cette liste à chaque requête et répond à la même URL en AVIF, en WebP ou dans le format d'origine. Le nom du fichier ne change pas, si bien que photo.jpg peut arriver en AVIF : c'est l'en-tête Content-Type qui dit ce qui a réellement été envoyé.
Comme une URL a désormais plusieurs bonnes réponses, la réponse doit le dire avec Vary: Accept. Cet en-tête indique à chaque cache situé entre la périphérie et le visiteur, du proxy d'une entreprise au cache du navigateur lui-même, que la réponse dépend d'Accept. Sans lui, un cache partagé peut stocker l'AVIF reçu par un visiteur et le remettre au suivant, dont le navigateur ne sait pas le décoder.
Le cache du CDN suit la même règle, et un détail compte ici. Les chaînes Accept diffèrent d'un navigateur à l'autre, et même d'une version à l'autre, si bien qu'un cache qui prend l'en-tête brut pour clé garde une copie presque identique pour chaque variante d'écriture. Un CDN d'images bien conçu réduit l'en-tête à la décision qu'il porte (AVIF, WebP ou aucun des deux) et garde une copie pour chacune.
L'autre voie consiste à décider dans le HTML : un élément <picture> liste une <source> AVIF et une WebP, et le navigateur prend le premier type qu'il prend en charge. Aucune négociation n'est nécessaire, mais vous produisez, stockez et référencez vous-même chaque variante. Avec un CDN d'images, le balisage reste un simple <img> ; <picture> reste l'outil de la direction artistique, quand un téléphone doit recevoir un autre cadrage et non une copie plus petite de la même image.
Redimensionner par l'URL
La négociation du format ne demande aucun changement dans vos pages ; le redimensionnement, si, car seule la page sait à quelle largeur une image sera affichée. Les CDN d'images prennent la taille dans l'URL, le plus souvent sous forme de paramètres : photo.jpg?w=640 demande une copie de 640 pixels de large. Un service bien pensé conserve les proportions quand vous donnez une seule dimension, fait tenir l'image dans le cadre quand vous donnez les deux, et n'agrandit jamais une image au-delà de sa taille d'origine.
Associé à srcset et sizes, un seul fichier source sert tous les écrans. Vous listez quelques largeurs de la même URL et indiquez à quelle largeur l'image s'affiche, et le navigateur télécharge la plus petite copie qui reste nette à la densité d'écran du visiteur. Le CDN d'images produit chaque largeur de la liste la première fois qu'on la demande, puis la sert depuis son cache.
Gardez la liste courte et fixe. Chaque largeur distincte est une conversion de plus et un objet de cache de plus : cinq largeurs utilisées sur tout le site se mettent bien mieux en cache que les valeurs que chaque gabarit calcule de son côté. Certains services acceptent d'autres paramètres, comme le recadrage, la qualité ou le point focal, et chacun multiplie les variantes de la même façon.
Une image source, cinq largeurs : le navigateur choisit celle qu'il lui faut
<img
src="https://example.com/media/photo.jpg?w=960"
srcset="https://example.com/media/photo.jpg?w=320 320w,
https://example.com/media/photo.jpg?w=640 640w,
https://example.com/media/photo.jpg?w=960 960w,
https://example.com/media/photo.jpg?w=1280 1280w,
https://example.com/media/photo.jpg?w=1920 1920w"
sizes="(max-width: 720px) 100vw, 720px"
width="1920" height="1080" alt="">Chaque variante est un objet de cache à part
Un CDN d'images transforme un fichier en famille. Une photo demandée en trois formats et cinq largeurs, ce sont quinze objets dans le cache, chacun sous sa propre clé. Trois conséquences en découlent.
La clé de cache doit contenir la taille. Si une règle ignore la chaîne de requête pour augmenter le taux de succès, ?w=320 et ?w=1920 partagent la même clé, et la taille demandée en premier part chez tout le monde. Gardez les paramètres de taille dans la clé, même si vous en retirez d'autres.
La première requête paie la conversion. Une variante que personne n'a encore demandée est produite à la volée : la périphérie récupère l'original, l'encode puis met le résultat en cache. Ce visiteur-là attend un peu plus ; tous les suivants reçoivent la copie en cache. Pour les pages qui doivent être rapides dès le premier affichage, quelques requêtes après un déploiement ou une purge préchauffent le cache.
La purge et l'expiration concernent toute la famille. Quand un original change sous le même nom, chaque format et chaque taille qui en sont issus doivent disparaître. Une purge par préfixe de chemin les atteint tous ; la purge d'une seule URL exacte peut laisser derrière elle les copies redimensionnées. Activer la conversion est le cas simple : quand le format fait partie de la clé de cache, chaque copie convertie est un nouvel objet et part dès la première requête. Seules les copies déjà présentes dans les navigateurs des visiteurs restent telles quelles jusqu'à leur expiration chez eux.
Qualité et taille : quand une conversion perd
Tout format avec perte échange des octets contre du détail au moyen d'un réglage de qualité, et les CDN d'images choisissent une valeur par défaut qui semble intacte à la taille d'affichage normale. Plus bas, les photos deviennent floues et pleines de blocs ; plus haut, le gain se réduit. Le texte, les contours nets et les aplats de couleur montrent les dégâts en premier, c'est pourquoi les captures d'écran et les logos demandent un traitement plus doux que les photos.
Le format compte autant que le réglage, et le gagnant change selon l'image. Le 5 octobre 2026, nous avons fait passer trois images par l'optimiseur d'images de CDN.com.tr, avec ses réglages de production, et compté les octets.
Photo d'actualité, JPEG. Original 262 025 octets ; WebP 113 860 ; AVIF 86 936. Le cas d'école : l'AVIF transporte la même image en à peu près un tiers des octets de l'original.
Capture d'écran du panneau, PNG. Original 105 078 octets ; PNG optimisé 40 379 ; WebP 41 218 ; AVIF 27 942. Un PNG à palette excelle sur les aplats et le texte, et ici le WebP est sorti plus lourd que lui ; l'AVIF l'a tout de même emporté.
Favicon, PNG, 16×16. Original 701 octets ; PNG optimisé 483 ; WebP 314 ; AVIF 682. À cette taille, le surcoût fixe du conteneur AVIF l'emporte sur sa meilleure compression, et le WebP gagne nettement.
Aucun format ne gagne partout, et une conversion peut produire un fichier plus lourd que la meilleure version de l'original. Un bon CDN d'images encode, compare les octets et envoie le fichier le plus léger ; un service qui convertit à l'aveugle alourdit une partie de vos images et les présente quand même comme optimisées. Notre guide AVIF ou WebP donne toutes les mesures et leurs raisons.
CDN d'images ou optimisation au build ?
Vous pouvez obtenir les mêmes formats sans CDN d'images. Une étape de build, un hook de téléversement ou une extension peut convertir chaque image une fois, écrire les variantes à côté des originaux et laisser un CDN classique les diffuser avec un balisage <picture>. La meilleure voie dépend de l'origine de vos images.
L'optimisation au build l'emporte sur un site dont les images vivent dans le dépôt : un site vitrine, une documentation, une application statique. L'ensemble est connu à l'avance, chaque fichier peut être réglé à la main, rien n'est traité pendant qu'un visiteur attend, et ce qui part est exactement ce que vous avez testé.
Un CDN d'images l'emporte quand les images arrivent plus vite que personne ne peut les traiter : photos de produits téléversées depuis l'administration d'une boutique, archives d'un site d'information, médiathèque WordPress riche de plusieurs années d'envois, images publiées par vos utilisateurs. Il l'emporte aussi quand le nombre de tailles grandit à chaque nouvelle mise en page, quand un thème ou un CMS hébergé écrit le balisage à votre place, et quand vous préférez ne pas faire tourner un convertisseur sur votre propre serveur.
Les deux se combinent bien : visuels d'en-tête réglés à la main depuis le build, et tout ce qui passe par le CMS depuis le CDN d'images. Les logos et icônes dessinés plutôt que photographiés restent de toute façon mieux en SVG : il n'y a rien à convertir, et ils restent nets à toutes les tailles.
Les pièges à vérifier avant de l'activer
La plupart des ennuis avec les CDN d'images viennent de quelques endroits, et chacun peut être vérifié avant qu'un visiteur ne s'en aperçoive.
Un Vary manquant. Une réponse qui change selon Accept sans porter Vary: Accept est, dans cette liste, le défaut qui peut montrer une image cassée à un visiteur. Vérifiez ce qu'envoie votre CDN et ce que laisse passer tout proxy placé devant lui.
Des paramètres de taille hors de la clé de cache. Une seule taille pour tout le monde : demandez deux largeurs de la même image et comparez ce qui revient.
Des paramètres sans limite. Si n'importe quelle largeur est acceptée, n'importe qui peut demander des milliers de tailles et vous faire payer chaque conversion. Une liste fixe de largeurs dans vos gabarits limite vos propres pages à quelques variantes ; les requêtes venues de l'extérieur, elles, ne s'arrêtent qu'avec une limite côté service, comme une liste de largeurs autorisées ou une limitation du nombre de requêtes.
Des fichiers plus lourds. Mesurez votre propre mélange d'images. Si le service ne compare pas les octets, ce sont les aplats et les icônes qui en pâtissent.
Des formats qui passent tels quels. Les GIF animés, les fichiers SVG et les images déjà en WebP sortent souvent inchangés ; vérifiez quels formats votre service convertit.
Le coût de traitement et les quotas. Encoder, surtout en AVIF, demande bien plus de CPU qu'envoyer un fichier en cache, et les services le mesurent : par transformation, par octet traité ou sur le quota d'une offre. Lisez comment le vôtre compte avant d'activer toutes vos images d'un coup.
Des copies périmées. Les images que les navigateurs ont chargées avant l'activation restent dans leur cache jusqu'à leur expiration, et aucune purge du CDN ne les atteint. Jugez le résultat avec une nouvelle requête, comme celle du vérificateur ci-dessous, plutôt qu'avec un rechargement.
Vérifiez ce que sert votre site
Le vérificateur ci-dessous montre ce que fait un CDN d'images, ou son absence, sur une vraie page. Il lit le HTML de la page, prend jusqu'à 20 images dans <img>, srcset, <picture> et og:image, et demande chacune deux fois : une fois comme un navigateur actuel (Accept: image/avif,image/webp,…), une fois comme un client qui accepte tout (Accept: */*). Il lit les premiers octets de chaque réponse pour connaître le vrai format, quoi qu'en dise le nom du fichier, compte les octets, et indique Vary et l'état du cache. Une simple adresse d'image fonctionne aussi.
Si les deux requêtes reçoivent le format d'origine pour chaque image, rien sur le trajet ne convertit vos images. Si la requête moderne reçoit de l'AVIF ou du WebP sans Vary: Accept dans la réponse, corrigez cela en premier. La page du vérificateur explique chaque résultat et ses limites.
L'optimisation d'image sur CDN.com.tr
L'optimisation d'image est un interrupteur pour tout votre compte ou pour une seule règle de diffusion. L'edge convertit les images JPEG et PNG en WebP, ou en AVIF et WebP si vous choisissez WebP + AVIF pour le compte, et chaque navigateur reçoit un format qu'il accepte ; les navigateurs qui n'acceptent ni l'un ni l'autre reçoivent l'image dans son format d'origine. Avec WebP + AVIF, la réponse vient de la même URL, avec Vary: Accept ; avec WebP seul, les navigateurs qui acceptent le WebP sont redirigés vers une copie .webp. Dans les deux cas, votre HTML garde les mêmes URL d'images. En pleine taille, une image nouvellement convertie n'est envoyée que si elle est plus légère que l'original. Si une conversion échoue, l'edge sert l'image d'origine à la place. Le traitement est décompté de votre quota mensuel.
Les mesures ci-dessus viennent de cet optimiseur. Avec WebP + AVIF, la photo d'actualité de 262 025 octets part en 86 936 octets d'AVIF, et la capture du panneau de 105 078 octets en 27 942. Les images PNG petites ou en aplats jusqu'à un mégapixel (icônes, captures d'écran, illustrations) doivent aussi battre notre propre PNG optimisé : un navigateur qui accepte le WebP mais pas l'AVIF reçoit donc cette capture sous la forme du PNG de 40 379 octets, et le favicon part en WebP de 314 octets plutôt qu'en AVIF de 682.
Le redimensionnement passe par l'URL : ajoutez ?w=, ?h= ou les deux à l'adresse d'une image. Une seule valeur conserve les proportions, les deux font tenir l'image dans ce cadre, et une image n'est jamais agrandie au-delà de sa taille d'origine. Les images redimensionnées sont converties elles aussi, mais elles ne sont pas comparées à l'original. Une règle garde w et h dans sa clé de cache tant qu'elle garde la chaîne de requête, ce qui est le réglage par défaut ; une règle qui ignore tous les paramètres de requête met en cache une seule taille pour toutes.
Les copies que la périphérie a converties avant l'arrivée de la comparaison en pleine taille restent telles quelles jusqu'à leur expiration ou leur purge, et les navigateurs qui ont déjà chargé une image gardent leur copie jusqu'à ce qu'elle expire dans le navigateur. Avec WebP seul, la redirection vers la copie .webp ne porte pas Vary: Accept, et c'est ce que signale le vérificateur ci-dessus ; WebP + AVIF répond à tous les navigateurs depuis la même URL, avec Vary: Accept. L'AVIF est décompté du quota à un taux plus élevé que le WebP, parce que son encodage demande plus de traitement ; le panneau affiche le taux actuel sous l'interrupteur. La rubrique d'aide sur l'optimisation des images détaille les interrupteurs, le choix du format et la purge.
WordPress. Sur un site WordPress derrière CDN.com.tr, c'est la périphérie qui convertit : les images de votre médiathèque sont converties en traversant le CDN, si bien que votre serveur ne dépense aucun CPU en encodage, qu'aucun fichier WebP ou AVIF supplémentaire n'est écrit dans la médiathèque, et que thèmes et constructeurs de pages continuent de fonctionner puisque les URL des images ne changent pas. Quand un site n'est pas sur notre CDN, l'extension gratuite CDNTR peut convertir les images en WebP, et en AVIF là où le serveur le permet, sur le serveur du site lui-même. Choisissez l'un ou l'autre : avec la conversion en périphérie activée, laissez désactivée la conversion locale de l'extension, pour que la périphérie travaille à partir de vos originaux.
Questions fréquentes
Quelle est la différence entre un CDN et un CDN d'images ?
Un CDN stocke des copies de vos fichiers près de vos visiteurs et les envoie sans les modifier. Un CDN d'images le fait aussi, et il transforme en plus les images au passage : il les convertit dans un format que chaque navigateur accepte, les redimensionne quand l'URL demande une taille et met chaque résultat en cache. Beaucoup de CDN proposent l'optimisation d'images comme un interrupteur : les deux sont donc souvent le même réseau, avec une fonction activée.
Un CDN d'images modifie-t-il mes fichiers d'origine ?
Non. Les originaux restent sur votre serveur ou votre stockage, tels que vous les avez téléversés ; les copies converties et redimensionnées sont produites sur le chemin de diffusion et vivent dans le cache du CDN. Quand les images converties partent sous les URL d'origine, désactiver la conversion rend les originaux aux visiteurs à mesure que les copies en cache expirent ou sont purgées.
Ai-je encore besoin de l'élément <picture> ?
Pas pour les formats. Avec un CDN d'images qui négocie, un simple <img> reçoit de l'AVIF, du WebP ou l'original selon le navigateur, et les lignes <source type="image/avif"> peuvent disparaître. Gardez <picture> pour la direction artistique, quand un petit écran doit recevoir un autre cadrage et non une copie plus petite de la même image.
Une image convertie peut-elle être plus lourde ?
Oui, plus lourde que la meilleure version de l'original, si le service convertit sans comparer. Dans notre mesure, un favicon de 16×16 pesait 682 octets en AVIF contre 483 en PNG optimisé et 314 en WebP, et une capture du panneau est sortie plus lourde en WebP (41 218 octets) qu'en PNG optimisé (40 379). Un bon service vérifie les octets et envoie le fichier le plus léger. Sur CDN.com.tr, une image en pleine taille nouvellement convertie n'est envoyée que si elle est plus légère que l'original, et un PNG petit ou en aplats jusqu'à un mégapixel seulement s'il bat aussi notre PNG optimisé.
Un CDN d'images vaut-il le coup pour WordPress ?
En général, oui, parce que les sites WordPress sont l'endroit où les images s'accumulent plus vite que quiconque ne les optimise. La conversion en périphérie atteint les images JPEG et PNG de toute la médiathèque, anciens envois compris, sans convertisseur sur votre serveur ni fichiers supplémentaires dans wp-content/uploads. Pour un site qui n'est pas sur un CDN, l'alternative est une extension qui convertit en local, comme CDNTR.
Comment le traitement des images est-il facturé sur CDN.com.tr ?
Il est décompté du quota mensuel du compte, comme le trafic ; il n'y a pas d'offre séparée à acheter. L'AVIF compte à un taux plus élevé que le WebP parce que son encodage demande plus de traitement, et le panneau affiche le taux actuel sous l'interrupteur.