Depuis http2, tu multiplexe les requêtes dans une même connexion tout ça donc ça ne sert à rien d'essayer d'économiser les ouvertures de connexion tcp.
C'est vrai que j'en suis resté surtout à HTTP/1.1. HTTP/2 règle une bonne partie de ce problème. Il va falloir que je me mette à jour.
Cependant si tu regardes la page Patréon que j'ai mentionné (il faut être logué ; j'ai constaté ça seulement après mon 1er commentaire), tu as du javascript qui charge des bouts de pages, qui charge du javascript, etc. HTTP/2 ne peut pas faire grand chose pour optimiser ça.
il faut prendre en compte quelques petites choses ta combinaison n'augmente pas trop le volume
En compression JPEG, les espaces vides dans une image ont une taille négligeable. Par contre c'est vrai qu'une fois décompressé en mémoire, c'est à prendre en compte.
la gestion du cache qui n'est pas forcément la même pour chacun
On parle ici d'image qui ne changent que très rarement (thème, etc). Ça me semble négligeable comme problème.
tu empêche les affichages progressif
C'est vrai. Mais ce problème peut être atténué en utilisant l'entrelacement.
Ta thèse c'est que les développeurs font n'importe quoi et ne cherche plus à bien faire tout en expliquant qu'ils en subissent les effets (tu as aussi le fait que le référencement prends en compte les temps de chargement).
Ils n'en subissent pas forcément les effets.
Dans mon exemple de Patréon, il s'agit des pages quand on est loggué. Quand on est pas loggué (--> ce qu'indexe les moteurs de recherche), les pages sont considérablement plus simples et chargent très vite. Donc ça n'embête que les utilisateurs. Ça réduit peut-être l'activité sur le site, mais ça ne réduit visiblement pas le salaire des développeurs.
Dans le cas d'un site web pour la boulangerie du coin, la société de prestation qui le fait cherche à faire un site "joli" (seul vrai critère du client), et se tape du reste.
Tout ça pour dire que prendre une métrique sans vraiment se poser la question de sa pertinence pour sortir des jugements
Dans le cadre de mon exemple (Patréon), je maintiens que cette métrique est pertinente. Par contre, je reconnais que dans le cas d'un site (presque) statique pour un festival, en HTTP/2, cette métrique n'a plus forcément de sens.
Tu considère que la population des développeurs sont des imbéciles incapables de se rendre compte de ce que toi tu vois ?
Pas tous.
Quand il s'agit de faire de la merde, certains ont une imagination sans fin (vécu). Il y en aussi beaucoup qui en font par manque de moyens ou de temps. Certains en font parce-que leur employeur ne leur laisse aucune flexibilité et les oblige à utiliser des méthodes de travail qui ont 20 ans de retard.
Après 10 ans de carrière, je peux dire que j'ai vu beaucoup trop d'atrocités et que plus rien ne me surprend. Vu tout les commentaires ici, je ne suis pas le seul.
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue.... Évalué à 2.
C'est vrai que j'en suis resté surtout à HTTP/1.1. HTTP/2 règle une bonne partie de ce problème. Il va falloir que je me mette à jour.
Cependant si tu regardes la page Patréon que j'ai mentionné (il faut être logué ; j'ai constaté ça seulement après mon 1er commentaire), tu as du javascript qui charge des bouts de pages, qui charge du javascript, etc. HTTP/2 ne peut pas faire grand chose pour optimiser ça.
En compression JPEG, les espaces vides dans une image ont une taille négligeable. Par contre c'est vrai qu'une fois décompressé en mémoire, c'est à prendre en compte.
On parle ici d'image qui ne changent que très rarement (thème, etc). Ça me semble négligeable comme problème.
C'est vrai. Mais ce problème peut être atténué en utilisant l'entrelacement.
Ils n'en subissent pas forcément les effets.
Dans mon exemple de Patréon, il s'agit des pages quand on est loggué. Quand on est pas loggué (--> ce qu'indexe les moteurs de recherche), les pages sont considérablement plus simples et chargent très vite. Donc ça n'embête que les utilisateurs. Ça réduit peut-être l'activité sur le site, mais ça ne réduit visiblement pas le salaire des développeurs.
Dans le cas d'un site web pour la boulangerie du coin, la société de prestation qui le fait cherche à faire un site "joli" (seul vrai critère du client), et se tape du reste.
Dans le cadre de mon exemple (Patréon), je maintiens que cette métrique est pertinente. Par contre, je reconnais que dans le cas d'un site (presque) statique pour un festival, en HTTP/2, cette métrique n'a plus forcément de sens.
Pas tous.
Quand il s'agit de faire de la merde, certains ont une imagination sans fin (vécu). Il y en aussi beaucoup qui en font par manque de moyens ou de temps. Certains en font parce-que leur employeur ne leur laisse aucune flexibilité et les oblige à utiliser des méthodes de travail qui ont 20 ans de retard.
Après 10 ans de carrière, je peux dire que j'ai vu beaucoup trop d'atrocités et que plus rien ne me surprend. Vu tout les commentaires ici, je ne suis pas le seul.