Proposer des applications rapides et légères avec Save-Data

L'en-tête de requête Save-Data Client-Hint disponible dans les navigateurs Chrome, Opera et Yandex permet aux développeurs de proposer des applications plus légères et plus rapides aux utilisateurs qui activent le mode Économie de données dans leur navigateur.

Nécessité d'avoir des pages légères

Statistiques Weblight

Tout le monde s'accorde à dire que des pages Web plus rapides et plus légères offrent une expérience utilisateur plus satisfaisante, permettent une meilleure compréhension et rétention du contenu, et génèrent plus de conversions et de revenus. Les recherches de Google ont montré que "…les pages optimisées sont chargées quatre fois plus vite que les pages d'origine et utilisent 80 % d'octets en moins. L'accélération de la vitesse de chargement entraîne également une augmentation de 50% du trafic vers ces pages."

Et bien que le nombre de connexions 2G soit enfin en baisse, la 2G était toujours la technologie réseau dominante en 2015. La couverture et la disponibilité des réseaux 3G et 4G augmentent rapidement, mais les coûts de propriété et les contraintes de réseau associés restent un facteur important pour des centaines de millions d'utilisateurs.

Ce sont de bons arguments pour optimiser vos pages.

Il existe d'autres méthodes pour améliorer la vitesse d'un site sans impliquer directement les développeurs, comme les navigateurs proxy et les services de transcodage. Bien que ces services soient très populaires, ils présentent des inconvénients majeurs : compression simple (et parfois inacceptable) des images et du texte, incapacité à traiter les pages sécurisées (HTTPS), optimisation des pages visitées uniquement via un résultat de recherche, etc. La popularité de ces services est en soi un indicateur que les développeurs Web ne répondent pas correctement à la forte demande des utilisateurs pour des applications et des pages rapides et légères. Mais atteindre cet objectif est un chemin complexe et parfois difficile.

En-tête de requête Save-Data

Une technique assez simple consiste à laisser le navigateur vous aider à l'aide de l'en-tête de requête Save-Data. En identifiant cet en-tête, une page Web peut personnaliser et offrir une expérience utilisateur optimisée aux utilisateurs dont les coûts et les performances sont limités.

Les navigateurs compatibles (ci-dessous) permettent à l'utilisateur d'activer un mode d'économie de données qui autorise le navigateur à appliquer un ensemble d'optimisations pour réduire la quantité de données requise pour afficher la page. Lorsque cette fonctionnalité est exposée ou annoncée, le navigateur peut demander des images de résolution inférieure, différer le chargement de certaines ressources ou acheminer les requêtes via un service qui applique d'autres optimisations spécifiques au contenu, telles que la compression des ressources d'image et de texte.

Prise en charge des navigateurs

  • Chrome 49 et versions ultérieures annonce Save-Data lorsque l'utilisateur active l'option "Économiseur de données" sur mobile ou l'extension "Économiseur de données" sur les navigateurs pour ordinateur.
  • Opera 35 et versions ultérieures annonce Save-Data lorsque l'utilisateur active le mode Opera Turbo sur ordinateur ou l'option Économie de données sur les navigateurs Android.
  • Yandex 16.2 et versions ultérieures annonce Save-Data lorsque le mode Turbo est activé sur les navigateurs pour ordinateur ou mobile.

Détecter le paramètre Save-Data

Pour déterminer quand proposer l'expérience "light" à vos utilisateurs, votre application peut rechercher l'en-tête de requête d'indication client Save-Data. Cet en-tête de requête indique la préférence du client pour une utilisation réduite des données en raison de coûts de transfert élevés, de vitesses de connexion lentes ou d'autres raisons.

Lorsque l'utilisateur active le mode Économie de données dans son navigateur, l'application de navigateur ajoute l'en-tête de requête Save-Data à toutes les requêtes sortantes (HTTP et HTTPS). Au moment de la rédaction de cet article, le navigateur ne fait la publicité que d'un seul jeton *on dans l'en-tête (Save-Data: on), mais cela pourra être étendu à l'avenir pour indiquer d'autres préférences utilisateur.

