WebP par défaut en attente pour 6.1 après de nouvelles objections des développeurs principaux de WordPress

La semaine dernière, les contributeurs de l'équipe Performance travaillaient à affiner leurs correctifs de suivi pour la fonctionnalité multi-mime/WebP, après que le travail principal ait été fusionné dans le noyau pour 6.1 à la fin du mois de juillet. Cela inclut des éléments connexes plus petits, tels que le shim pour les navigateurs non compatibles et l'ajout de la prise en charge PDF, qui sont traités dans des tickets séparés.

La proposition de générer des images WebP par défaut pour les nouveaux téléchargements d'images JPEG a été controversée depuis le début. Alors que les contributeurs parrainés par Google à la tête du projet ont apporté quelques révisions après une première série de commentaires critiques importants, d'autres contributeurs ont continué à exprimer des préoccupations qui, selon eux, n'étaient pas prises en compte. Plusieurs contributeurs ont signalé des problèmes avec la fonctionnalité et ont suggéré qu'elle devrait commencer par être opt-in, une idée qui a été sommairement rejetée avant que le travail principal ne soit engagé.

La semaine dernière, le développeur principal de WordPress, Andrew Ozz, a pesé sur le ticket avec de nouvelles objections :

Comme @MatthiasReinholz, @eatingrules et d'autres, je pense que cette approche fait peut-être défaut. Pourquoi y aurait-il deux fois plus de fichiers image occupant beaucoup d'espace supplémentaire alors que la moitié d'entre eux ne seront jamais utilisés nulle part ?

À mon humble avis, une meilleure approche consisterait à créer toutes les sous-tailles d'image WEBP. Si des fichiers JPEG sont effectivement nécessaires, ils peuvent être générés à la volée selon les besoins. Inutile d'encombrer le stockage des serveurs Web avec tous ces fichiers inutiles.

D'un autre côté, si les tailles de fichiers WEBP sont en fait plus grandes que les JPEG, cela signifierait probablement que de meilleurs outils sont nécessaires, et ce correctif est prématuré.

Il y a six semaines, en réponse à une plainte selon laquelle les "ressources pour la conversion seraient énormes", Adam Silverstein, principal responsable de l'engagement parrainé par Google, a confirmé que les ressources pour générer les images lors du téléchargement "augmenteraient considérablement".

"Cependant, les ressources pour servir une image seront réduites", a déclaré Silverstein. "Étant donné que le téléchargement d'images est très rare par rapport à la diffusion d'images, l'effort supplémentaire pour compresser et stocker les images devrait en valoir la peine."

C'est un autre problème cité par Ozz dans son objection à cette approche.

"En fait, cette augmentation spectaculaire de l'utilisation des ressources lors du téléchargement d'une image est un très mauvais effet secondaire ici", a déclaré Ozz. "Cela signifie que de nombreux téléchargements échoueront et laisseront les utilisateurs bloqués. Cela augmentera également considérablement les demandes d'assistance pour WordPress et les sociétés d'hébergement. Ne pensez pas que c'est acceptable. Pour cette raison, même si le support multi-mime d'image est nécessaire dans WordPress, l'approche actuelle ne semble pas être une bonne solution.

Environ 24 heures plus tard, le contributeur parrainé par Google, Felix Arntz, a déclaré que le mécanisme de repli WebP vers JPEG pour les anciens navigateurs était prêt à être validé et qu'il prévoyait de le valider dans quelques jours.

"S'il vous plaît, ne validez plus de code ici, à moins que ce ne soit pour faire face à l'augmentation spectaculaire des ressources nécessaires pour créer des sous-tailles d'image après le téléchargement", a déclaré Ozz. « Comme je l'ai dit plus haut, une telle augmentation est inacceptable.

"Existe-t-il des données sur la quantité de ressources supplémentaires (mémoire, temps de traitement, etc.) nécessaires lors du téléchargement de différentes tailles d'image ? Une estimation du nombre de sites pouvant être concernés par cela ? Des suggestions sur la façon d'y faire face? Savez-vous ce qui se passe lorsque le post-traitement d'une image téléchargée échoue ?

"Franchement, pour l'instant, il semble que ce patch devra être annulé et refactorisé afin de résoudre ce problème."

Adam Silverstein a répondu à ses préoccupations en expliquant pourquoi ils ont choisi l'approche actuelle, en prévision de certains cas extrêmes et en ajoutant éventuellement la prise en charge de formats comme AVIF une fois qu'ils seront plus largement pris en charge :

J'ai tendance à être d'accord avec votre évaluation selon laquelle toutes les sous-tailles devraient être générées uniquement en tant que WebP, c'était la forme de la proposition originale. Pour la grande majorité des cas d'utilisation/utilisateurs, cela fonctionnera le mieux. Je serais ouvert à considérer cela comme valeur par défaut (avec quelques atténuations, voir ci-dessous).

La raison pour laquelle nous avons décidé de générer les deux formats était pour des considérations de compatibilité descendante pour les quelques cas extrêmes que nous avons identifiés où les images WebP pourraient ne pas fonctionner : à savoir les images envoyées par e-mail (certains anciens clients Outlook/Windows), les balises Open Graph (certains services ne prennent pas en charge WebP) et les anciens navigateurs Safari. Une possibilité que nous avons envisagée serait de ne conserver que le JPEG pleine taille afin qu'il soit toujours disponible pour ces cas extrêmes.

