A propos du webp

-  documentation https://www.spip.net/fr_article2002.html

-  on peut ajouter une ligne dans spip_types_documents mais ça ne suffit pas. Voir

-  https://core.spip.net/issues/3958#note-3
-  https://github.com/seenthis/seenthis_squelettes/issues/13#issuecomment-510776860

-  sous spip 3.2 les logos ne sont pas traités comme des documents. On peut dire quels formats sont autorisés en réglant la variable $GLOBALS['formats_logos'] dans mes_options.php
-  a priori sous spip 3.3 ce sera bien le réglage via php my admin qui permettra de faire cela, car les logos seront des document

Les pbs c’est
-  les filtres spip d’images n’acceptent pas le webp -> depuis https://git.spip.net/spip/spip/pulls/85 les filtres SPIP supportent webp
-  Safari (Mac iOs) n’accepte pas webp (cf https://caniuse.com/#search=webp)

Arno* : Je fabrique les WebP dans image_responsive à partir des versions Jpeg (qui restent la norme), ce qui fait qu’ils sont servis dans les sources de . Donc en pratique, je travaille exactement comme avant avec les JPEG, et c’est au niveau es squelettes, avec image_responsive, que les WebP sont fabriqués automatiquement et livrés sous une forme qui fait qu’ils passent nickel sous Chrome et Firefox, et qu’iOS continue avec les JPEG.

<picture style='padding:0;padding-bottom:66.711229946524%' class='conteneur_image_responsive_h'>
  <!--[if IE 9]><video style='display: none;'><![endif]-->
    <source srcset='local/cache-responsive/cache-300/ba9d5372068e77f0f1ccdb99f98fa039.png.webp?1589575322 1x,local/cache-responsive/cache-600/ba9d5372068e77f0f1ccdb99f98fa039.png.webp?1589575322 2x' type='image/webp'>
    <source srcset='local/cache-responsive/cache-300/ba9d5372068e77f0f1ccdb99f98fa039.png?1589575322 1x,local/cache-responsive/cache-600/ba9d5372068e77f0f1ccdb99f98fa039.png?1589575322 2x' type='image/jpeg'>
  <!--[if IE 9]></video><![endif]-->
  <img loading='lazy' lazyload='1' class='image_responsive avec_picturefill' alt='' src='local/cache-responsive/cache-300/ba9d5372068e77f0f1ccdb99f98fa039.png?1589575322' data-src='local/cache-gd2/ef/66e9467473bbb3d76717f4c5ffe7a6.png' data-l='748' data-h='499' data-tailles='[\&#034;300\&#034;]'/>
</picture>

Un détail pas du tout marrant : j’ai un site qui fabrique énormément d’images, et notamment des PNG. Et j’ai constaté que GD2 fabriquait une quantité astronomique de fichiers PNG corrompus. En revanche, le code de GD2 qui fabrique des WepP n’a produit rigoureusement aucune image corrompue. J’ai l’impression qu’il y a une énorme différence de qualité de code entre les deux fonctions…

Avec htaccess

Cam : Une autre solution c’est de proposer le webp aux navigateurs qui l’accepte. Ce que je fais sur mes hébergements dans leur htacess :

RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_URI}  (?i)(.*)(\.jpe?g|\.png)$
RewriteCond %{DOCUMENT_ROOT}%1.webp -f
RewriteRule (?i)(.*)(\.jpe?g|\.png)$ %1%2\.webp [L,T=image/webp,R]

-  Si le navigateur accepte le webp et qu’elle existe on le lui envoie au lieu du png ou jpg. Cela évite de modifier le comportement natif de spip
-  En complément j’ai un script d’optimisation qui génère périodiquement les webp. (dont les versions modifiée par les filtres images). Entre autre je m’appuie sur une version patchée de https://github.com/VirtuBox/img-optimize

----

[WIP] Webp ---- Webp dans la pratique

<BOUCLE_diapo(DOCUMENTS){extension IN jpg,jpeg}{id_article}{par rang_lien}>
[<picture>
	[<source srcset="(#FICHIER|image_aplatir{webp,ffffff,80}|extraire_attribut{src})" type="image/webp">]
	[<source srcset="(#FICHIER)" type="image/jpeg">]
	(#FICHIER|balise_img)
</picture>]
</BOUCLE_diapo>