La gamme des appareils qui peuvent se connecter au Web est plus étendue qu'auparavant. La même application Web diffusée sur un ordinateur de bureau haut de gamme peut également être diffusée sur un téléphone, une montre ou une tablette basse consommation. Il peut donc être incroyablement difficile de créer des expériences attrayantes qui fonctionnent parfaitement sur n'importe quel appareil.
L'API Device Memory est une nouvelle fonctionnalité de la plate-forme Web qui vise à aider les développeurs Web à gérer le paysage moderne des appareils. Elle ajoute une propriété en lecture seule à l'objet navigator, navigator.deviceMemory, qui renvoie la quantité de RAM dont dispose l'appareil en gigaoctets, arrondie à la puissance de deux la plus proche. L'API comporte également un en-tête "Client Hints" (Device-Memory), qui indique la même valeur.
L'API Device Memory permet aux développeurs d'effectuer deux opérations principales:
- Prenez des décisions d'exécution concernant les ressources à diffuser en fonction de la valeur de mémoire de l'appareil renvoyée (par exemple, diffuser une version "allégée" d'une application pour les utilisateurs d'appareils à faible mémoire).
- Transmettez cette valeur à un service d'analyse afin de mieux comprendre la corrélation entre la mémoire de l'appareil et le comportement des utilisateurs, les conversions ou d'autres métriques importantes pour votre entreprise.
Adapter le contenu de manière dynamique en fonction de la mémoire de l'appareil
Si vous exécutez votre propre serveur Web et que vous êtes en mesure de modifier la logique qui diffuse les ressources, vous pouvez répondre de manière conditionnelle aux requêtes contenant l'en-tête des indicateurs client Device-Memory.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
Cette technique vous permet de créer une ou plusieurs versions de vos scripts d'application et de répondre aux requêtes du client de manière conditionnelle en fonction de la valeur définie dans l'en-tête Device-Memory. Ces versions n'ont pas besoin de contenir un code complètement différent (car plus difficile à gérer). La plupart du temps, la version "allégée" exclut simplement les fonctionnalités qui peuvent être coûteuses et non essentielles à l'expérience utilisateur.
Utiliser l'en-tête des suggestions client
Pour activer l'en-tête Device-Memory, ajoutez la balise <meta> des conseils client au <head> de votre document:
<meta http-equiv="Accept-CH" content="Device-Memory">
Vous pouvez également inclure "Device-Memory" dans les en-têtes de réponse Accept-CH de votre serveur:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
Cela indique au navigateur d'envoyer l'en-tête Device-Memory avec toutes les requêtes de sous-ressources pour la page actuelle.
En d'autres termes, une fois que vous avez implémenté l'une des options ci-dessus pour votre site Web, si un utilisateur consulte un appareil disposant de 0,5 Go de RAM, toutes les requêtes image, CSS et JavaScript de cette page incluent l'en-tête Device-Memory avec la valeur définie sur "0.5". Votre serveur peut répondre à ces requêtes comme vous le souhaitez.
Par exemple, la route Express suivante diffuse une version "allégée" d'un script si l'en-tête Device-Memory est défini et que sa valeur est inférieure à 1, ou une version "complète" si le navigateur n'est pas compatible avec l'en-tête Device-Memory ou si la valeur est supérieure ou égale à 1:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
Utiliser l'API JavaScript
Dans certains cas (comme avec un serveur de fichiers statiques ou un CDN), vous ne pourrez pas répondre de manière conditionnelle aux requêtes basées sur un en-tête HTTP. Dans ces cas, vous pouvez utiliser l'API JavaScript pour effectuer des requêtes conditionnelles dans votre code JavaScript.
La logique suivante est semblable à la route Express ci-dessus, sauf qu'elle détermine de manière dynamique l'URL du script dans la logique côté client:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
Bien que la diffusion conditionnelle de différentes versions du même composant en fonction des capacités de l'appareil soit une bonne stratégie, il peut parfois être encore préférable de ne pas diffuser du tout un composant.
Bien souvent, les composants ne sont que des améliorations. Elles apportent une touche personnelle à l'expérience, mais ne sont pas nécessaires à la fonctionnalité de base de l'application. Dans ce cas, il peut être judicieux de ne pas charger ces composants en premier lieu. Si un composant destiné à améliorer l'expérience utilisateur ralentit l'application ou ne répond pas, cela signifie qu'il n'atteint pas son objectif.
Quelle que soit la décision prise concernant l'expérience utilisateur, il est essentiel d'en mesurer l'impact. Il est également essentiel que vous ayez une idée précise des performances actuelles de votre application.
Comprendre la corrélation entre la mémoire de l'appareil et le comportement des utilisateurs de la version actuelle de votre application vous aidera à déterminer les mesures à prendre et vous fournira une base de référence qui vous permettra de mesurer l'efficacité des futurs changements.
Suivre la mémoire de l'appareil à l'aide d'analyses
L'API Device Memory est nouvelle, et la plupart des fournisseurs de solutions d'analyse n'en assurent pas le suivi par défaut. Heureusement, la plupart des fournisseurs de solutions d'analyse vous offrent un moyen de suivre des données personnalisées (par exemple, Google Analytics dispose d'une fonctionnalité appelée Dimensions personnalisées) que vous pouvez utiliser pour suivre la mémoire des appareils de vos utilisateurs.
Utiliser une dimension personnalisée "Mémoire de l'appareil"
L'utilisation de dimensions personnalisées dans Google Analytics s'effectue en deux étapes.
- Configurez la dimension personnalisée dans Google Analytics.
- Remplacez votre code de suivi par
setla valeur de mémoire de l'appareil pour la dimension personnalisée que vous venez de créer.
Lorsque vous créez la dimension personnalisée, nommez-la "Mémoire de l'appareil" et sélectionnez le champ d'application "session", car la valeur ne change pas pendant la session de navigation de l'utilisateur:
Ensuite, mettez à jour votre code de suivi. Voici un exemple de ce à quoi cela pourrait ressembler. Notez que pour les navigateurs qui ne sont pas compatibles avec l'API Device Memory, la valeur de la dimension sera "(not set)".
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
Création de rapports sur les données de mémoire de l'appareil
Une fois que la dimension "Mémoire de l'appareil" est définie sur set dans l'objet de suivi, toutes les données que vous envoyez à Google Analytics incluent cette valeur.
Cela vous permettra de ventiler les métriques de votre choix (par exemple, le temps de chargement des pages, le taux d'achèvement de l'objectif, etc.) par mémoire de l'appareil pour voir s'il existe des corrélations.
Étant donné que la mémoire de l'appareil est une dimension personnalisée plutôt qu'une dimension intégrée, elle n'apparaît dans aucun des rapports standards. Pour accéder à ces données, vous devez créer un rapport personnalisé. Par exemple, la configuration d'un rapport personnalisé qui compare les temps de chargement par mémoire de l'appareil peut se présenter comme suit:
Le rapport généré peut se présenter comme suit:
Une fois que vous collectez des données sur la mémoire de l'appareil et que vous disposez d'une référence pour savoir comment les utilisateurs expérimentent votre application sur toutes les plages du spectre de mémoire, vous pouvez tester différentes ressources pour différents utilisateurs (à l'aide des techniques décrites dans la section ci-dessus). Par la suite, vous pourrez examiner les résultats et voir s'ils se sont améliorés.
Conclusion
Cet article explique comment utiliser l'API Device Memory pour adapter votre application aux fonctionnalités des appareils de vos utilisateurs et comment mesurer l'expérience de ces utilisateurs avec votre application.
Bien que cet article se concentre sur l'API Device Memory, la plupart des techniques décrites ici peuvent être appliquées à toute API qui indique les fonctionnalités de l'appareil ou les conditions du réseau.
À mesure que le paysage des appareils ne cesse de s'élargir, il est plus important que jamais que les développeurs Web prennent en compte l'ensemble du spectre des utilisateurs lorsqu'ils prennent des décisions qui affectent leur expérience.