Petit Hack -> webp

Bonjour,

Ayant converti les images d’un site de jpg et png vers webp je me pose la question de savoir s’il y aurait des conséquences néfaste si je lance une requête sql (SELECT UPDATE) sur la table spip_documents pour modifier les noms de documents jpg/xxx.jpg et png/yyy.png en webp/xxx.webp et webp/yyy.webp en mettant le type de doc à webp.

J’ai déjà fait quelques tests à la mano et ça a l’air d’être OK. Mais on ne sait jamais…

Si quelqu’un a déjà fait la manip, un retour serait bienvenu.

Bernard

Je me réponds à moi-même.
En fait j’ai fait la manip juste avec des UPDATE et des REPLACE sur la table spip_documents et tout s’est bien passé.
La seule chose c’est que les tailles des documents ne sont pas mises à jour. Ça serait facile à faire en utilisant la sortie d’un ls sur le dossier webp et lancer une série d’UPDATE.
Ce n’est pas pénalisant les images s’affichent correctement et leur poids a été divisé par deux sans perte de qualité visible. Ça c’est pour les jpg, Pour les png le gain va être nettement supérieur.
Si depuis la fiche article on ouvre la fiche document la taille du fichier est recalculée et SPIP demande d’enregistrer la modification.

Bernard

C’est intéressant et ça mériterait un article sur contrib, ou au moins des notes sur le carnet wiki de contrib, avec les scripts ou les commandes shell utilisées…

Merci. Je vais préparer ça au plus simple. Je le mets en ligne dès que j’ai un moment.
BF.

Pour info, il y a 2 plugins de gestion des images « responsives » qui les génèrent automatiquement et proprement (iOS ne gère pas les webp avant une certaine version) :

Pour « responsive » je sais pas, mais le plugins « adaptive », qui procure une qualité de rendu des images dans toutes les configurations d’écran, ne répond au même besoin que la conversion des images en webp.
Convertir une fois pour toutes les images de JPG à WEBP ne se fait qu’une fois et permet de diviser la taille des documents, la charge pour le serveur à l’avenir, les temps de chargements. Avec ces images, le fonctionnement du site ne change pas, le HTML est le même qu’un spip de base, tout simple et sans hack css ou js.
Avec « Adaptive », le serveur multiplie au contraire les images pour en présenter une sur mesure pour les différentes configurations d’écran. Il y a 5 seuils de taille d’écran par défaut et donc, environ 5 versions différentes du document sont créées dans /local/. Je connais pas bien le fonctionnement ; ça doit dépendre de la taille de l’image par rapport à ces seuils aussi mais dans mon expérience, sur un petit site, le volume d’image résultant devient très important : pour 17Mo d’images fournies, « adaptive » en produit (en plus) 73 Mo dans /local/adpt-img, ce qui fait qu’au total le volume d’image est de 90Mo (sans parler de celles dans cache-gd2).
[EDIT] après vérification en vidant d’abord le dossier adapt-img, je vois que les images sont dupliquées en 31 endroits dans autant de sous-dossiers différents. Pfffiou

Alors qu’en convertissant les images présentes en webp, les 17Mo d’images deviennent seulement 10Mo tout compris.

1 « J'aime »

Attention, on a fait la même chose pour faire passer plusieurs centaines
de vidéos dans des formats anciens en MP4.

A priori tout avait l’air de fonctionner, mais au fur et à mesure on y
découvre des incompatibilités. Il y a des vidéos qui ne sont pas
correctement affichés, il y en a qui démarrent automatiquement et
simultanément quand elles se trouvent sur la même page d’article, etc.

On a fini par faire des uploads manuels pour un belle quantité de vidéos
plus ou moins défectueux après la manip initiale.

Donc, pour les image c’est peut-être une bonne idée, pour les formats
plus exigeants il vaudrait mieux écrire un plugin qui respecte les
traitements propres à SPIP.

:-)k++

On 10.12.21 11:52, JLuc via Discuter de SPIP wrote:

C’est intéressant et ça mériterait un article sur contrib, ou au moins des notes sur le carnet wiki de contrib, avec les scripts ou les commandes shell utilisées…


Voir le sujet ou répondre à ce courriel pour répondre.

Pour se désabonner de ces courriels, cliquez ici.

C’est surtout le transfert de données qui est écologiquement couteux : une fois les fichiers générés sur l’hébergement, au delà de la taille de l’hébergement, ça ne coûte pas grand chose. Donc ce n’est pas tant les 90Mo qu’il faut prendre en compte mais les Mo effectivement transférés à chaque affichage de la page.
Il y a 3 possibilités :

  • envoyer la même image à la taille d’affichage x1 à tout le monde > moindre qualité d’affichage sur les écrans HD (la majorité ?)
  • envoyer la même grande image à tout le monde, même aux petits écrans > coût de transfert élevé même si pas HD
  • utiliser un plugin qui gère automatiquement tous les cas et crée les images selon la densité des écrans (normal ou HD x2, x3…) > plus de fichiers générés mais optimisation du poids transféré pour tous les écrans

Ce n’est pas tant les 90Mo « stocké à froid » qu’il faut prendre en compte mais les Mo effectivement transférés en fonction de tes contraintes d’affichage.

Et c’est à remettre en perspective : le cache fait plus de 300Mo, les hébergements classiques sont dimensionnés en 10aine ou 100aine de Go…

C’est très juste, encore qu’on pourrait ergoter encore sur la démultiplication des caches sur les proxies entre le serveur et le navigateur, mais ça sera compliqué à évaluer.
Plus simplement le site dont je parlais, où il y a 90Mo d’image, est sur un hébergement gratuit où il n’y a que 100Mo théoriquement.
Et sur un autre de mes sites, dont l’hébergement est pas gratuit lui, je suis obligé de temps en temps d’augmenter le forfait « espace disque » car il en manque. Alors s’il me faut multiplier l’espace des images par 4, ça passera pas inaperçu sur la facture.
Donc x4 l’espace disque des images, c’est pas toujours négligeable.

Bonjour à vous,
Je reprends ce post un peu ancien concernant la conversion en .webp. Pas trop familier avec les images, je voulais savoir si vous aviez de (nouveaux) éléments sur le sujet:

  • affichage des images (documents…) en .webp a minima pour les temps de réponse
  • stockage (au téléchargement ou a posteriori) au format .webp au mieux (pour moi)
    Et au-delà des 2 plugins Adaptive images et Images responsive, si un petit nouveau existait car je n’ai pas su en trouver. Un plugin basique n’est peut-être pas si compliqué à écrire avec le bon algo de conversion…
    Merci ! :slight_smile:
    JMarc

Le filtre |image_format permet désormais de générer du webp : Traitement automatisé des images - SPIP
Il y a aussi |image_aplatir - SPIP

Mais je ne sais pas à partir de quelle version de SPIP.

1 « J'aime »

Bonjour
un grand merci !!! je cherchais à générer mes images en webp j’ai essayé des plugings trop compliqués pour moi et là juste un filtre et hop ça marche direct sans plugin ! Trop bien ! Coeur sur toi :slight_smile:

1 « J'aime »