Il est également possible de détecter si Save-Data est activé en JavaScript :

if ('connection' in navigator) {
  if (navigator.connection.saveData === true) {
    // Implement data saving operations here.
  }
}

Il est essentiel de vérifier la présence de l'objet connection dans l'objet navigator, car il représente l'API Network Information, qui n'est implémentée que dans les navigateurs Chrome, Chrome pour Android et Samsung Internet. À partir de là, il vous suffit de vérifier si navigator.connection.saveData est égal à true. Vous pouvez implémenter toutes les opérations d'enregistrement de données dans cette condition.

L'en-tête Save-Data révélé dans les outils pour les développeurs de Chrome, avec l'extension Économiseur de données.
Activation de l'extension Économiseur de données dans Chrome pour ordinateur.

Si votre application utilise un service worker, elle peut inspecter les en-têtes de requête et appliquer la logique appropriée pour optimiser l'expérience. Le serveur peut également rechercher les préférences annoncées dans l'en-tête de requête Save-Data et renvoyer une réponse alternative (balisage différent, images et vidéos plus petites, etc.).

Conseils et bonnes pratiques d'implémentation

  1. Lorsque vous utilisez Save-Data, fournissez des éléments d'interface utilisateur qui le prennent en charge et permettent aux utilisateurs de basculer facilement entre les expériences. Exemple :
    • Informez les utilisateurs que Save-Data est pris en charge et encouragez-les à l'utiliser.
    • Permettez aux utilisateurs d'identifier et de choisir le mode à l'aide d'invites appropriées et de boutons ou de cases à cocher intuitifs pour l'activer ou le désactiver.
    • Lorsque le mode Économie de données est sélectionné, annoncez-le et proposez un moyen simple et évident de le désactiver et de revenir à l'expérience complète si vous le souhaitez.
  2. N'oubliez pas que les applications légères ne sont pas des applications de moindre qualité. Elles n'omettent pas de fonctionnalités ni de données importantes, mais sont simplement plus conscientes des coûts impliqués et de l'expérience utilisateur. Exemple :
    • Une application de galerie photo peut fournir des aperçus de résolution inférieure ou utiliser un mécanisme de carrousel moins lourd en termes de code.
    • Une application de recherche peut renvoyer moins de résultats à la fois, limiter le nombre de résultats contenant de nombreux éléments multimédias ou réduire le nombre de dépendances requises pour afficher la page.
    • Un site axé sur l'actualité peut afficher moins d'articles, omettre les catégories les moins populaires ou fournir des aperçus multimédias plus petits.
  3. Fournissez une logique de serveur pour vérifier l'en-tête de requête Save-Data et envisagez de fournir une réponse de page alternative et plus légère lorsqu'il est activé (par exemple, en réduisant le nombre de ressources et de dépendances requises, en appliquant une compression de ressources plus agressive, etc.).
    • Si vous diffusez une autre réponse en fonction de l'en-tête Save-Data, n'oubliez pas de l'ajouter à la liste Vary (Vary: Save-Data) pour indiquer aux caches en amont qu'ils doivent mettre en cache et diffuser cette version uniquement si l'en-tête de requête Save-Data est présent. Pour en savoir plus, consultez les bonnes pratiques concernant l'interaction avec les caches.
  4. Si vous utilisez un service worker, votre application peut détecter quand l'option d'économie des données est activée en vérifiant la présence de l'en-tête de requête Save-Data ou la valeur de la propriété navigator.connection.saveData. Si cette option est activée, réfléchissez à la possibilité de réécrire la requête pour récupérer moins d'octets ou d'utiliser une réponse déjà récupérée.
  5. Envisagez d'augmenter Save-Data avec d'autres signaux, tels que des informations sur le type et la technologie de connexion de l'utilisateur (voir l'API NetInfo). Par exemple, vous pouvez choisir de proposer l'expérience simplifiée à tous les utilisateurs disposant d'une connexion 2G, même si Save-Data n'est pas activé. À l'inverse, ce n'est pas parce que l'utilisateur dispose d'une connexion 4G "rapide" qu'il n'est pas intéressé par l'économie de données (par exemple, en itinérance). Vous pouvez également augmenter la présence de Save-Data avec l'indication client Device-Memory pour mieux s'adapter aux utilisateurs sur les appareils disposant d'une mémoire limitée. La mémoire de l'appareil de l'utilisateur est également annoncée dans l'indication client navigator.deviceMemory.

