La conversion en WebP arrivera-t-elle avec WordPress 6.0 ?

Une équipe de contributeurs dédiée à la performance s’est constituée en octobre dernier, notamment autour de personnes « sponsorisées » par Google. Vous verrez, ça a son importance.

Leur mission est d’améliorer les performances natives de WordPress afin que les 43% des sites web qui utilisent notre CMS soient plus rapides ; sans action particulière de la part des webmasters.

Et quels sont les éléments qui pèsent le plus lourd dans une page ?
Les images.

WordPress fait déjà un beau travail

Mais nous avons déjà des systèmes intéressants en place, notamment le srcset.

Par exemple (et on va simplifier les choses), si quelqu’un visite un site depuis un mobile, on lui servira une image en taille « moyenne » et non l’image originale, bien plus lourde.

D’ailleurs si on envoie une image trop grande, WordPress va la redimensionner avec 2560px de largeur maximale en ajoutant -scaled au nom de fichier.

Avec ces deux mesures :

• On affiche des versions redimensionnées plus légères sur mobile ;
• Et on évite des images trop lourdes pour les grands écrans.

Mais on peut aller plus loin, c’est d’ailleurs pour cela que l’on utilise des extensions de compression d’images !

Nous avons d’ailleurs nos chouchous : TinyPNG en extension majoritairement gratuite et Imagify si l’on souhaite aller plus loin avec des forfaits payants.

Regardons ce qui se fait ailleurs

Sauf que tous les webmasters ne mettent pas en place de telles solutions et c’est pour cela que les sites WordPress sont majoritairement plus « lents » que ceux qui sont conçus avec Wix ou Shopify par exemple.

En effet, ces plateformes ont déjà mis en place tout ce qu’il faut pour convertir les images en WebP et les servir aux navigateurs compatibles depuis des années.

Alors pourquoi ne pas faire de même pour WordPress ?
Pourquoi ne pas les suivre et imposer une politique unique pour tout le monde ?

Eh bien parce que les conséquences individuelles sont différentes dans un écosystème open-source.

On ne peut pas prendre une décision avec autant de répercutions quand on s’appelle WordPress.

A contrario, le problème ne se pose pas pour les plateformes propriétaires qui maîtrisent leurs technologies, leurs serveurs et leurs tarifs.

La levée de bouclier n’a pas tardé

Adam Silverstein, porte-parole de l’équipe Performance, a publié le 29 mars la proposition d’adopter le WebP par défaut dans le cadre de WordPress 6.0.

Le but est donc d’avoir en doublon toutes les tailles d’images en JPG et en WebP afin de les servir aux navigateurs compatibles sans casser la rétro-compatibilité non plus.

Mais les réactions ont afflué peu de temps après : elles ont tantôt douté de l’implémentation, tantôt refusé purement et simplement la trajectoire qui était annoncée.

Et le premier point de blocage est la conséquence de la politique de WordPress « Decisions, not options ». C’est à dire que si une majorité d’utilisateurs tireront profit d’une fonctionnalité donnée, autant l’imposer à tous… sans aucune option dans l’interface.

Et c’est ce qui est prévu pour le moment : ce serait activé par défaut pour tout le monde.

Or c’est une proposition relativement « autoritaire » appliquée à une multitude de cas individuels qui n’ont pas les mêmes problématiques en termes d’hébergement, de sauvegardes ou de qualité d’image.

Sans compter les webmasters qui ont déjà pris la peine de configurer des processus d’optimisation d’images et qui devraient potentiellement revoir leurs assemblages s’ils ne sont plus pertinents.

Pourquoi ça ne passe pas ?

Cette décision est donc vue d’un mauvais œil parce qu’elle semble être prise par une poignée de contributeurs qui ont des intérêts collectifs en tête :

• Une comparaison excessive à des plateformes propriétaires qui ont plus de facilité à faire de gros changements sur leurs infrastructures ;
• Et peut-être aussi des envies d’économies pour Google ? En effet, si les pages sont moins lourdes, les robots consommeront moins de ressources à explorer le web.

On sent ainsi un potentiel conflit d’intérêt puisque la plupart des contributeurs de cette équipe Performance sont payés par Google. Ça n’aide clairement pas à faire passer la pilule.

Donc en l’état, avec une telle opposition, il y a fort à parier que la proposition actuelle ne pourra pas voir le jour à l’occasion de WordPress 6.0.

Les contributeurs vont devoir revoir leur copie et mettre de l’eau dans leur vin pour que la conversion en WebP arrive dans le cœur de WordPress.

🤔 On surveille la suite de ce feuilleton pour mettre à jour la partie Performance de notre formation WordPress en conséquence.