Chrome Lite Pages, c’est cette fonctionnalité du navigateur de Google qui permet de réécrire le code des pages sur Android, pour rendre leur chargement rapide en cas de contrainte réseau, et ce même pour les pages en HTTPS. Evidemment, nous apprécions les initiatives pour que le web soit plus rapide, nous sommes aussi attachés à un web neutre, et Chrome Lite Pages fait émerger quelques interrogations qui, elles, ne le sont pas.
De Data Saver à Chrome Lite Pages
Jusqu’à présent, Chrome proposait d’optimiser les pages en HTTP en cas de connexion mobile lente pour économiser de la bande passante, des données, de l’argent, du temps… grâce à sa fonctionnalité Data Saver.
Les pages web peuvent ainsi se charger jusqu’à 2 fois plus vite tout en économisant jusqu’à 90 % de données.
Lorsque cette fonctionnalité opère, une icône apparaît dans la barre d’URL, et l’utilisateur.rice peut basculer en version originale en cliquant dessus (si cette action est répétée, Chrome le détecte et désactive l’option).
Data Saver peut aussi être émulé dans le cadre d’une connexion normale depuis les paramètres de Chrome.
Dorénavant, la dernière version de Chrome pour Android qui supporte Chrome Lite Pages permet son exécution non seulement sur des pages en HTTP (comme le faisait Data Saver, donc), mais aussi en HTTPS.
Les optimisations dépendent entre autres de la connexion, de la zone géographique et du code de la page (le fonctionnement de Chrome Lite Pages est détaillé ici). Seule l'URL est partagée avec Google mais pas les autres informations telles que les cookies, les données d’identification ou de personnalisation (ce point a été clarifié sur Twitter par des ingénieurs Google dans un thread). La page est “simplement” téléchargée sur les serveurs de Google pour être réécrite - sauf pour les pages dont l’en-tête HTTP contient la balise no-transform, ce qui empêche la réécriture. A bon entendeur.se…
Optimizations include smarter server-side pre-rendering and prioritizing critical sub-resources on the page, but they vary based on quite a few factors (region, how the page is rendered, etc...).
— Houssein Djirdeh (@hdjirdeh) March 12, 2019
Yep kind of. An internal redirect is made to our servers that fetches the original page and optimizes content where possible, so any cookies scoped to the origin is never sent to Google.
— Houssein Djirdeh (@hdjirdeh) March 13, 2019
Quant aux optimisations de Chrome Lite Pages depuis Chrome 72 (c’est-à-dire maintenant), elles sont approfondies ici et portent sur :
- le remplacement des images
- la désactivation de scripts
- la prévisualisation offline
- le téléchargement des ressources critiques uniquement.
Elles sont appliquées en cas de connexion 2G ou “slow-2G”, ou quand, en fonction des capacités du mobile, le First Contentful Paint observé sur la page est supérieur à 5 secondes. En théorie, peu de pages sont concernées.
En termes d’amélioration des performances web, les temps de chargement sont réduits, sur ce point les objectifs sont atteints. Mais notons que la réécriture du code se fait sans consultation ni accord préalable de l’éditeur du contenu. Et comme nous le soulignions en début d'article, ce procédé - qui plus est pour des pages HTTPS - nous interroge sur le plan éthique.
De la neutralité du navigateur et du web en général
Ce principe de réécriture du code sans consentement de l’éditeur nous a rappelé l’initiative de SFR quelques années plus tôt. L’opérateur dégradait le contenu de pages web afin qu’elles se chargent plus rapidement pour donner l'impression que le réseau SFR était plus performant que ses concurrents. Tollé à l’époque, l’opérateur s’est vu accusé d’entrave à la neutralité du net.
Le principe même de la réécriture du code pour optimiser les temps de chargement n’est pourtant pas à remettre cause, c’est d’ailleurs ce que fait Fasterize. Mais l’immense différence, c’est que cela se fait avec l’accord de l'éditeur du contenu qui consent à cette réécriture pour appliquer des optimisations sur son site, tout en gardant la main sur son contenu. Il peut aussi décider de les interrompre quand bon lui semble.
C’est donc sur le sujet de la neutralité du net que nous nous sommes questionnés à propos de Chrome Lite Pages (et nous ne somme pas les seuls, un exemple ici dans ce billet publié par Tim Kadlec) : est-ce le rôle d’un navigateur de modifier le code d’une page ? Est-ce le rôle de Google de prendre la main sur le contenu de sites, quelles que soient les conditions ?
Si l’initiative part a priori d’une bonne intention, n’oublions pas que l’enfer en est pavé.
Vous souhaitez suivre nos actualités webperf, techniques, e-commerce…
Abonnez-vous à notre newsletter :
