Craft et technique
Comment éviter les fuites de mémoire dans un site riche en animations ?
Pour éviter les fuites de mémoire dans un site animé, chaque ressource créée doit avoir un responsable et une condition de fin. Une scène retirée de l’écran peut encore conserver des références, des textures ou une boucle active. La qualité de la première visite ne suffit donc pas à juger la solidité du site.
L'essentiel.
Un site animé doit savoir libérer ce qu’il crée. Les scènes, écouteurs, textures et boucles ont un cycle de vie à définir. La vérification consiste à répéter les parcours et à distinguer une mémoire utilement conservée d’une accumulation non maîtrisée.
- Définir la création, l’utilisation et la libération de chaque famille de ressources.
- Arrêter les activités et détacher les références qui n’ont plus d’utilité.
- Traiter explicitement les ressources graphiques selon les règles du moteur employé.
- Comparer la mémoire sur des cycles répétés, en distinguant cache prévu et accumulation anormale.
Le problème devient particulièrement visible lorsque la navigation charge plusieurs scènes sans quitter complètement l’application. Les retours, les ouvertures de panneaux et les changements de variantes doivent être testés de manière répétée. L’objectif est de comprendre ce qui reste en mémoire et pourquoi, sans supposer que toute conservation est une fuite.
Identifier ce qui survit à la fermeture d’une scène
Une scène peut mobiliser des objets JavaScript, des éléments du document, des événements, des médias et des ressources graphiques. Ces éléments ne suivent pas tous le même mécanisme de libération. Il faut donc dresser leur inventaire et définir leur propriétaire.
La documentation mémoire de Chrome DevTools montre notamment comment des éléments retirés du document peuvent rester retenus par des références JavaScript. Un panneau qui n’est plus visible peut ainsi continuer à exister et à recevoir des événements.
| Ressource | Question de cycle de vie | Vérification à prévoir |
|---|---|---|
| Écouteur d’événement | Quand cesse-t-il d’être utile ? | Il ne se multiplie pas à chaque ouverture |
| Boucle d’animation | Quel événement l’arrête ? | Elle ne continue pas après la sortie |
| Scène et médias | Qui en possède la référence ? | Les éléments inutiles deviennent libérables |
| Texture ou géométrie | Est-elle encore partagée ? | Sa libération ne casse pas une autre scène |
Cette cartographie est plus utile qu’un nettoyage indifférencié en fin de page. Elle permet de comprendre les dépendances et de traiter les ressources au bon moment.
Respecter les règles du moteur graphique
Dans Three.js, retirer un objet de la scène ne libère pas automatiquement toutes ses ressources graphiques. Le guide officiel sur la libération des objets décrit notamment les méthodes de libération des géométries, matériaux et textures, ainsi que l’attention nécessaire aux ressources partagées.
Le nettoyage doit donc être organisé. Une texture commune à plusieurs objets ne doit pas être détruite tant qu’elle sert ailleurs. À l’inverse, conserver sans limite chaque variante déjà consultée peut créer une accumulation inutile. La politique de cache doit être explicite et proportionnée au parcours.
Les activités programmées demandent le même soin. cancelAnimationFrame permet d’annuler une demande de frame identifiée. Il faut également empêcher la logique de relancer une boucle après la sortie et traiter les autres abonnements ou minuteries utilisés par le projet.
Exemple pédagogique : une galerie qui ouvre plusieurs scènes
Imaginons un portfolio fictif où chaque projet possède une petite scène 3D. Lors de la première visite, tout semble correct. Après plusieurs allers-retours, l’interface devient moins réactive. Une hypothèse est que les scènes précédentes restent actives ou conservent des ressources sans raison.
Le protocole ouvre le même projet, revient à la liste, puis répète ce cycle. L’équipe observe les ressources conservées après chaque retour et compare ce comportement avec la politique prévue. Elle vérifie notamment les boucles, les références aux objets et les éléments graphiques propres au projet fermé.
Donner une fin aux ressources
- CréerIdentifier les objets, médias, textures et événements nécessaires.
- UtiliserGarder une responsabilité explicite pour les ressources partagées.
- QuitterArrêter les activités et libérer ce qui ne sert plus.
- VérifierRépéter le parcours pour contrôler ce qui reste et pourquoi.
Dans cet exemple, une correction peut consister à donner au composant une fonction de fermeture responsable de ses ressources. Le résultat doit être vérifié sur les mêmes cycles. Il ne faut pas annoncer une fuite résolue simplement parce que la page redevient fluide après un rechargement complet.
Distinguer croissance normale et fuite probable
Une courbe de mémoire peut augmenter lors d’une opération, puis redescendre. Certaines ressources sont conservées volontairement pour éviter un nouveau chargement. L’analyse doit donc porter sur l’évolution après des cycles comparables et sur la raison des éléments retenus.
Les outils de profilage permettent d’examiner les objets, les références et les allocations. Ils demandent une interprétation : un compteur non nul ne démontre pas à lui seul une fuite, et toutes les ressources graphiques ne se lisent pas dans un unique chiffre de mémoire JavaScript.
Documentez l’état initial, le parcours, les moments de capture et les attentes de nettoyage. Commencez par un composant isolé, puis vérifiez son intégration dans le site. Les interactions entre composants peuvent créer des dépendances absentes du prototype.
Le contrôle doit être rejoué après une évolution importante : nouveau moteur, nouvelle transition ou ajout de variantes. Une règle simple de production consiste à demander pour chaque composant animé non seulement « comment démarre-t-il ? », mais aussi « comment s’arrête-t-il et que laisse-t-il derrière lui ? ».
Questions fréquentes
Une mémoire élevée signifie-t-elle forcément une fuite ?
Non. Une scène peut utiliser beaucoup de ressources de manière légitime, ou conserver un cache prévu. Il faut examiner l’évolution, les références et les besoins du parcours. La question est de savoir si les éléments retenus restent utiles et si la consommation se stabilise dans des conditions comparables.
Peut-on libérer toutes les textures à chaque changement de page ?
Cela peut détruire des ressources encore utilisées ou provoquer des rechargements coûteux. Il faut connaître leur propriétaire et leurs usages partagés. Une politique de nettoyage ciblée, associée à un cache maîtrisé, est préférable à une destruction générale appliquée sans comprendre les dépendances.
Les tests automatisés suffisent-ils à détecter le problème ?
Ils peuvent aider à répéter des parcours et à suivre certaines mesures, mais ne remplacent pas l’analyse des ressources ni l’observation sur les appareils utiles. Une dégradation peut dépendre de conditions particulières. Le protocole doit combiner répétition, instrumentation et examen du comportement réel.
Sources
LVX : inclure la durée de vie des effets dans la recette
Pour un site riche en interactions, LVX peut intégrer les parcours répétés et les sorties de scène aux critères de production. L’équipe technique dispose alors de situations explicites à vérifier : ouverture, retour, changement de variante et reprise. La direction artistique peut préserver ses moments forts tout en discutant les coûts et les règles de conservation. Cette démarche vise une expérience qui reste maîtrisée après plusieurs actions, avec une finition évaluée sur l’ensemble de la visite et pas seulement sur son premier écran. Discuter du projet avec LVX.
