Is Firefox a Pig

SYNTHÈSE STRUCTURÉE

Le problème : Firefox et la RAM sous Linux

L’intervenant décrit un scénario courant : « Je me retrouve souvent avec plus de 80 onglets de navigateur ouverts, et parfois Kdenlive qui tourne sur une machine avec 16 Go de RAM. » Lorsque l’utilisation mémoire dépasse 12-14 Go, le système commence à swapper sur le disque, même avec un SSD rapide, ce qui ralentit considérablement l’expérience. Le problème n’est pas imputable à Linux, mais à la manière dont Firefox gère la mémoire au fil du temps.

La gestion mémoire de Linux : page cache et buffers

Le noyau Linux utilise un page cache : les données lues depuis le disque restent en RAM après usage, ce qui accélère les accès ultérieurs. Ce cache peut occuper 70 à 80 % de la RAM, mais il est libéré automatiquement dès qu’une application en a besoin. La commande free -h affiche souvent une RAM pleine, mais la majeure partie est en réalité du cache réutilisable. Les buffers gèrent les entrées/sorties disque et sont aussi dynamiques.

L’architecture de Firefox et ses content processes

Firefox utilise le moteur de rendu Gecko. Chaque onglet crée un content process (processus de contenu) pour isoler sécurité et stabilité. Le problème survient quand ces processus accumulent de la mémoire sans la libérer correctement, surtout avec des sites JavaScript lourds (React, Angular, Vue.js) qui génèrent des memory leaks (fuites mémoire). Firefox utilise son propre allocateur mémoire, jemalloc, qui peut parfois mal interagir avec le gestionnaire mémoire du noyau.

Première tentative : extensions de déchargement d’onglets

L’intervenant a installé des extensions comme Auto Tab Discard ou The Great Suspender. Le principe : geler un onglet inactif pour libérer la mémoire, tout en conservant le titre et l’URL. Cela fonctionne, mais avec des limites : « Les formulaires peuvent être perdus, et les sites avec une authentification complexe peuvent casser. »

Optimisations via about:config

L’intervenant a modifié plusieurs paramètres dans about:config pour réduire la consommation mémoire :

• Désactiver le cache disque : browser.cache.disk.enabled → false. L’idée est d’éviter la gestion simultanée de la RAM et du disque.
• Forcer le cache en RAM : browser.cache.memory.capacity → 512 (Mo). Le cache reste en mémoire rapide, géré directement par le noyau.
• Limiter l’historique de navigation : browser.sessionhistory.max_total_viewers → 2 (au lieu de -1 pour illimité). Moins de pages mises en cache pour la navigation avant/arrière.
• Désactiver la lecture automatique des vidéos : media.autoplay.default → 5. Les vidéos en autoplay sont une source majeure de consommation CPU et mémoire.
• Activer WebRender : gfx.webrender.all → true. WebRender utilise l’accélération GPU via les pilotes open-source Mesa.
• Réduire la fréquence de sauvegarde de session : browser.sessionstore.interval → 30000 (30 secondes au lieu de 15). La sérialisation constante de la mémoire avec 80 onglets est coûteuse.
• Réduire le nombre de content processes : dom.ipc.processCount → 4 (au lieu de 8). Moins de processus réduit la surcharge système.
• Limiter le décodage des images : image.mem.decode_bytes_at_a_time → 8192 (au lieu de 6384). Les images haute résolution consomment beaucoup de mémoire lors du décodage.

Résultats mitigés des optimisations

Les réglages ont permis une baisse de la consommation mémoire de 20 à 30 %, mais le comportement sous-jacent persiste : « Firefox continue d’accumuler de la RAM au fil du temps, et il doit être redémarré tous les deux à trois jours pour retrouver de la réactivité. » L’intervenant conclut que le problème est architectural : Firefox essaie d’être tout à la fois (sécurité, rapidité, respect de la vie privée, compatibilité), mais le web moderne est devenu trop lourd.

Le vrai problème : la complexité du web

L’intervenant résume : « Le web est un troupeau de cochons frénétiques. » Chaque site est une application, chaque page charge des mégaoctets de JavaScript, chaque réseau social est un écosystème de widgets et de traqueurs. Il reconnaît aussi sa propre responsabilité : ouvrir plus de 100 onglets avec 16 Go de RAM, un éditeur vidéo et OpenOffice, c’est peut-être excessif. Il compare avec le début des années 2000, où Firefox gérait des dizaines d’onglets sans ralentir.

CONCEPTS CLÉS

• Page cache : Mécanisme du noyau Linux qui conserve en RAM les données lues depuis le disque pour accélérer les accès ultérieurs, libéré automatiquement si nécessaire.
• Content process : Processus séparé créé par Firefox pour chaque onglet, assurant isolation et sécurité, mais pouvant accumuler de la mémoire.
• jemalloc : Allocateur mémoire interne de Firefox, conçu pour être plus efficace que malloc standard, mais parfois mal adapté au gestionnaire mémoire du noyau.
• WebRender : Système de rendu de Firefox utilisant l’accélération GPU pour améliorer les performances graphiques.
• Memory leak : Fuite mémoire où un programme ne libère pas la mémoire allouée après usage, entraînant une consommation croissante.

CONCLUSION

Le message principal est que la consommation excessive de RAM de Firefox sous Linux n’est pas un défaut isolé du navigateur, mais le reflet d’un web moderne devenu trop lourd et complexe. Les optimisations via about:config et les extensions peuvent réduire l’empreinte mémoire de 20 à 30 %, mais ne résolvent pas le problème architectural. L’intervenant invite à repenser nos attentes : « Parfois, la simplicité bat la complexité. Parfois, un navigateur qui fait son travail sans grandes promesses est meilleur qu’un autre qui essaie de révolutionner le web tout en dévorant toute votre RAM. » Pour un administrateur système, cela signifie qu’il faut accepter de redémarrer Firefox régulièrement, ou envisager des alternatives plus légères, tout en gardant un œil critique sur l’évolution du web.