Device Memory API et performances web : indication mémoire

navigator.deviceMemory est une indication approximative qui aide une application web à choisir une stratégie de ressources prudente. Ce n’est ni un inventaire de RAM, ni un test de performance, ni un motif pour identifier une personne. Traitez-la comme une entrée facultative, combinez-la aux résultats d’exécution et gardez une valeur par défaut utilisable pour les navigateurs qui ne l’exposent pas.

Ce que représente Device Memory API

Device Memory API expose navigator.deviceMemory, une valeur approximative de la mémoire de l’appareil en gigaoctets. La spécification du W3C décrit une valeur réduite et regroupée, pas une mesure exacte. Le navigateur peut l’arrondir ou la plafonner avant de la retourner ; le code doit donc la traiter comme une indication générale de capacité.

La propriété permet de choisir entre des variantes de ressources déjà conçues : différer une grande image, réduire un cache initial ou sélectionner une tâche cliente plus légère. Elle n’indique pas la mémoire libre actuelle et ne prédit pas la réussite d’une page. Elle ne renseigne pas non plus sur le quota de stockage, la vitesse du processeur, la qualité du réseau ou les préférences de l’utilisateur.

Disponibilité et limites

La prise en charge n’est pas universelle. MDN décrit Navigator.deviceMemory comme une fonctionnalité expérimentale à disponibilité limitée ; un navigateur peut l’omettre ou ne l’exposer que dans un contexte sécurisé. Le code doit détecter la propriété et continuer sans elle, sans assimiler son absence à une faible mémoire.

La valeur est volontairement imprécise et peut dépendre de la politique du navigateur. N’en faites pas une barrière de compatibilité, un contrôle de droits ou un seuil qui étiquette un appareil ou son propriétaire. N’en déduisez ni modèle, ni revenus, ni localisation, ni identité. Cette API est une surface sensible parmi d’autres, pas un profil fiable de l’appareil.

Adaptation progressive des charges réelles

Commencez par une expérience de base qui fonctionne sans l’API. Si une indication est disponible, utilisez-la pour choisir une variante bornée, puis observez le résultat avec des métriques applicatives ordinaires : fin du chargement, échecs de décodage, tâches longues et annulations. Ces signaux décrivent mieux la tâche courante qu’une estimation matérielle statique.

Adaptez un coût à la fois et rendez la décision réversible. Vous pouvez charger plus tard les médias sous la ligne de flottaison, choisir un aperçu plus petit, réduire les workers simultanés ou différer un index facultatif. Conservez le même contenu sémantique et les contrôles accessibles. Ne retirez jamais une action nécessaire simplement parce que l’indication est absente ou faible.

Le guide de planification de capacité BrowserContext traite des budgets mesurés pour les charges de navigateur longues. Le guide des capacités WebGL et de la confidentialité illustre la même stratégie de repli, tandis que les signaux de stockage et de mémoire des profils expliquent pourquoi des valeurs de ressources distinctes ne doivent pas être confondues.

Des replis respectueux de la confidentialité

Gardez l’indication locale à la décision qui en a besoin. N’envoyez pas la valeur brute à un serveur, ne l’ajoutez pas à un identifiant de compte et ne la conservez pas comme attribut stable de profil, sauf si une fonction clairement expliquée le demande. Une valeur regroupée peut tout de même contribuer à l’empreinte lorsqu’elle est combinée à d’autres signaux.

Préférez quelques politiques de ressources avec une valeur par défaut explicite et précisez que le choix est heuristique. Respectez les réglages d’économie de données et permettez de demander l’expérience complète lorsque c’est possible. Si l’adaptation modifie le transfert de données, expliquez-le avant l’action et gardez une voie accessible pour continuer.

Placer l’indication dans la bonne couche

L’API concerne la présentation ou l’ordonnancement, pas l’identité, les droits ou la facturation. La page peut différer un aperçu tandis que le serveur conserve les mêmes permissions et données nécessaires.

Ne faites pas dépendre le serveur d’une valeur absente ou arrondie autrement. S’il faut une préférence, envoyez un choix visible et temporaire, comme l’économie de données, pas le groupe mémoire.

Combiner capacité et résultats

La mémoire n’est qu’une partie de la charge. Latence, décodage, processeur, stockage, écran et préférences peuvent dominer. Mesurez le résultat utile à l’utilisateur plutôt qu’une estimation fixe.

Observez le décodage d’une image, le démarrage de la lecture, les reprises, la latence de saisie et la récupération. Ces résultats guident la politique sans transformer l’indication en étiquette.

Concevoir la base en premier

La base inclut contenu requis, clavier, texte lisible et reprise des améliorations. Une variante légère peut différer une amélioration, mais pas cacher l’unique moyen de terminer une tâche.

Testez sans propriété, avec lecture tardive et valeur regroupée, ainsi qu’après un changement d’économie de données. Le but est un comportement correct dans chaque branche.

Choisir des politiques durables

Images adaptatives, chargement différé, contre-pression, caches bornés et annulation restent utiles sans l’API. Ils réduisent aussi la pression réseau ou batterie.

Gardez quelques politiques nommées. Chacune doit préciser taille maximale, concurrence, cache et récupération pour rester facile à auditer.

Journaux et conservation

Enregistrez la politique et le résultat, pas une donnée matérielle inutile. resource_policy=reduced explique souvent le report. Si la valeur brute est nécessaire au diagnostic, limitez accès et durée puis supprimez-la.

Agrégez les résultats par politique. Évitez les tableaux qui classent des personnes par mémoire ; les résultats suffisent pour améliorer le produit.

