GithubHelp home page GithubHelp logo

Modification BP #80 about best-practices HOT 4 CLOSED

cnumr avatar cnumr commented on August 11, 2024
Modification BP #80

from best-practices.

Comments (4)

tbroyer avatar tbroyer commented on August 11, 2024 2

Mais je suis moyennement d'accord pour parler de AVIF et surtout WebP qui sont des formats propriétaires.

Google (pour WebP) et Alliance for Open Media (pour AVIF) ont tous deux mis le code des codecs sous license BSD (une des licenses open source les plus "permissives") avec une “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) patent license”.
Donc même s'ils sont développés par des entreprises privées, ce sont des "formats ouverts", et pas vraiment ce qu'on pourrait appeler des "formats propriétaires". YMMV.

Quid de la lecture du site par des versions de navigateurs avant 2018 ? (ce n'est pas si vieux)

Fournir un format alternatif?

Quid de la durabilité du site si Google décide d’arrêter le WebP ?

Quid si Mozilla (au pif) décide d'arrêter de supporter les GIF dans Firefox ? (ou MP4, you name it)
(on parle bien ici de supprimer le support du format d'un navigateur web ? cf. note sur le licensing ci-dessus, même si Google faisait machine arrière sur le licensing, ça n'empêcherait pas les autres navigateurs d'intégrer le codec)

De plus, le client final qui va mettre à jour son contenu, va rarement faire du WebP, mais basiquement du JPG. Donc ne vaut-il pas mieux insister sur les façons d'optimiser le JPG ?

Why not both?

from best-practices.

florinesueur avatar florinesueur commented on August 11, 2024 2

Format alternatif :

<picture>
        <source srcset="image.webp" type="image/webp">
        <img src="image.jpg" alt="" loading="lazy">
 </picture>

De plus, le client final qui va mettre à jour son contenu, va rarement faire du WebP, mais basiquement du JPG. Donc ne vaut-il pas mieux insister sur les façons d'optimiser le JPG ?

J'ai l'impression qu'il faut un livre des BP uniquement sur l'éducation des clients finaux et utilisateurs.

from best-practices.

LaFelixe avatar LaFelixe commented on August 11, 2024

Pas compris si je pouvais intervenir dans l'issue ....
Mais je suis moyennement d'accord pour parler de AVIF et surtout WebP qui sont des formats propriétaires. Quid de la lecture du site par des versions de navigateurs avant 2018 ? (ce n'est pas si vieux) Quid de la durabilité du site si Google décide d’arrêter le WebP ? Ou alors faire mentions de cette contrainte.
De plus, le client final qui va mettre à jour son contenu, va rarement faire du WebP, mais basiquement du JPG. Donc ne vaut-il pas mieux insister sur les façons d'optimiser le JPG ?

from best-practices.

DocRoms avatar DocRoms commented on August 11, 2024

Pas compris si je pouvais intervenir dans l'issue .... Mais je suis moyennement d'accord pour parler de AVIF et surtout WebP qui sont des formats propriétaires. Quid de la lecture du site par des versions de navigateurs avant 2018 ? (ce n'est pas si vieux) Quid de la durabilité du site si Google décide d’arrêter le WebP ? Ou alors faire mentions de cette contrainte. De plus, le client final qui va mettre à jour son contenu, va rarement faire du WebP, mais basiquement du JPG. Donc ne vaut-il pas mieux insister sur les façons d'optimiser le JPG ?

Comme le dit très bien @tbroyer les formats ne sont pas propriétaires . Mais de toutes manières, propriétaire ou pas, on ne peut pas faire l'impasse sur ce genre de format aujourd'hui, on y gagne vraiment beaucoup en réduction de poids de ressources... et de poids de pages.

Il est possible évidement d'utiliser plusieurs types d'images différents comme l'a très bien montré @florinesueur , mais on a également la possibilité d'envoyer des images différentes à des clients différents grâce aux headers des requêtes qui sont fournis au serveur. Le module modPageSpeed de Google le fait très bien :
- Je suis compatible webp : j'envoie un DOM avec du WebP
- Je ne suis pas compatible webp, j'envoie l'image "normale" ;)

L'intérêt est double, vu que l'on ne renvoie que l'image qu'il faut dans le DOM, et que l'image renvoyée est optimisée par rapport à ce que supporte le navigateur ;)

Aujourd'hui, les sites sont principalement lourd à cause des vidéos, des images, puis du JS... On doit trouver toutes les solutions pour réduire drastiquement le poids des pages sur les terminaux clients. Insister le JPG, qui est un format que l'on peut très facilement réduire de 30 à 80% n'est , pour moi, pas la meilleure façon de rendre tout ça plus sobre :)

(Désolé, je répond bien après ^^ )

from best-practices.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.