La prise en charge «multi-mime» ici est conçue pour générer plusieurs formats afin que vos sites puissent fournir un format principal et de secours avec quelque chose comme l'élément d' picture . Ceci est moins important pour WebP car il est si largement pris en charge, mais serait utile pour adopter de nouveaux formats comme AVIF par plugins ou core.

Silverstein a également déclaré que l'option de générer des images à la volée était quelque chose qu'ils devaient comprendre, mais "semblait hors de portée pour cet effort".

En réponse à la plainte concernant l'augmentation spectaculaire des ressources pour les téléchargements d'images, Silverstein a déclaré qu'ils s'appuyaient sur le mécanisme de "nouvelle tentative" pour atténuer ce problème.

"Ce changement double également le nombre de fois que WordPress réessaiera" la régénération d'image, donc même si le temps de traitement augmentera, je ne pense pas que nous verrons nécessairement une augmentation des échecs ", a-t-il déclaré. "Je sais que nous avons eu du mal à ajouter de nouvelles tailles dans le passé, mais c'était avant que nous ayons ajouté le mécanisme de nouvelle tentative."

L'équipe à l'origine du projet WebP par défaut se concentre davantage sur la fourniture d'images de plus petite taille sur le frontend et considère l'utilisation de ressources supplémentaires lors du téléchargement comme un sacrifice nécessaire pour les utilisateurs de WordPress.

"Les ressources supplémentaires au moment du téléchargement doivent être mises en balance avec les ressources réduites de la diffusion de l'image WebP plus petite, d'autant plus que la diffusion se produit généralement plusieurs ordres de grandeur plus fréquemment que le téléchargement", a déclaré Silverstein.

"Si le téléchargement échoue après toutes les tentatives, l'utilisateur vit la même expérience qu'actuellement : il se retrouve avec une image cassée et inutilisable. Cela peut probablement être corrigé, même si je ne pense pas que ce changement augmentera les taux d'échec.

Le développeur principal de WordPress, Dion Hulse, a également commenté le ticket pour signaler les problèmes de conversions WebP dans le répertoire de photos WordPress :

Il suffit de noter ici que ces conversions Webp supplémentaires semblent avoir été la principale cause d'échecs de téléchargement sur le répertoire de photos WordPress ces dernières semaines. Voir #meta6142 et les tickets fermés en double.

Les erreurs étaient généralement du Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (évidemment avec des valeurs d'octets) lors de la tentative d'exécution de la conversion originale jpeg -> webp initiale en taille réelle.

Cela n'a pas affecté chaque téléchargement , seulement celui de certaines images. Potentiellement lié à la valeur $quality transmise pour les requêtes webp (IIRC, la valeur par défaut de 82 a été optimisée pour jpeg ?).

Hulse a désactivé la conversion JPEG en WebP à la suite de ces erreurs, car le répertoire de photos n'utilise pas actuellement WebP, mais a noté que cela "pourrait être un signe qu'il pourrait être utile d'envisager de ne générer que des webp pour les images redimensionnées, plutôt que pour le fichier original aussi.

Silverstein a déclaré qu'ils enquêtaient sur les problèmes signalés par Hulse, car cela pourrait avoir révélé un bogue.

Ozz est revenu en arrière pour recommander que la création de sous-tailles à la demande serait une meilleure approche qui permettrait un traitement plus rapide des images téléchargées et des besoins en espace réduits, puisque les images JPEG supplémentaires ne seraient pas générées à moins que cela ne soit nécessaire. Il a également noté que la « nouvelle tentative » de post-traitement d'image « ne fonctionne pas aussi bien que prévu ».

"La mauvaise nouvelle est que si le post-traitement échoue, il est probable que le fichier téléchargé à l'origine restera", a déclaré Ozz. "Ensuite, il sera utilisé partout car la plupart du code dans WP revient aux tailles disponibles, et la seule taille sera l'original. Cela signifie que nous servirons d'énormes images (4 Mo - 8 Mo en moyenne). Un sérieux inconvénient.

Silverstein a répondu aux suggestions d'Ozz, en accord avec beaucoup, et a proposé deux voies potentielles pour le projet :

1. Conservez l'infrastructure multi-mime actuelle, mais modifiez les valeurs par défaut afin que seuls les fichiers WebP soient générés, éventuellement jusqu'à une taille seuil au-delà de laquelle seuls les fichiers JPEG seraient générés. La plupart des travaux existants continueraient; le filtrage de contenu pourrait éventuellement être supprimé.
2. Rétablissez l'infrastructure multi-mime et revenez à une approche mime unique, en utilisant WebP pour les images jusqu'à une taille seuil et en ajustant la couche de compatibilité pour utiliser les JPEG que nous conservons.

L'équipe Performance fait plus de recherches et a temporairement suspendu tout autre engagement jusqu'à ce qu'elle reçoive des commentaires sur la prochaine direction du projet.