L'économiseur de données de Chrome en version finale sur Mac

Stéphane Moussie |

Lancée l'année dernière en bêta, l'extension Économiseur de données de Chrome est désormais disponible en version finale sur Mac. Comme sur mobile, cette extension réduit la consommation de data en faisant transiter toutes les pages web par les serveurs de Google qui se chargent de les compresser avant de les afficher. Il y a une exception pour les sites sécurisés (HTTPS) et les pages en mode de navigation privée.

Les images sont notamment converties en WebP, le format très optimisé de Google. Sur un site comme celui d'Apple qui utilise beaucoup d'images, on économise ainsi beaucoup de données. Ceux qui ont un bon œil remarqueront néanmoins la compression assez forte.

La version finale de l'extension propose un historique allant jusqu'à 60 jours et indiquant l'économie réalisée pour chaque site. L'extension permet d'économiser pas moins de 4,4 Mo sur 6,2 lors d'un petit tour sur le site d'Apple.

avatar Novezan | 

Google dépendant !!!!

avatar lmouillart | 

Pour ceux qui n'aiment pas les produits Google, Opera propose le même type de proxy compressant (qui sont encore plus performant) dans les siens. Ces outils sont bien pratiques en utilisation sur des bornes wifi publiques ou sur des connexions mobiles de faible qualité.

avatar joneskind | 

@lmouillart

J'utilise aussi les solutions d'Opera quand je suis en partage de connexion (Vivaldi sur Mac) mais je ne suis pas certain que ce soit beaucoup mieux que Google ^_^.

Il est quand même temps de remplacer ce bon vieux Jpg !

Dans un monde idéal, les navigateurs se mettraient d'accord pour supporter le même nouveau format d'image et les hébergeurs du monde entier se chargeraient de convertir les jpg au nouveau format. Il serait inutile de modifier l'extension en .jpg des fichiers compressés avec ce nouveau codec et tout serait simple et tranquille.

PS : Ce qui est triste c'est que Google ne développe pas d'extension Safari pour supporter le WebP...

avatar lmouillart | 

Pour cela il y a le webp : https://developers.google.com/speed/webp/
Comme souvent et comme nous en avons tous discutés sur la news relative aux spécificités de constructeurs à la webkit, pour webp c'est l'initiative d'un seul constructeur : Google.
Ce format est déjà supporté dans de nombreux outils, et par les navigateurs et moteurs les plus utilisés si l'on considère l'ensemble des plateformes. Malheureusement, ce n'est ni suivi par Apple, ni par Microsoft, on en revient donc à la nécessité de s'accorder sur un socle commun.

Actuellement Google fonctionne en proposant les deux formats : quand le navigateur gère les spécificités avancées des technologies Google (HTTP2, webp, vp9), elles sont utilisées, quand on est sur un navigateur "legacy", les anciennes technologies moins efficientes sont utilisées (HTTP, jpeg, h254, ...)

avatar Mrleblanc101 | 

@lmouillart :
WebKit est l'initiative de Apple... Pas Google !

avatar lmouillart | 

La phrase que j'ai écrite c'est webp est à l'initiative d'un constructeur, tout comme webkit est à l'initiative d'un constructeur et pour webp c'était Google. Je modifie pour rendre plus clair.

avatar lmouillart | 

La bibliothèque pour sa gestion dans OS X existe (binaire + sources sous licence BSD).
Le code pour sa gestion dans webkit existe il est juste désactivé par Apple lors de l'intégration dans ses produits.
Concernant un plug-in pour Safari, les discussions dans la nouvelle sur la disparition de Flash Player, et celle sur la disparition du plug-in Java montrent que ce n'est pas une voie vers laquelle il faut aller.

"les hébergeurs du monde entier se chargeraient de convertir les jpg au nouveau format."
Attention le jpg est un format à perte, et bien qu'il existe pour webp une option pour faire une compression sans perte, l'option le mettant en remplaçant du jpeg est avec pertes. Donc, convertir à l'arrache du jpeg en webp donne une qualité moindre et donc des artéfacts comme lors de l'utilisation de l'économiseur de donnés de Google.

"Dans un monde idéal, les navigateurs se mettraient d'accord pour supporter le même nouveau format d'image ", oui avec des arbitres : c'est ce a quoi sert le w3c et d'autres.

avatar joneskind | 

@lmouillart

"Concernant un plug-in pour Safari, les discussions dans la nouvelle sur la disparition de Flash Player, et celle sur la disparition du plug-in Java montrent que ce n'est pas une voie vers laquelle il faut aller."

Je ne parle pas d'un plugin mais bien d'une extension !

"Attention le jpg est un format à perte, et bien qu'il existe pour webp une option pour faire une compression sans perte, l'option le mettant en remplaçant du jpeg est avec pertes. Donc, convertir à l'arrache du jpeg en webp donne une qualité moindre et donc des artéfacts comme lors de l'utilisation de l'économiseur de donnés de Google."

