Configurer WebP et AVIF
D'abord regarder ce dont ton serveur est capable
Dans la section « Images » se trouve la carte « Capacités de ce serveur ». Elle ne montre pas ce qui est écrit sur le papier, mais ce qui a été mesuré sur le PHP en fonctionnement : bibliothèque d'images GD avec sa version, lecture JPEG, lecture PNG, lecture WebP, écriture WebP, écriture AVIF. La question est posée deux fois — la fonction doit exister et le format doit figurer dans imagetypes(). C'est important, car certains hébergeurs compilent GD sans WebP ni AVIF : imagewebp() est alors présente et n'échoue qu'à l'appel.
S'il manque un format, l'interrupteur correspondant reste certes visible, mais il est désactivé et porte la justification. Pour WebP, elle est : GD doit être compilé avec libwebp. Pour AVIF : PHP 8.1 ou plus récent avec libavif. Les deux relèvent de ton hébergeur. Passer par l'appel AJAX pour contourner cela n'aide en rien — le serveur refuse explicitement l'activation d'un format non disponible.
La ligne « Imagick » est purement informative. Ce module n'utilise pas Imagick ; s'il y est écrit « non disponible », il ne te manque rien.
Activer et régler les trois nombres
Il y a trois interrupteurs et trois champs numériques. « Générer du WebP » et « Générer de l'AVIF » sont désactivés par défaut, « Diffuser via <picture> » est activé. Cette séparation est voulue : tu peux d'abord laisser les fichiers se créer et n'activer la diffusion que plus tard. Inversement : si tu désactives la diffusion, les fichiers continuent d'être créés, mais les visiteurs reçoivent un balisage inchangé.
La qualité WebP est sur 82, la qualité AVIF sur 50. Les deux champs acceptent des valeurs de 30 à 100, tout ce qui est au-dessus ou en dessous est ramené à cette plage. Les valeurs par défaut différentes ne sont pas un oubli : AVIF mesure autrement que JPEG, 50 y donne déjà un rendu très propre. Au-delà de 90, le fichier WebP grossit plus vite que le gain visible.
La limite supérieure en mégapixels est sur 40 et accepte des valeurs de 4 à 400. Elle protège de la limite de mémoire : une photo de 6000 × 4000 occupe environ 96 MB au décodage, quelle que soit la taille de son fichier. En plus, avant chaque décodage, Kakapo fait le calcul par rapport à la mémoire réellement encore libre et saute l'image, plutôt que de laisser le téléversement mourir à la limite.
Si tu modifies l'un des trois interrupteurs, le cache de pages déposé est jeté. La qualité et la limite de mégapixels le laissent en place — elles n'agissent qu'au prochain téléversement et ne rendent fausse aucune page déjà déposée.
Ce qui se passe lors du téléversement
La conversion s'exécute à la fin du téléversement, dès que WordPress a créé toutes les tailles d'image. Sont traités le fichier issu des métadonnées et chaque taille créée — pas l'original conservé par le cœur, qui de toute façon n'est jamais diffusé.
Chaque dérivé se trouve comme fichier compagnon à côté de son original et porte le nom complet de celui-ci plus l'extension : bild.jpg devient bild.jpg.webp, pas bild.webp. Raison : dans le même dossier, bild.jpg et bild.png peuvent coexister ; en remplaçant simplement l'extension, l'un des dérivés écraserait l'autre. Si quelque chose se trouve déjà à l'emplacement cible, il n'est pas touché.
L'écriture se fait d'abord dans un fichier annexe dont le nom contient le numéro de processus et une part d'aléatoire. Ce n'est que lorsqu'il s'avère, mesure à l'appui, plus petit que l'original qu'il prend sa place par rename. S'il est plus grand ou de taille égale, il est supprimé et l'original reste en place. Un traitement interrompu ne laisse donc jamais derrière lui un dérivé trop grand.
Le téléversement dispose d'un budget de temps de 12 secondes. À la génération, AVIF est plusieurs fois plus lent que WebP, et six tailles multipliées par deux formats se heurteraient sinon au temps d'exécution du serveur web — l'exploitant verrait un téléversement interrompu. Ce qui n'y tient plus est rattrapé par un passage complémentaire unique : il est planifié 30 secondes plus tard et dispose alors de 90 secondes. Ce qui est fait comme ce qui est sauté est noté sur le fichier joint, afin que la même tentative ne soit pas répétée à chaque régénération.
Pour les JPEG, une rotation EXIF est appliquée après coup, car les WebP et AVIF issus de GD ne reprennent pas cette information. Pour les originaux PNG, Kakapo essaie d'abord le WebP sans perte — les logos, les graphiques et les captures d'écran deviennent ainsi souvent plus petits, sans que les contours s'effilochent. La transparence est conservée dans les deux formats cibles.
Comment se fait la diffusion
Kakapo enveloppe le <img> dans un <picture> et place devant lui des sources AVIF et WebP, AVIF en premier — le navigateur prend la première source qu'il comprend. Le <picture> reçoit display:contents, afin qu'il n'insère pas de boîte supplémentaire dans la disposition des mises en page Flex et Grid de ton thème.
Choix délibéré contre l'alternative via .htaccess : la négociation de contenu exige des règles Apache, ne fonctionne pas du tout sous nginx et entre en conflit avec les caches intermédiaires des CDN qui ne font pas varier l'en-tête Accept. Avec <picture>, c'est le navigateur qui décide, sans une seule ligne de configuration serveur.
L'intervention porte sur le contenu des articles et les images à la une, avec la priorité 22 — après le Lazy-Load (20), avant la réécriture CDN (25), afin que les sources nouvellement créées passent elles aussi par le CDN. Les blocs <picture> déjà présents restent intacts, de même que les images provenant d'hôtes étrangers et tout ce qui se trouve en dehors du dossier uploads.
Une règle vaut la peine d'être connue : un format n'est proposé que si la plus grande version du srcset existe en dérivé. S'il manque une taille moyenne ou petite, le navigateur prend la suivante en taille — quelques kilo-octets de plus, mais jamais une image floue. S'il manquait la plus grande, un écran large ne pourrait plus atteindre la pleine résolution ; c'est précisément ce cas qui est exclu.
Si rien n'est créé : lire les raisons
La carte « Fichiers générés & économie réelle » indique pour chaque format le nombre de fichiers, la somme des originaux, la somme des dérivés et la différence. Chaque chiffre provient de la comparaison de deux tailles de fichier réelles au moment de la création — rien n'est estimé ni extrapolé. « Originaux » ne désigne ici que la somme des fichiers pour lesquels un dérivé a été créé, pas l'ensemble de tes médias.
En dessous figure ce qui n'a pas été converti, avec la raison. Les plus importantes :
« Le résultat était plus grand que l'original » — ce n'est pas une erreur. Avec de très petites miniatures, cela arrive régulièrement en AVIF ; l'original est conservé et les autres tailles reçoivent malgré tout leur dérivé.
« Non inscriptible » — vérifier les droits dans le dossier uploads. C'est la seule raison qui réclame vraiment ton intervention.
« Un fichier se trouvait déjà à l'emplacement cible » — il n'a pas été écrasé. Le plus souvent, il provient du traitement par lots sur l'existant et est déjà exactement ce qui devait être créé ici.
« N'a pas tenu en mémoire » — augmenter la limite de mégapixels ou la limite de mémoire de PHP.
« Illisible » — fichier endommagé, JPEG CMJN ou variante exotique. « Pas un JPEG/PNG/WebP » — les GIF animés et les PDF ne sont volontairement pas touchés.
Si la carte est vide, active le WebP et téléverse une image. Les images déjà présentes dans la médiathèque ne s'atteignent pas par ce biais, mais par le traitement par lots plus bas sur la même page.