Surveillez l'utilisation totale de la mémoire de votre page Web avec measureUserAgentSpecificMemory()

Découvrez comment mesurer l'utilisation de la mémoire de votre page Web en production pour détecter les régressions.

Ulan Degenbaev
Ulan Degenbaev

Les navigateurs gèrent automatiquement la mémoire des pages Web. Chaque fois qu'une page Web crée un objet, le navigateur alloue un bloc de mémoire "sous le capot" pour le stocker. Étant donné que la mémoire est une ressource limitée, le navigateur effectue une récupération de mémoire pour détecter quand un objet n'est plus nécessaire et pour libérer le bloc de mémoire sous-jacent.

La détection n'est toutefois pas parfaite, et il a été prouvé qu'une détection parfaite est une tâche impossible. Par conséquent, les navigateurs approximativent la notion d'objet nécessaire par la notion d'objet accessible. Si la page Web ne peut pas atteindre un objet via ses variables et les champs d'autres objets accessibles, le navigateur peut récupérer l'objet en toute sécurité. La différence entre ces deux notions entraîne des fuites de mémoire, comme illustré par l'exemple suivant.

const object = {a: new Array(1000), b: new Array(2000)};
setInterval(() => console.log(object.a), 1000);

Ici, le tableau b plus volumineux n'est plus nécessaire, mais le navigateur ne le récupère pas, car il est toujours accessible via object.b dans le rappel. Par conséquent, la mémoire du tableau plus volumineux est divulguée.

Les fuites de mémoire sont très courantes sur le Web. Il est facile d'en créer une en oubliant de désenregistrer un écouteur d'événements, en capturant accidentellement des objets à partir d'un iframe, en ne fermant pas un worker, en accumulant des objets dans des tableaux, etc. Si une page Web présente des fuites de mémoire, son utilisation de la mémoire augmente au fil du temps et la page Web apparaît lente et gonflée aux yeux des utilisateurs.

La première étape pour résoudre ce problème consiste à le mesurer. La nouvelle API performance.measureUserAgentSpecificMemory() permet aux développeurs de mesurer l'utilisation de la mémoire de leurs pages Web en production et ainsi de détecter les fuites de mémoire qui passent inaperçues lors des tests locaux.

En quoi performance.measureUserAgentSpecificMemory() diffère-t-il de l'ancienne API performance.memory ?

Si vous connaissez l'API performance.memory non standard existante, vous vous demandez peut-être en quoi la nouvelle API diffère. La principale différence est que l'ancienne API renvoie la taille du tas de mémoire JavaScript, tandis que la nouvelle API estime la mémoire utilisée par la page Web. Cette différence devient importante lorsque Chrome partage le même tas avec plusieurs pages Web (ou plusieurs instances de la même page Web). Dans ce cas, le résultat de l'ancienne API peut être arbitrairement incorrect. Étant donné que l'ancienne API est définie en termes spécifiques à l'implémentation, tels que "heap", sa standardisation est impossible.

Autre différence : la nouvelle API effectue une mesure de la mémoire lors de la collecte des déchets. Cela réduit le bruit dans les résultats, mais leur production peut prendre un certain temps. Notez que d'autres navigateurs peuvent décider d'implémenter la nouvelle API sans s'appuyer sur le garbage collection.

Suggestions de cas d'utilisation

L'utilisation de la mémoire d'une page Web dépend du calendrier des événements, des actions des utilisateurs et des récupérations de mémoire. C'est pourquoi l'API de mesure de la mémoire est destinée à agréger les données d'utilisation de la mémoire en production. Les résultats des appels individuels sont moins utiles. Exemples de cas d'utilisation :

  • Détection de régression lors du déploiement d'une nouvelle version de la page Web pour détecter les nouvelles fuites de mémoire.
  • Effectuer des tests A/B sur une nouvelle fonctionnalité pour évaluer son impact sur la mémoire et détecter les fuites de mémoire
  • Corrélation de l'utilisation de la mémoire avec la durée de la session pour vérifier la présence ou l'absence de fuites de mémoire.
  • Corrélation de l'utilisation de la mémoire avec les métriques utilisateur pour comprendre l'impact global de l'utilisation de la mémoire.

