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

Dave Gash

Ilya Grigorik

Jeremy Wagner

L'en-tête de demande d'indication du client Save-Data 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.

Le besoin de pages allégées

Tout le monde s'accorde pour dire que les pages Web plus rapides et plus légères offrent une expérience utilisateur plus satisfaisante, favorisent la compréhension et la fidélisation des contenus, et génèrent davantage de conversions et de revenus. Une étude Google a montré que "les pages optimisées se chargent quatre fois plus vite que les pages d'origine et utilisent 80 % d'octets en moins. Le chargement de ces pages étant beaucoup plus rapide, nous avons également constaté une augmentation de 50% du trafic vers ces pages."

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

Ces arguments sont de bons arguments pour optimiser vos pages.

Il existe d'autres méthodes pour améliorer la vitesse d'un site sans intervention directe du développeur, telles que les navigateurs proxy et les services de transcodage. Bien que ces services soient très populaires, ils présentent des inconvénients importants : compression simple des images et du texte (et parfois non acceptable), impossibilité de traiter les pages sécurisées (HTTPS), n'optimisant que les pages consultées via un résultat de recherche, etc. La popularité même de ces services indique en elle-même que les développeurs Web ne répondent pas correctement à la forte demande des utilisateurs en termes d'applications et de 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 optimisée pour les utilisateurs dont les coûts et les performances sont limités.

Les navigateurs compatibles (ci-dessous) permettent à l'utilisateur d'activer un mode *d'enregistrement des données qui autorise le navigateur à appliquer un ensemble d'optimisations afin de 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 de texte et d'image.

Prise en charge des navigateurs

• Chrome 49 et versions ultérieures annoncent 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 annoncent Save-Data lorsque l'utilisateur active le mode Opera Turbo sur ordinateur ou l'option Économies de données sur les navigateurs Android.
• Yandex 16.2+ annonce Save-Data lorsque le mode Turbo est activé sur les navigateurs mobiles ou d'ordinateur.

Détecter le paramètre Save-Data

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

Lorsque l'utilisateur active le mode Économie de données dans son navigateur, celui-ci 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 n'annonce qu'un seul jeton "*on-" dans l'en-tête (Save-Data: on), mais il pourra être étendu à l'avenir pour indiquer d'autres préférences utilisateur.

De plus, il est 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.
  }
}

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

Activez 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 différente (balisage différent, images et vidéos plus petites, etc.).

Conseil :Si vous utilisez PageSpeed pour Apache ou Nginx pour optimiser vos pages, consultez cette discussion pour savoir comment permettre à vos utilisateurs de réaliser des économies Save-Data.

Conseils et bonnes pratiques pour l'implémentation

1. Lorsque vous utilisez Save-Data, fournissez des appareils d'interface utilisateur compatibles avec celui-ci et permettez aux utilisateurs de basculer facilement d'une expérience à l'autre. Exemple :
   • Informer les utilisateurs que Save-Data est compatible et les encourager à l'utiliser
   • Permettez aux utilisateurs d'identifier et de choisir le mode à l'aide d'invites appropriées, ainsi que de boutons ou de cases à cocher "Activer/Désactiver" intuitifs.
   • Lorsque le mode Économie de données est sélectionné, annoncez-le et indiquez-lui un moyen facile 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 mineures. Ils n'omettent pas de fonctionnalités ou de données importantes, ils sont juste plus attentifs aux coûts impliqués et à 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 gourmand en code.
   • Une application de recherche peut renvoyer moins de résultats à la fois, limiter le nombre de résultats 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 des catégories 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 autre réponse de page 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 plus agressive des ressources, etc.).
   • Si vous diffusez une autre réponse basée sur 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 le moment où l'option d'enregistrement des données est activée en vérifiant la présence de l'en-tête de requête Save-Data ou en vérifiant la valeur de la propriété navigator.connection.saveData. Si cette option est activée, déterminez si vous pouvez réécrire la requête pour récupérer moins d'octets ou utiliser une réponse déjà récupérée.
5. Envisagez d'enrichir Save-Data avec d'autres signaux, tels que des informations sur le type de connexion et la technologie de l'utilisateur (voir l'API NetInfo). Par exemple, vous pouvez proposer l'expérience simplifiée à tout utilisateur d'une connexion 2G, même si Save-Data n'est pas activé. À l'inverse, ce n'est pas parce que l'utilisateur utilise une connexion 4G "rapide" qu'il ne souhaite pas enregistrer de données (en itinérance, par exemple). En outre, vous pouvez augmenter la présence de Save-Data avec l'indice du client Device-Memory pour vous adapter davantage aux utilisateurs d'appareils dont la mémoire est limitée. La mémoire de l'appareil de l'utilisateur est également annoncée dans l'indice client navigator.deviceMemory.

Recettes

Ce que vous pouvez obtenir via Save-Data est limité à ce que vous pouvez inventer. Pour vous donner une idée de ce qui est possible, examinons quelques cas d'utilisation. En lisant ce texte, vous pouvez proposer d'autres cas d'utilisation. N'hésitez donc pas à faire des tests et à voir ce qu'il est possible de faire.

Vérification de Save-Data dans le code côté serveur

