« L’application fonctionne, mais pourquoi devient-elle de plus en plus lente ? »
« Il n’y a pas d’erreur dans le code, mais les performances sont au ralenti… »
« L’onglet Chrome est littéralement à bout de souffle » 🥵

Félicitations.
Vous venez peut-être de rencontrer une fuite de mémoire.

Aujourd’hui, nous allons :

• Comprendre vraiment ce qu’est une fuite de mémoire
• Examiner exactement d’où elle vient
• Et surtout : apprendre comment la prévenir

---

🧠 Qu’est-ce qu’une fuite de mémoire ? (Explication très claire)

Une fuite de mémoire se produit lorsque JavaScript garde des données dans la RAM alors qu’elles ne sont plus nécessaires.

Flux normal :

1. Les données sont créées
2. Les données sont utilisées
3. Une fois terminées → supprimées 🧹

Avec une fuite de mémoire :

« Peut-être que ça servira plus tard… »
JavaScript refuse de les supprimer 😬

Résultat :

• RAM saturée
• L’application ralentit
• Le navigateur commence à se plaindre

---

🧹 Garbage Collector (Le concierge prudent)

JavaScript a un Garbage Collector.

Son rôle :

Supprimer les données qui ne sont plus accessibles

Exemple simple :

let user = { name: "Ali" };
user = null;

• { name: "Ali" } n’est plus accessible
• Le Garbage Collector arrive et dit :

« OK, on peut le supprimer » ✅

💡 Le problème survient lorsque vous gardez accidentellement des données accessibles.

Le Garbage Collector dira alors :

« Ceci est encore vivant… » 😐

---

🚨 Signes d’une fuite de mémoire (Votre app appelle à l’aide)

Faites attention si vous remarquez :

• 🐌 L’application devient de plus en plus lente
• 📈 La RAM augmente constamment
• 🔄 Actualiser la page la rétablit temporairement
• 💻 Le ventilateur de l’ordinateur tourne à fond ✈️

---

😈 Causes les plus courantes des fuites de mémoire en JavaScript

Plongeons maintenant dans les pièges classiques que tout le monde rencontre 👇

---

1️⃣ Variables globales – « Je suis là et je ne pars pas »

❌ Code dangereux

leakedValue = "Oops";

Que s’est-il passé ?

• Pas de let, const ou var
• Devient automatiquement global
• Reste dans la RAM jusqu’à la fermeture de la page 🎯

Exemple sournois :

function createData() {
  data = new Array(1000000);
}
createData();

• data reste en mémoire même après la fin de la fonction

✅ Utilisation correcte

function createData() {
  const data = new Array(1000000);
}

🧠 Règle :

Les variables globales = fuites de mémoire potentielles

---

2️⃣ Event listeners – « Vous l’avez ajouté, mais oublié »

Erreur classique :

button.addEventListener("click", () => {
  console.log("Clicked");
});

Problème ?

• Le bouton peut être supprimé du DOM
• Le listener reste en mémoire
• JS pense « un jour quelqu’un cliquera dessus » 😅

❌ Désastre dans les SPA

• La page change, le composant disparaît, mais le listener persiste

✅ Utilisation correcte :

function handleClick() {
  console.log("Clicked");
}

button.addEventListener("click", handleClick);

// Nettoyage
button.removeEventListener("click", handleClick);

📌 Règle d’or :

Si vous ajoutez un événement, prévoyez de le retirer

---

3️⃣ setInterval & setTimeout – Bombe à retardement ⏰

❌ Dangereux

setInterval(() => {
  console.log("Running...");
}, 1000);

Que se passe-t-il ?

• La page change ou le composant se démonte
• L’intervalle continue à tourner indéfiniment 😈

✅ Utilisation correcte

const id = setInterval(() => {
  console.log("Running...");
}, 1000);

// Stoppez-le lorsque terminé
clearInterval(id);

⚛️ En React :

useEffect(() => {
  const id = setInterval(() => {
    console.log("tick");
  }, 1000);

  return () => clearInterval(id);
}, []);

💡 Astuce :

Si vous avez un intervalle mais que vous ne le nettoyez pas → fuite probable

---

4️⃣ Closures – Superpuissance avec effets secondaires 🧠

Qu’est-ce qu’une closure ?

Une fonction qui se souvient des variables de son scope externe

function counter() {
  let count = 0;

  return function () {
    count++;
    console.log(count);
  };
}

Ici :

• count n’est jamais supprimé
• Parce que la fonction interne l’utilise toujours

❌ Gros dataset + closure = fuite de mémoire

function leakyClosure() {
  const bigArray = new Array(1000000);

  return () => {
    console.log(bigArray.length);
  };
}

• Tant que cette fonction existe → bigArray reste en RAM 🧠

✅ Solution

• Garder les grosses données à l’extérieur
• Nullifier les références lorsque terminé

---

5️⃣ Références DOM – Chaînes invisibles

❌ Fuite classique

let box = document.getElementById("box");

document.body.removeChild(box);
// box garde encore la référence

Que s’est-il passé ?

• Le DOM a disparu
• La référence JS reste
• Le Garbage Collector ne peut pas la supprimer

✅ Nettoyage

box = null;

🧹 Maintenant, elle peut être collectée

---

🕵️ Comment détecter les fuites de mémoire ?

🔍 Chrome DevTools

• Onglet Memory
• Heap Snapshot
• Allocation Timeline

Test logique :

« Ai-je vraiment encore besoin de ces données ? »

Si la réponse est non → probablement une fuite 😄

---

🛡️ Guide de prévention des fuites de mémoire (Mur de sagesse)

✔️ Évitez les variables globales
✔️ Nettoyez les event listeners
✔️ Stoppez les intervalles/timeouts
✔️ Faites attention aux grosses closures
✔️ Nullifiez les références DOM
✔️ Respectez le cycle de vie des composants

---

🎯 Pourquoi est-ce critique ?

Parce que les fuites de mémoire :

• Ne génèrent pas d’erreurs
• Ne crient pas dans la console
• Tuent silencieusement les performances ☠️

Et en production :

« Pourquoi notre app est-elle si lente ? » 😬

---

☕ Résumé épique

• Fuite de mémoire = mémoire inutilisée reste allouée
• JavaScript ne vous avertira pas
• L’un des bugs les plus dangereux
• Mais si vous savez comment les gérer → prévenable ✅