Le mois dernier, le projet de WordPress de générer par défaut des images WebP pour les nouvelles images JPEG importées a été suspendu pour la prochaine version 6.1 suite aux objections des développeurs principaux. La proposition initiale avait été intégrée au noyau fin juillet, malgré de nombreuses critiques et inquiétudes de la part de la communauté de développement WordPress. Hier, la fonctionnalité a été réintégrée suite à la récente publication de Matt Mullenweg concernant son retrait du noyau au profit d'un développement en tant qu'extension officielle.
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 concernant cette fonctionnalité lors de discussions ultérieures. En attendant, les utilisateurs qui souhaitaient que le format WebP soit chargé par défaut peuvent toujours bénéficier de cette fonctionnalité grâce à l' extension Performance Lab , maintenue par l'équipe de performance WordPress.
Si vous attendez la sortie officielle de la prise en charge de WebP dans WordPress, vous pouvez patienter encore un peu ou commencer l'implémentation avec des plugins alternatifs, comme nous l'avons déjà expliqué dans cet article : Réduire le poids d'un site web grâce aux images WebP