Questions avant publication

Vérifiez que l’expérience reste complète sans la propriété, qu’aucun droit ou compte n’en dépend et que les journaux n’enregistrent pas la valeur brute. Rendez une réduction facultative compréhensible et réversible.

Répétez après une mise à jour du navigateur ou de la page. Un petit test sans propriété vaut mieux qu’une grande matrice de classes supposées.

Tester la disponibilité sans supposer une famille de navigateurs

La détection de fonctionnalité doit rester une branche normale, pas un test du nom du navigateur. Lisez la propriété seulement si elle existe et gardez la base quand elle vaut undefined. Le contexte sécurisé, la navigation privée ou un cadre intégré peuvent modifier la disponibilité.

Testez cette branche dans les environnements pris en charge. Vérifiez le contenu et les contrôles nécessaires, plutôt qu’une valeur fixe. Une mise à jour peut changer l’arrondi ; les tests doivent viser le comportement.

Séparer indication mémoire et budget de performance

L’indication peut choisir une politique initiale, tandis que le budget est une mesure liée à une charge. Gardez-les séparés : l’indication guide la page, le budget appartient à la version, l’hôte, la charge et la période observée.

En cas de dépassement, examinez le cycle de vie, les médias, les workers, le cache et le réseau avant de modifier la politique. Une fuite touche chaque appareil ; le processeur peut aussi limiter la réactivité.

Donner la priorité à l’intention de l’utilisateur

L’adaptation ne doit pas annuler un choix explicite. Pour un document complet demandé, expliquez le coût et proposez un chargement progressif, sans réduire silencieusement le contenu. L’économie de données est distincte de la mémoire.

Offrez un bouton de reprise visible et expliquez chaque report. Ne demandez pas une donnée matérielle pour choisir une image plus petite ; présentez la taille ou le mode clairement.

Éviter la corrélation entre sessions

L’usage le plus respectueux est temporaire : lisez l’indication pour la tâche actuelle, gardez la politique choisie et supprimez la valeur brute. Ne la combinez pas à un identifiant, une IP, Canvas, des polices ou des temps.

Pour l’assistance, enregistrez la politique, la version du navigateur et la charge reproductible, pas le groupe mémoire. Les rapports agrégés peuvent comparer les politiques sans suivre une personne.

Prévoir changement et récupération

Chaque politique doit avoir un responsable, une condition de retour et une date de revue. Relancez la charge après un changement de navigateur, de bundle, de médias ou d’hôte. Gardez la base tant que les nouvelles mesures ne sont pas établies.

La récupération fait partie de la performance : annulez le travail facultatif au départ, libérez les tampons et évitez les boucles de reprise sous pression.

Documenter la limite publique

La documentation doit dire que l’API est une indication approximative et facultative et qu’un chemin de base existe. Elle doit préciser qu’elle ne mesure pas la mémoire libre, ne garantit pas la performance, n’identifie pas l’appareil et n’autorise pas un compte.

Conservez les deux sources publiques. La spécification W3C justifie la valeur réduite et la confidentialité ; MDN justifie l’avertissement de disponibilité. En cas de changement, mettez à jour la compatibilité et retestez le repli.

La revue doit aussi couvrir l’échec de chaque ressource facultative : une image annulée garde son texte alternatif, un worker indisponible offre un chemin principal et un cache absent utilise des requêtes bornées. Une indication limitée ne voit ni la pression temporaire ni les autres onglets. Vérifiez par de petits parcours le premier chargement, le retour, les transitions, le transfert interrompu et la fermeture. Notez fin, annulation, latence et récupération sans contenu ni identifiant. Cela améliore les politiques sans transformer Device Memory API en profil matériel.

Les équipes multi-produits peuvent garder des noms de politiques communs et adapter les limites à chaque charge. Un lecteur réduit l’aperçu, un éditeur réduit l’indexation, mais tous deux peuvent signaler reduced au support. Publiez le comportement compréhensible, pas le groupe mémoire. Si les preuves sont insuffisantes, gardez la politique simple au lieu de recueillir davantage de données identifiantes.

Gardez les traces de revue petites et reproductibles : définition de politique, charge, version du navigateur et résultats suffisent souvent. Le parcours doit être rejouable sans accès aux pages privées des clients et conserver les preuves utiles aux comparaisons.

Lors d'une revue de production, notez aussi le mode de repli affiché lorsque l'indication est indisponible et si la personne peut continuer sans modifier un réglage. Cela relie la décision d'API à l'expérience réelle : une image plus légère, un aperçu différé ou moins de workers doivent rester compréhensibles et réversibles. Cette preuve de comportement est plus utile qu'un groupe matériel conservé et facilite la vérification après une mise à jour.

Si le serveur doit expliquer le choix, journalisez seulement le nom temporaire de la politique et le résultat de la tâche. N'envoyez pas l'indication comme attribut du compte : le retour arrière et le diagnostic restent possibles sans transformer une décision de compatibilité en profil intersessions.

Liste de décisions pratique

1. Détectez navigator.deviceMemory ; ne supposez jamais sa présence.
2. Définissez une expérience de base indépendante de l’indication.
3. Utilisez des variantes larges et réversibles, pas des étiquettes d’appareils.
4. Mesurez les résultats de la tâche et ajustez les budgets selon les échecs observés.
5. Gardez la valeur hors des identifiants, journaux et requêtes distantes sauf si l’utilisateur en comprend le but.

Sources

• W3C Device Memory API
• MDN : Navigator.deviceMemory