Recettes

Les possibilités offertes par Save-Data ne sont limitées que par votre imagination. Pour vous donner une idée de ce qui est possible, examinons quelques cas d'utilisation. En lisant cet article, vous trouverez peut-être d'autres cas d'utilisation. N'hésitez pas à faire des tests pour découvrir ce qui est possible !

Rechercher Save-Data dans le code côté serveur

Bien que l'état Save-Data soit quelque chose que vous pouvez détecter en JavaScript via la propriété navigator.connection.saveData, il est parfois préférable de le détecter côté serveur. Dans certains cas, l'exécution de JavaScript peut échouer. De plus, la détection côté serveur est le seul moyen de modifier le balisage avant qu'il ne soit envoyé au client, ce qui est impliqué dans certains des cas d'utilisation les plus intéressants de Save-Data.

La syntaxe spécifique pour détecter l'en-tête Save-Data dans le code côté serveur dépend du langage utilisé, mais l'idée de base devrait être la même pour n'importe quel backend d'application. En PHP, par exemple, les en-têtes de requête sont stockés dans le tableau superglobal $_SERVER aux index commençant par HTTP_. Cela signifie que vous pouvez détecter l'en-tête Save-Data en vérifiant l'existence et la valeur de la variable $_SERVER["HTTP_SAVE_DATA"] comme suit :

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

Si vous placez cette vérification avant l'envoi de tout balisage au client, la variable $saveData contiendra l'état Save-Data et sera disponible n'importe où sur la page. Maintenant que ce mécanisme est illustré, examinons quelques exemples de la façon dont nous pouvons l'utiliser pour limiter la quantité de données que nous envoyons à l'utilisateur.

Diffuser des images en basse résolution pour des écrans haute résolution

Un cas d'utilisation courant des images sur le Web consiste à diffuser des images par paires : une image pour les écrans"standards" (1x) et une autre deux fois plus grande (2x) pour les écrans haute résolution (par exemple, Retina Display). Cette catégorie d'écrans haute résolution ne se limite pas nécessairement aux appareils haut de gamme et devient de plus en plus courante. Dans les cas où une expérience d'application plus légère est préférable, il peut être judicieux d'envoyer des images de résolution inférieure (1x) à ces écrans, plutôt que des variantes plus grandes (2x). Pour ce faire lorsque l'en-tête Save-Data est présent, nous modifions simplement le balisage que nous envoyons au client :

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}

Ce cas d'utilisation est un exemple parfait de la facilité avec laquelle vous pouvez répondre à une demande spécifique d'un utilisateur qui vous demande de lui envoyer moins de données. Si vous n'aimez pas modifier le balisage sur le backend, vous pouvez également obtenir le même résultat en utilisant un module de réécriture d'URL tel que mod_rewrite d'Apache. Vous trouverez des exemples de la manière d'y parvenir avec une configuration relativement simple.

Vous pouvez également étendre ce concept aux propriétés background-image CSS en ajoutant simplement une classe à l'élément <html> :

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

À partir de là, vous pouvez cibler la classe save-data sur l'élément <html> dans votre CSS pour modifier la façon dont les images sont diffusées. Vous pouvez envoyer des images d'arrière-plan basse résolution sur des écrans haute résolution, comme indiqué dans l'exemple HTML ci-dessus, ou omettre complètement certaines ressources.

