Vérificateur de format d'image

Ce que fait le vérificateur

1. Lit une fois le HTML de la page (jusqu'à 1,5 Mo) et prend jusqu'à 20 images dans <img> (avec srcset et les attributs courants de chargement différé), <picture> et og:image.
2. Demande chaque image deux fois : avec Accept: image/avif,image/webp,…, comme l'envoie un navigateur récent, et avec Accept: */*, comme un client qui ne demande rien de particulier.
3. Lit les premiers octets de chaque réponse pour connaître le format réel, quoi que disent le nom du fichier ou le Content-Type, et compte les octets.
4. Affiche l'en-tête Vary et le statut de cache indiqué par le CDN, et suit jusqu'à 3 redirections en vérifiant à nouveau chaque adresse cible.
5. Pour un <picture> avec un <source> AVIF ou WebP, la requête moderne va à ce source et l'autre à l'<img> : là, c'est le navigateur qui choisit le format, pas le serveur.

Lire les résultats

AVIF ou WebP

Un navigateur qui prend en charge ces formats en a reçu un. La taille indiquée à côté est ce que ce navigateur a téléchargé ; la taille sous « Autres navigateurs » est ce que reçoit un navigateur sans prise en charge d'AVIF ni de WebP.

Original uniquement

L'image est arrivée en JPEG, PNG ou GIF même à un navigateur qui demandait AVIF et WebP : le site ne la convertit pas.

Le même fichier pour tous les navigateurs

Les deux requêtes ont reçu le même format. C'est le résultat d'un site sans négociation de format, et d'un site qui sert des fichiers WebP à tout le monde. Sans rien à comparer, aucune économie n'est affichée.

Sans Vary: Accept

La réponse change selon l'en-tête Accept mais ne l'indique pas avec Vary: Accept, et les caches partagés ont le droit de la conserver. Un proxy entre le serveur et le visiteur pourrait alors remettre un fichier AVIF ou WebP à un navigateur qui ne l'a pas demandé.

L'économie

Seules les images dont les deux réponses ont été lues en entier, et sont arrivées dans des formats différents, comptent dans le total. Une taille connue seulement par Content-Length est affichée mais jamais additionnée : le chiffre est une mesure, pas une estimation.

Limité ou bloqué

Si un site répond 429, 403, une vérification anti-robots ou la petite page 503 qu'envoient les limiteurs de débit, le vérificateur cesse de lui envoyer des requêtes pour cette vérification et marque les images restantes comme non vérifiées. Réessayez quelques minutes plus tard.

Comment un serveur choisit le format

Un navigateur liste dans son en-tête Accept les formats d'image qu'il sait afficher. Un serveur ou un CDN qui convertit les images le lit et répond en AVIF, en WebP ou avec l'original depuis la même URL. Il doit aussi envoyer Vary: Accept, pour que les caches gardent une copie par format.

L'autre méthode est dans le HTML : un élément <picture> liste des fichiers <source> AVIF et WebP et le navigateur prend le premier qu'il prend en charge. Les deux fonctionnent, et le vérificateur suit celle qu'utilise la page.

AVIF ou WebP : lequel est le plus léger, et quand

Limites et ce que nous envoyons

• Jusqu'à 20 images sur 5 serveurs au plus par page, jusqu'à 5 Mo lus par image, 20 secondes par vérification.
• 3 vérifications par minute et 20 par jour depuis une même adresse. Une vérification terminée est réutilisée pendant 10 minutes, et un site est vérifié au plus 6 fois en 10 minutes, quel que soit le demandeur.
• Les requêtes partent de notre serveur en Turquie en IPv4, avec un User-Agent qui se termine par cdn.com.tr-image-check/1.0 et renvoie à cette page. Un CDN peut nous répondre depuis un autre emplacement que pour vos visiteurs, certains sites bloquent les clients automatisés, et un site joignable uniquement en IPv6 ne peut pas être vérifié.
• Seules les adresses publiques sur les ports 80 et 443 sont demandées ; les réseaux privés et internes sont refusés. Les images ne sont pas conservées : seuls les formats, les tailles et quelques en-têtes reviennent.
• Les images que JavaScript ajoute après le chargement de la page et les images de fond CSS ne sont pas dans le HTML : le vérificateur ne les voit pas.