Compatibilité du navigateur

Navigateurs pris en charge

  • Chrome: 89.
  • Edge: 89.
  • Firefox: non compatible.
  • Safari: non compatible.

Source

Actuellement, l'API n'est compatible qu'avec les navigateurs Chromium, à partir de Chrome 89. Le résultat de l'API dépend fortement de l'implémentation, car les navigateurs ont différentes manières de représenter des objets en mémoire et d'estimer l'utilisation de la mémoire. Les navigateurs peuvent exclure certaines régions de mémoire de la comptabilisation si la comptabilisation appropriée est trop coûteuse ou impossible. Par conséquent, les résultats ne peuvent pas être comparés entre les navigateurs. Il n'est pertinent de comparer les résultats que pour le même navigateur.

Utiliser performance.measureUserAgentSpecificMemory()

Détection de fonctionnalités

La fonction performance.measureUserAgentSpecificMemory sera indisponible ou peut échouer avec une SecurityError si l'environnement d'exécution ne répond pas aux exigences de sécurité pour éviter les fuites d'informations inter-origines. Il repose sur l'isolation cross-origin, qu'une page Web peut activer en définissant les en-têtes COOP+COEP.

La prise en charge peut être détectée au moment de l'exécution:

if (!window.crossOriginIsolated) {
  console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
} else if (!performance.measureUserAgentSpecificMemory) {
  console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
} else {
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
    } else {
      throw error;
    }
  }
  console.log(result);
}

Test local

Chrome effectue la mesure de la mémoire lors de la récupération de mémoire, ce qui signifie que l'API ne résout pas immédiatement la promesse de résultat et attend plutôt la prochaine récupération de mémoire.

L'appel de l'API force une collecte des déchets après un délai d'inactivité, qui est actuellement défini sur 20 secondes, mais peut se produire plus tôt. Démarrer Chrome avec l'indicateur de ligne de commande --enable-blink-features='ForceEagerMeasureMemory' réduit le délai avant expiration à zéro et est utile pour le débogage et les tests en local.

Exemple

L'utilisation recommandée de l'API consiste à définir un moniteur de mémoire global qui échantillonne l'utilisation de la mémoire de l'ensemble de la page Web et envoie les résultats à un serveur pour agrégation et analyse. Le moyen le plus simple consiste à effectuer des échantillons périodiquement, par exemple toutes les M minutes. Cependant, cela introduit un biais dans les données, car des pics de mémoire peuvent se produire entre les échantillons.

L'exemple suivant montre comment effectuer des mesures de mémoire impartiales à l'aide d'un processus de Poisson, qui garantit que les échantillons ont une probabilité égale de se produire à tout moment (démo, source).

Commencez par définir une fonction qui planifie la prochaine mesure de la mémoire à l'aide de setTimeout() avec un intervalle aléatoire.

function scheduleMeasurement() {
  // Check measurement API is available.
  if (!window.crossOriginIsolated) {
    console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
    console.log('See https://web.dev/coop-coep/ to learn more')
    return;
  }
  if (!performance.measureUserAgentSpecificMemory) {
    console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
    return;
  }
  const interval = measurementInterval();
  console.log(`Running next memory measurement in ${Math.round(interval / 1000)} seconds`);
  setTimeout(performMeasurement, interval);
}

La fonction measurementInterval() calcule un intervalle aléatoire en millisecondes de sorte qu'en moyenne, une mesure soit effectuée toutes les cinq minutes. Consultez la page Distribution exponentielle si vous souhaitez en savoir plus sur les mathématiques sous-jacentes à la fonction.

function measurementInterval() {
  const MEAN_INTERVAL_IN_MS = 5 * 60 * 1000;
  return -Math.log(Math.random()) * MEAN_INTERVAL_IN_MS;
}