Oui. Je connais bien ces phénomènes. Mais il y a quand même une certaine marge d'action sans trop détériorer le fichier original.

Mais pour en revenir aux formats proposés par Google, même si je salue l'initiative, le problème est qu'ils ne sont pas au niveau du H.264 et H.265 pour le WebM, et que le gain apporté par le WebP n'a jamais été suffisant pour justifier de mettre en route le changement. Il n'y a pas si longtemps, MacGé publiait un article à propos d'un développeur qui avait fait un nouveau format d'image prenant en compte la couche Alpha et basé sur le codec H.265 et qui lui offrait un réel gain par rapport au jpg.

avatar Nicolas R. | 

Les discussions que je peux lire sont très intéressantes... cela dit pour en revenir au sujet qui nous intéresse à présent, c'est-à-dire cette extension, je suis plus que mitigé eu égard à son installation.

Je l'ai utilisé pendant des mois. Me suis rendu compte qu'en moyenne j'avais gagné 20% de bande passante.
Seulement, certains players bogguent (impossible à lancer sans désactiver le plugin) et de simples pages (Allociné) ont un rendu très anarchique (un css/js qui foire).
Comme jongler étant ennuyeux, j'ai fini par la désinstaller tout bonnement. Je l'essaye à nouveau pour voir si cela a été corrigé

avatar lmouillart | 

Elle passe par un proxy donc certaines ressources, ou leur accès est modifié. Sur certains sites ça bloque, ou sur certaines fonctionnalités (détail ici : https://goo.gl/YvQogG)

Sur mobile je l'ai toujours d'activé, sans trop de souçis.
Sur desktop, uniquement en cas de condition très dégradée.

L'avantage de fonctionnement d'Opera sur celui de Chrome est qu'il est possible de compresser encore plus (très utile avec une connexion très mauvaise : edge ou intermittente), et que l'accès aux ressources se fait via socket et non plus par http, on gagne l'overhead due au http, et on évite de faire x requêtes.

avatar simnico971 | 

Intérêt assez limité vu que de plus en plus de sites sont en https, notamment Facebook (et tant mieux).

avatar C1rc3@0rc | 

Qu'importe de passer par Google/ Opera/ machin, cela implique de passer par un proxy qui va alterer les donnees. A partir de la on ne peut plus avoir confiance dans ce qui transite et qui s'affiche.

Il faut aussi rappeler que ces passages par ces proxy va augmenter la charge du Net (on double les requetes au minimum), ralentit le transit (les paquets doivent etre tous receptionnés une 1ere fois, puis reexpediés) et desiquilibre la charge sur le Net...

De plus le gain semble peut important.

Le jour ou un proxy voudra vraiment alléger le contenu, il débarrassera les pages de la publicité, et on aura des "allègements" de plus de 100%!

avatar lmouillart | 

Flywheel, le proxy compresseur de données fait aussi office de cache. Donc un certain nombres de ressources sont mutualisées entre les utilisateurs. Le nombre de requêtes est donc plus faible, ainsi que la charge du coté du serveur cible.

Il y a un papier assez détaillé mais très accessible qui décrit le fonctionnement de ce proxy : http://goo.gl/5Yeb81

"Qu'importe de passer par Google/ Opera/ machin, cela implique de passer par un proxy qui va alterer les donnees."
Oui c'est l'objectif
"A partir de la on ne peut plus avoir confiance dans ce qui transite et qui s'affiche."
Oui et non, si vous utilisez déjà un produit Google, il n'y a pas plus de raisons, ni moins d'avoir confiance en ce produit qu'en un autre. On est dans une problématique similaire avec n'importe quel CDN, et même en https.

avatar iPeP (non vérifié) | 

Quand on a un site ou un blog à optimiser, c'est le type de nouvelle qui laisse perplexe...

Cela fait plusieurs années que Google et autres poussent à la roue pour que tout soit optimisé, compressé, calibré. La grande obsession est la vitesse du site. De temps de réponse du DNS et de la rapidité à charger dépend une grande partie de l'évaluation de votre site par Google (le pagespeed qui rentre en compte dans le pagerank). Pour répondre à ça, on minify, on GZIP, il faut utiliser des caches, des CDN etc...
Depuis 2 ans, la mode est au HTTPS. On nous dit qu'il devient obligatoire, qu'il va participer à l'évaluation etc...
Et puis tout d'un coup, notre amis Google balance des caches qui font tout, sauf pour le HTTPS (ce qui normal d'un point de vue sécurité)... et là, quand tu regarde le temps et l'investissement pour répondre à ces foutue exigences, tu as un grand moment de solitude et tu te dis qu'il y a un truc...

avatar arno75011 | 

Bonsoir ok pour les DATA économisés mais est ce que ça va plus vite ? je suis en fibre illimité donc je pense que l'économie des datas ne sont pas mon problème

CONNEXION UTILISATEUR