Les images sont presque toujours la partie la plus lourde d’une page, et bien les optimiser demande de réunir de nombreux éléments : des formats modernes comme AVIF et WebP, des tailles adaptées à chaque emplacement et à chaque écran, une qualité de compression raisonnable, une livraison rapide à des utilisateurs répartis un peu partout. Faite à la main, ou avec les outils de base d’un CMS, c’est un travail qui réussit rarement sur toutes les images d’un site. Les CDN d’images promettent de le faire automatiquement : on envoie l’image une seule fois, et le service produit à la volée toutes les variantes nécessaires.
Dans cet article, nous voyons comment ils fonctionnent, ce qu’ils offrent par rapport aux plugins qui optimisent les images directement sur le serveur, quels sont les coûts et les risques, et comment savoir si en adopter un est vraiment rentable pour un site.
Comment fonctionne un CDN d’images
Un CDN d’images est un service qui se place entre le site et le navigateur. Le site ne conserve que l’image d’origine, à la plus haute qualité disponible. Les pages, au lieu de pointer directement vers le fichier, pointent vers une URL du service qui contient les instructions de transformation : la largeur voulue, le type de recadrage, la qualité, le format. Quand arrive la première requête pour une combinaison de paramètres donnée, le service télécharge l’original, le transforme, l’envoie au navigateur et le stocke dans son propre cache ; les requêtes suivantes pour la même variante sont servies directement depuis le cache du nœud le plus proche de l’utilisateur.
Le format est en général choisi automatiquement d’après l’en-tête Accept envoyé par le navigateur : ceux qui prennent en charge AVIF le reçoivent, les autres reçoivent du WebP ou du JPEG. C’est le même mécanisme de négociation que celui décrit dans l’article sur les formats WebP et AVIF, la gestion correcte du cache et de l’en-tête Vary étant laissée au service. De nombreux services peuvent aussi ajuster automatiquement la qualité selon le contenu de l’image, en compressant davantage là où la perte ne se voit pas.
<!-- La même image en quatre largeurs, format choisi par le service -->
<img src="https://img.esempio.it/prodotti/divano.jpg?w=800&f=auto&q=auto"
srcset="https://img.esempio.it/prodotti/divano.jpg?w=400&f=auto&q=auto 400w,
https://img.esempio.it/prodotti/divano.jpg?w=800&f=auto&q=auto 800w,
https://img.esempio.it/prodotti/divano.jpg?w=1200&f=auto&q=auto 1200w,
https://img.esempio.it/prodotti/divano.jpg?w=1600&f=auto&q=auto 1600w"
sizes="(min-width: 1024px) 50vw, 100vw"
width="1600" height="1067" alt="Canapé trois places en velours vert">La syntaxe des paramètres varie d’un service à l’autre : certains les placent à la fin de l’URL, d’autres dans le chemin. Le principe est le même, et il se combine naturellement avec les images responsives : chaque entrée de srcset devient une URL avec une largeur différente, sans avoir à générer le moindre fichier à l’avance.
Ce que l’on gagne
- Des tailles exactes. Chaque emplacement de la page peut recevoir une image de la bonne largeur, et non la plus proche parmi les quelques tailles générées par le CMS. Pour une nouvelle mise en page, il suffit de changer les paramètres, sans régénérer des milliers de fichiers.
- Des formats modernes sans travail. AVIF et WebP sont produits et servis automatiquement, et quand un meilleur format arrive, il suffit que le service le prenne en charge.
- Moins de charge sur le serveur. Le serveur d’origine n’a pas à générer de variantes lors de l’envoi des images ni à les servir à chaque visite : le service s’en charge, depuis son propre réseau.
- Une livraison proche des utilisateurs. Les images sont servies depuis des nœuds répartis géographiquement, avec des temps de connexion et de téléchargement plus courts pour les visiteurs éloignés du serveur.
- Des fonctionnalités en plus. Recadrage intelligent sur le sujet, suppression des métadonnées, conversion des GIF animés en vidéo, filigranes : des fonctions qui demanderaient un logiciel spécifique sur le serveur.
Ce que cela coûte, et ce que cela risque
Le premier coût est financier. La tarification dépend en général du nombre de transformations, du trafic servi ou des deux, et croît avec le site. Pour un site de quelques centaines d’images et un trafic modéré, la dépense peut être minime ; pour un catalogue de centaines de milliers de produits et de nombreuses visites, il faut l’estimer avec soin, notamment parce que chaque combinaison de largeur, de format et de qualité compte comme une variante distincte.
Le deuxième concerne la performance de la première requête. Quand une variante n’est pas encore dans le cache, le service doit télécharger l’original et le transformer, et cette requête peut prendre des centaines de millisecondes. Pour les images très visitées, le problème se résout de lui-même, mais pour l’image principale d’une nouvelle page, qui est souvent l’élément du LCP, le premier visiteur peut en payer le coût. Certains services permettent de prégénérer les variantes principales ; sinon, on peut visiter les nouvelles pages juste après leur publication.
Le troisième est le domaine. Si les images sont servies depuis un domaine différent de celui du site, le navigateur doit ouvrir une connexion supplémentaire, avec résolution DNS, TCP et TLS : un coût payé sur l’image la plus importante. Un preconnect vers le domaine du service, comme l’explique l’article sur preload, preconnect et fetchpriority, le réduit ; de nombreux services permettent aussi d’utiliser un sous-domaine du site ou de passer par le même CDN que celui qui sert les pages, ce qui supprime la connexion supplémentaire.
Le quatrième est la dépendance vis-à-vis du fournisseur (vendor lock-in). Les URL d’images avec les paramètres du service finissent dans les contenus, les modèles et parfois les newsletters : changer de service oblige à les réécrire. Il vaut donc la peine de générer les URL depuis un point unique, par exemple une fonction du thème ou un plugin, plutôt que de les insérer à la main, et de toujours conserver les originaux sur son propre site.
Les alternatives
Un service externe n’est pas toujours nécessaire. Il existe trois approches principales, chacune adaptée à des situations différentes.
La première, ce sont les plugins qui optimisent les images sur le serveur : ils compressent les originaux, génèrent des variantes WebP ou AVIF avec les tailles attendues par le thème, et les servent avec les règles de négociation du serveur. Ils sont prévisibles côté coût, ne dépendent pas de services externes et suffisent pour la plupart des petits et moyens sites. Les limites sont l’espace disque, le travail du serveur lors de l’envoi des images et les tailles fixes.
La deuxième, ce sont les fonctions de transformation d’images proposées par de nombreux CDN généralistes, qui peuvent être activées sur le domaine du site et sont souvent intégrées au cache de page, comme nous l’avons vu à propos de Cloudflare. La troisième, ce sont les services spécialisés complets, qui ajoutent gestion des fichiers, recadrage intelligent, transformations avancées et intégrations avec les CMS, pour un coût plus élevé.
WordPress et les CDN d’images
Dans WordPress, l’intégration passe presque toujours par un plugin du service, qui réécrit les URL d’images dans les contenus et les modèles et génère les valeurs de srcset avec les paramètres du service. Pour ceux qui préfèrent un contrôle direct, les filtres du noyau permettent d’intervenir sur les URL des variantes :
// Réécrit les variantes du srcset pour pointer vers le service de transformation
add_filter(
'wp_calculate_image_srcset',
function ( $sources ) {
foreach ( $sources as $larghezza => $source ) {
$percorso = wp_parse_url( $source['url'], PHP_URL_PATH );
$sources[ $larghezza ]['url'] = 'https://img.esempio.it' . $percorso
. '?w=' . (int) $larghezza . '&f=auto&q=auto';
}
return $sources;
}
);Avec un CDN d’images, il vaut aussi la peine de réduire les tailles que WordPress génère à l’envoi, qui deviennent superflues, et de vérifier que les fonctions automatiques du noyau, comme l’ajout de fetchpriority="high" à l’image principale et l’exclusion des premières images du lazy loading, continuent de fonctionner après la réécriture des URL.
Qualité et compression
L’un des aspects les plus utiles et les moins considérés est la gestion de la qualité. Choisir un seul niveau de compression pour toutes les images d’un site est toujours un compromis : une photographie très détaillée tolère moins de compression qu’une image avec de grandes zones de couleur unie. Les réglages automatiques de nombreux services analysent chaque image et choisissent le niveau de compression le plus agressif qui ne produit aucune différence perceptible, avec des économies qui s’ajoutent à celles du format. Il vaut tout de même la peine de vérifier le résultat sur quelques images représentatives, surtout les photos de produits, où une perte de détail peut affecter la perception de la qualité, et de fixer un plancher pour les images les plus importantes.
Un exemple
Un site d’annonces immobilières reçoit chaque jour des centaines de photographies envoyées par les agences, souvent directement depuis les appareils photo, de plusieurs mégaoctets chacune. Pour chaque photo, le serveur génère six tailles différentes en JPEG, qui occupent des dizaines de gigaoctets et ralentissent le chargement des annonces ; les pages de recherche, avec vingt annonces et leurs photos, pèsent plus de quatre mégaoctets sur mobile. Avec un CDN d’images, le serveur ne conserve que les originaux, les pages demandent la largeur exacte pour chaque emplacement avec format et qualité automatiques, et les photographies sont servies depuis les nœuds les plus proches. Les pages de recherche passent sous le mégaoctet, la génération de variantes sur le serveur disparaît et le LCP des pages d’annonce s’améliore nettement. Le coût du service est en partie compensé par la réduction de l’espace disque et du trafic du serveur ; le reste se met en balance avec la hausse des contacts générés par les pages d’annonce.
Quand c’est rentable
Un CDN d’images est le choix naturel pour les sites qui ont beaucoup d’images et beaucoup de formats d’affichage : boutiques en ligne avec de grands catalogues, sites éditoriaux avec des archives photo, portails immobiliers, sites à contenu généré par les utilisateurs. Il est aussi utile quand le serveur d’origine est limité et ne peut pas se permettre de générer et de servir de nombreuses variantes, ou quand l’audience est répartie sur plusieurs continents.
Pour un site institutionnel de quelques dizaines d’images, un blog ou une boutique au petit catalogue, un bon plugin d’optimisation sur le serveur, avec des formats modernes et des tailles responsives correctes, obtient en général des résultats très proches, sans coûts récurrents ni dépendances externes. Le critère décisif n’est pas la technologie, mais le rapport entre le travail que le service épargne et ce qu’il coûte.
Comment vérifier le résultat
Après l’activation, quelques vérifications confirment que le service fonctionne comme prévu. Dans le panneau Network des DevTools, les images doivent arriver au format moderne pour les navigateurs qui le prennent en charge, avec des tailles proches de la taille d’affichage et de longs en-têtes de cache. L’image du LCP demande une attention particulière : elle doit être découverte immédiatement, avoir une priorité haute et ne pas subir de retard dû à une connexion supplémentaire. Il vaut aussi la peine de consulter les rapports du service sur le pourcentage de requêtes servies depuis le cache : un pourcentage bas indique trop de combinaisons de paramètres différentes, et donc des transformations fréquentes, plus lentes et plus coûteuses.
En bref
Un CDN d’images conserve un seul original et produit à la volée les variantes nécessaires, dans le meilleur format pour chaque navigateur et à la bonne taille pour chaque emplacement, en les servant depuis un réseau distribué. Les bénéfices sont concrets : tailles exactes, formats modernes automatiques, moins de charge sur le serveur, livraison rapide. Les coûts le sont tout autant : une tarification qui croît avec le site, une première transformation lente, des connexions supplémentaires si le domaine est différent, la dépendance aux URL du fournisseur.
Pour les sites qui ont beaucoup d’images et beaucoup de trafic, c’est souvent la solution la plus efficace ; pour les plus petits, un plugin bien configuré sur le serveur offre l’essentiel des bénéfices sans coûts récurrents. Dans les deux cas, le résultat doit être vérifié sur les pages réelles, avec une attention particulière à l’image qui décide du LCP.