Enfin, la fonction performMeasurement() asynchrone appelle l'API, enregistre le résultat et planifie la prochaine mesure.

async function performMeasurement() {
  // 1. Invoke performance.measureUserAgentSpecificMemory().
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
      return;
    }
    // Rethrow other errors.
    throw error;
  }
  // 2. Record the result.
  console.log('Memory usage:', result);
  // 3. Schedule the next measurement.
  scheduleMeasurement();
}

Enfin, commencez à mesurer.

// Start measurements.
scheduleMeasurement();

Le résultat peut ressembler à ceci:

// Console output:
{
  bytes: 60_100_000,
  breakdown: [
    {
      bytes: 40_000_000,
      attribution: [{
        url: 'https://example.com/',
        scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 20_000_000,
      attribution: [{
          url: 'https://example.com/iframe',
          container: {
            id: 'iframe-id-attribute',
            src: '/iframe',
          },
          scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 100_000,
      attribution: [],
      types: ['DOM']
    },
  ],
}

L'estimation de l'utilisation totale de la mémoire est renvoyée dans le champ bytes. Cette valeur dépend fortement de l'implémentation et ne peut pas être comparée entre les navigateurs. Il peut même varier entre les différentes versions du même navigateur. La valeur inclut la mémoire JavaScript et DOM de toutes les iFrames, fenêtres associées et nœuds de calcul Web du processus en cours.

La liste breakdown fournit des informations supplémentaires sur la mémoire utilisée. Chaque entrée décrit une partie de la mémoire et l'attribue à un ensemble de fenêtres, d'iFrames et de nœuds de calcul identifiés par une URL. Le champ types liste les types de mémoire spécifiques à l'implémentation associés à la mémoire.

Il est important de traiter toutes les listes de manière générique et de ne pas coder en dur des hypothèses basées sur un navigateur particulier. Par exemple, certains navigateurs peuvent renvoyer un breakdown ou un attribution vide. D'autres navigateurs peuvent renvoyer plusieurs entrées dans attribution, ce qui indique qu'ils n'ont pas pu distinguer laquelle de ces entrées est propriétaire de la mémoire.

Commentaires

Le groupe de la communauté sur les performances Web et l'équipe Chrome aimeraient connaître vos commentaires et votre expérience avec performance.measureUserAgentSpecificMemory().

Parlez-nous de la conception de l'API

L'API ne fonctionne-t-elle pas comme prévu ? Ou manque-t-il des propriétés dont vous avez besoin pour mettre en œuvre votre idée ? Signalez un problème de spécification dans le dépôt GitHub performance.measureUserAgentSpecificMemory() ou ajoutez vos commentaires à un problème existant.

Signaler un problème d'implémentation

Avez-vous trouvé un bug dans l'implémentation de Chrome ? Ou l'implémentation est-elle différente de la spécification ? Signalez un bug sur new.crbug.com. Veillez à inclure autant de détails que possible, à fournir des instructions simples pour reproduire le bug et à définir Components sur Blink>PerformanceAPIs. Glitch est idéal pour partager des reproductions rapidement et facilement.

Montrer votre soutien

Prévoyez-vous d'utiliser performance.measureUserAgentSpecificMemory() ? Votre soutien public aide l'équipe Chrome à hiérarchiser les fonctionnalités et montre aux autres fournisseurs de navigateurs à quel point il est essentiel de les prendre en charge. Envoyez un tweet à @ChromiumDev et dites-nous où et comment vous l'utilisez.

Liens utiles

Remerciements

Un grand merci à Domenic Denicola, Yoav Weiss et Mathias Bynens pour les examens de conception de l'API, et à Dominik Inführ, Hannes Payer, Kentaro Hara et Michael Lippautz pour les examens de code dans Chrome. Je remercie également Per Parker, Philipp Weis, Olga Belomestnykh, Matthew Bolohan et Neil McKay pour leurs commentaires précieux qui ont grandement amélioré l'API.

Image héros par Harrison Broadbent sur Unsplash