Le mois dernier, le plan de WordPress visant à générer des images WebP par défaut pour les nouveaux téléchargements d'images JPEG a été suspendu pour la prochaine version 6.1 suite aux objections des meilleurs développeurs. La proposition originale a été fusionnée avec le noyau fin juillet, malgré les commentaires critiques importants et les préoccupations de la communauté des développeurs WordPress. Hier, la fonction a été restaurée en réponse au récent poster par Matt Mullenweg sur la suppression du noyau pour le développement comme plug-in canonique:
J'ai lu toutes les conversations et les problèmes ici. Je suis intéressé par la prise en charge de nouveaux formats et l'amélioration des performances, mais je pense que ce changement envoyé par défaut aux utilisateurs lors de la mise à niveau vers 6.1 est beaucoup pour l'instant, même avec certaines des interactions maladroites que les systèmes d'exploitation ont encore autour de webp ( et HEIC ! ) dossier.
Je suis heureux que le support de travail pour les fichiers webp et HEIC reste dans le noyau, car nous devrions être libéraux dans ce que nous acceptons et travailler avec, mais pas avec la modification pour tout convertir en webp lorsque les JPEG sont chargés.
Au cours de la réunion de l'équipe de performance d'aujourd'hui, les contributeurs ont brièvement discuté de la restauration.
Nous essayons toujours de comprendre ce qu'est exactement un plug-in canonique et s'il fonctionne par défaut pour WebP, a déclaré Adam Silverstein, sous-traitant principal sponsorisé par Google. Nous avons encore quelques correctifs à corriger pour la version 6.1 sur la qualité de l'image lors de la sortie des WebP (ce qui est toujours une option, donc seul un plug-in est nécessaire pour l'instant).
Lors de la précédente réunion de l'équipe Performance, Silverstein a déclaré que le message de Mullenweg sur la fonctionnalité qui n'avait pas été achetée avait été une surprise pour l'équipe et qu'ils travaillaient avec les résultats de la publication pour mieux comprendre les préoccupations dans l'espoir de trouver une voie vers suivre.
Je tiens à reconnaître que c'est un coup dur pour tous ceux qui ont travaillé sur la fonction (moi y compris) et en même temps, je voudrais nous encourager à nous concentrer sur la façon dont nous pouvons aller de l'avant compte tenu de l'emplacement actuel. Y a-t-il des préoccupations que nous pouvons résoudre ? Un plugin canonique a-t-il un sens ?
dit Silverstein.
Les participants à cette discussion ont exprimé leur inquiétude quant au fait que les utilisateurs adopteront WebP par défaut s'il est déplacé vers leur propre plugin. Cela nécessiterait un changement de marque stratégique pour indiquer qu'il fournit des images plus rapides, car la plupart des utilisateurs ne seront pas familiarisés avec le format WebP.
Je pense que s'il reste un "projet de fonctionnalité", il est logique de rester dans le plugin Performance Lab : nous ne savons pas si le retirer nous prendrait plus de testeurs (d'autant plus que le plugin Performance Lab a 10k + installations qui c'est beaucoup pour un plug-in de fonctionnalité)
a déclaré Felix Arntz, un contributeur sponsorisé par Google.
Si nous devions suivre la voie d'un "plug-in canonique", nous devrions bien sûr le supprimer, mais la nature du projet changerait également
Les contributeurs décideront des prochaines étapes pour la fonctionnalité lors de discussions futures. Pour l'instant, les utilisateurs qui attendaient avec impatience de charger WebP par défaut peuvent toujours obtenir cette fonctionnalité en utilisant le plugin Laboratoire de performance , géré par l'équipe de performance WordPress.
Donc, si vous attendez la sortie officielle du support Webp dans WordPress, vous pouvez décider d'attendre encore un peu ou de commencer l'implémentation avec des plugins alternatifs comme nous l'avons déjà expliqué dans ce post : Diminuer le poids d'un site web grâce à l'utilisation d'images WebP