Bien que vous pouvez détecter l'état Save-Data 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. Elle est impliquée dans certains des cas d'utilisation les plus bénéfiques de Save-Data.

La syntaxe spécifique de détection de l'en-tête Save-Data dans le code côté serveur dépend du langage utilisé, mais l'idée de base doit être la même pour tout backend d'application. En PHP, par exemple, les en-têtes de requête sont stockés dans le tableau superglobal $_SERVER au niveau des 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 effectuez cette vérification avant l'envoi du balisage au client, la variable $saveData contiendra l'état Save-Data et sera disponible n'importe où sur la page. Voici quelques exemples illustrant comment utiliser ce mécanisme pour limiter la quantité de données que nous envoyons à l'utilisateur.

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

Un cas d'utilisation courant des images sur le Web consiste à diffuser des images par ensembles de deux : une image pour les écrans"standards" (1x) et une autre image deux fois plus grande (2x) pour les écrans haute résolution (par exemple, Écran Retina). 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 prudent 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, il nous suffit de modifier 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 parfait exemple de la facilité avec laquelle vous devez vous adapter à une personne qui vous demande spécifiquement de lui envoyer moins de données. Si vous n'aimez pas modifier le balisage sur le backend, vous pouvez obtenir le même résultat en utilisant un module de réécriture d'URL tel que mod_rewrite d'Apache. Il existe des exemples d'obtention avec relativement peu de configuration.

Vous pouvez également étendre ce concept aux propriétés CSS background-image 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> de votre CSS pour modifier la façon dont les images sont diffusées. Vous pouvez envoyer des images de fond basse résolution sur des écrans haute résolution, comme illustré dans l'exemple HTML ci-dessus, ou omettre certaines ressources.

Omettre les images non essentielles

Certains contenus d'images disponibles sur le Web ne sont tout simplement pas essentiels. Bien que ces images puissent apporter des avantages intéressants au contenu, elles ne sont peut-être pas souhaitables pour ceux qui essaient d'exploiter tout leur potentiel des plans de données facturés à l'usage. 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 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 certainement avoir un effet prononcé, comme vous pouvez le voir dans la figure ci-dessous:

Comparaison des images non critiques chargées lorsque le composant Save-Data est vide et des images identiques qui sont omises lorsque l'option "Enregistrer les données" est présente.

Bien sûr, l'omission d'images n'est pas la seule possibilité. Vous pouvez également agir sur Save-Data pour renoncer à envoyer d'autres ressources non critiques, telles que certaines polices de caractères.

Omettre les polices Web non essentielles

Bien que les polices Web ne représentent généralement pas autant de la charge utile totale d'une page donnée que les images, elles restent très populaires. Ils ne consomment pas non plus une quantité insignifiante de données. De plus, la façon dont les navigateurs récupèrent et affichent les polices est plus compliquée qu'il n'y paraît. Des concepts tels que FOIT et FOUT, et les heuristiques de navigateur rendent le rendu une opération nuancée.

Il peut donc être logique que vous souhaitiez omettre les polices Web non essentielles pour les utilisateurs qui souhaitent bénéficier d'expériences utilisateur plus fluides. Avec Save-Data, cette opération est relativement simple.

Par exemple, supposons que vous ayez inclus Fira Sans dans Google Fonts sur votre site. Fira Sans est une excellente police de texte, mais elle n'est peut-être pas si cruciale 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 appellent d'abord la police de caractères non essentielle, puis la désactive 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 conserver l'extrait <link> de Google Fonts, car le navigateur charge de manière spéculative les ressources CSS (y compris les polices Web) en appliquant d'abord des styles au DOM, puis en vérifiant si des éléments HTML appellent l'une des ressources de la feuille de style. Si quelqu'un se produit avec Save-Data activé, Fira Sans ne se chargera jamais, car le DOM stylisé ne l'appelle jamais. Arial est alors pris en compte. Ce n'est pas aussi bien que Fira Sans, mais il peut être préférable aux utilisateurs qui essaient d'allonger leur forfait.

Résumé

L'en-tête Save-Data est peu nuancé. Il est activé ou désactivé, et l'application doit fournir des expériences appropriées en fonction de son paramètre, quelle qu'en soit la raison.

Par exemple, certains utilisateurs peuvent ne pas autoriser le mode Économie de données s'ils soupçonnent une perte de contenu ou de fonction de l'application, même en cas de mauvaise connectivité. À l'inverse, certains utilisateurs peuvent tout naturellement faire en sorte que les pages restent aussi petites et simples que possible, même dans une bonne situation de connectivité. Il est préférable que votre application part du principe que l'utilisateur souhaite bénéficier d'une expérience complète et illimitée jusqu'à ce que vous ayez une indication claire du contraire via une action utilisateur explicite.

En tant que propriétaires de sites et développeurs Web, en tant que développeurs Web, endossons la responsabilité de la gestion de notre contenu afin d'améliorer l'expérience utilisateur pour les utilisateurs dont les données et le coût sont limités.

Pour en savoir plus sur Save-Data et obtenir d'excellents exemples pratiques, consultez la page Aidez vos utilisateurs Save Data.