ImagePipe négocie le format d'image à chaque requête via l'en-tête Accept du navigateur : AVIF en priorité à partir du palier Pro, puis WebP, puis un repli JPEG/PNG. En plaçant un CDN ou un proxy inverse devant ImagePipe, on ajoute une couche de cache entre le navigateur et le cache disque permanent d'ImagePipe. Si ce CDN met en cache la réponse image sans tenir compte de l'en-tête Accept, il ne stocke qu'une seule variante, par exemple l'AVIF, et la resert à tous les visiteurs demandant la même URL, y compris ceux dont le navigateur ne l'a jamais annoncée comme supportée.
Le symptôme est irrégulier : certains visiteurs voient une image cassée ou anormalement lourde, d'autres ne remarquent rien, selon la variante mise en cache en premier et le nœud du CDN qui répond. Ce n'est pas un bug d'ImagePipe, qui envoie la bonne réponse pour chaque requête reçue : le problème se situe une couche au-dessus, dans la décision de mise en cache du CDN.
Avant d'activer un CDN devant ImagePipe, vérifiez s'il respecte Vary: Accept sur les réponses : la plupart des CDN le supportent mais ne l'activent pas par défaut, et certains plafonnent le nombre de variantes de cache par URL basées sur Vary. Si votre CDN ne gère pas du tout le cache par Vary, la solution la plus sûre consiste à segmenter vous-même la clé de cache, par exemple en y incluant un indicateur de format normalisé, pour que les réponses AVIF, WebP et JPEG/PNG ne se retrouvent jamais mélangées sous la même entrée.
Une fois la configuration faite, vérifiez-la en demandant deux fois la même URL d'image via le CDN : une fois avec un en-tête Accept qui exclut AVIF et WebP, une fois avec l'en-tête par défaut d'un navigateur récent, puis comparez le Content-Type reçu à chaque fois. Si les deux requêtes renvoient les mêmes octets en cache, le CDN ne respecte toujours pas la négociation et nécessite un réglage supplémentaire avant mise en production.