Omettre les images non essentielles

Certains contenus d'images sur le Web ne sont tout simplement pas essentiels. Bien que ces images puissent être de bons compléments au contenu, elles ne sont pas souhaitables pour ceux qui essaient de tirer le meilleur parti de leurs forfaits de données limités. Dans ce qui est peut-être le cas d'utilisation le plus simple de Save-Data, nous pouvons utiliser le code de détection PHP précédent et omettre complètement le balisage d'image non essentiel :

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

Cette technique peut avoir un effet prononcé, comme vous pouvez le voir sur la figure ci-dessous :

Comparaison des images non critiques chargées en l&#39;absence de Save-Data et des mêmes images omises en présence de Save-Data.
Comparaison des images non critiques chargées en l'absence de l'en-tête Save-Data et de celles omises en sa présence.

Bien sûr, omettre des images n'est pas la seule possibilité. Vous pouvez également agir sur Save-Data pour éviter d'envoyer d'autres ressources non critiques, telles que certaines typographies.

Omettre les polices Web non essentielles

Bien que les polices Web ne représentent généralement pas une part aussi importante de la charge utile totale d'une page donnée que les images, elles restent très populaires. Elles consomment également une quantité non négligeable de données. De plus, la façon dont les navigateurs récupèrent et affichent les polices est plus complexe que vous ne le pensez. Des concepts tels que FOIT, FOUT et les heuristiques du navigateur font du rendu une opération nuancée.

Il peut donc être judicieux d'exclure les polices Web non essentielles pour les utilisateurs qui souhaitent une expérience utilisateur plus simple. Save-Data rend cette opération relativement simple.

Par exemple, imaginons que vous ayez inclus Fira Sans de Google Fonts sur votre site. Fira Sans est une excellente police pour le corps du texte, mais elle n'est peut-être pas si importante pour les utilisateurs qui essaient d'économiser des données. En ajoutant une classe save-data à l'élément <html> lorsque l'en-tête Save-Data est présent, nous pouvons écrire des styles qui invoquent la typographie non essentielle au début, mais qui s'en désinscrivent ensuite lorsque l'en-tête Save-Data est présent :

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

Avec cette approche, vous pouvez laisser l'extrait <link> de Google Fonts en place, car le navigateur charge de manière spéculative les ressources CSS (y compris les polices Web) en appliquant d'abord les styles au DOM, puis en vérifiant si des éléments HTML invoquent l'une des ressources de la feuille de style. Si quelqu'un passe par là avec Save-Data activé, Fira Sans ne se chargera jamais, car le DOM stylisé ne l'invoque jamais. Arial sera utilisé à la place. Elle n'est pas aussi esthétique que Fira Sans, mais elle peut être préférable pour les utilisateurs qui essaient de ne pas dépasser leur forfait de données.

Résumé

L'en-tête Save-Data n'est pas très nuancé : il est activé ou désactivé, et l'application doit fournir des expériences appropriées en fonction de son paramètre, quelle que soit la raison.

Par exemple, certains utilisateurs peuvent ne pas autoriser le mode Économie de données s'ils pensent qu'il y aura une perte de contenu ou de fonctionnalité de l'application, même en cas de mauvaise connectivité. À l'inverse, certains utilisateurs peuvent l'activer systématiquement pour que les pages soient aussi petites et simples que possible, même en cas de bonne connectivité. Il est préférable que votre application parte du principe que l'utilisateur souhaite bénéficier d'une expérience complète et illimitée, sauf indication contraire explicite de sa part.

En tant que propriétaires de sites et développeurs Web, nous devons prendre la responsabilité de gérer notre contenu pour améliorer l'expérience utilisateur des personnes dont les données et les coûts sont limités.

Pour en savoir plus sur Save-Data et découvrir d'excellents exemples pratiques, consultez Aider vos utilisateurs Save Data.