Pourquoi faut-il supprimer vos logs en production ?

La console est souvent utilisée lors du développement pour vérifier que les différentes étapes d'un code fonctionnent correctement, mais ces logs ont-ils un impact sur les performances de votre code ?

À noter que la meilleure méthode est d**'utiliser un debugger intégré à votre IDE si possible !**

L'impact en termes de performances

S'ils n'ont qu'un impact minime lorsqu'ils sont exécutés un par un, les logs en production peuvent avoir un impact très conséquent sur les performances de votre code, notamment quand ils sont présent dans une boucle, ou dans un morceau de code très fréquemment appelé par vos utilisateurs.

Pour simuler cette perte de performance, j'ai créé un script de benchmark très simple, dont j'ai mesuré le temps d'exécution avec console.time :

// Version sans logs
console.time("no-log");
for(let i=0,j=0; i < 1000; i++){
    j++;
}
console.timeEnd("no-log");

//Version avec logs
console.time("log");
for(let i=0,j=0; i < 1000; i++){
    j++;
    console.log(j);
}
console.timeEnd("log");

Le principe est d'exécuter un morceau de code simple (une incrémentation) au sein d'une boucle de 1000 itérations, une fois sans logs, et une autre fois avec un log d'activé.

Résultats

Pour que les résultats soient suffisamment probants, j'ai exécuté ce script sur trois environnements différents, dont deux sur des machines différentes.

Environnement

Temps avec log

Temps sans log

Firefox (Laptop)

158ms

3ms

NodeJS (Laptop)

570.3ms

6.2ms

NodeJS (VPS OVH)

139.450ms

15.8ms

La différence est flagrante, selon l'environnement, notre petit log enfermé dans sa boucle multiplie par 9, 50 et même presque 100 le temps d'exécution de notre code, c'est énorme.

Imaginez si ce log est présent dans une boucle, appelée dans une partie très demandée d'une de vos APIs, la perte est considérable et peut devenir un goulot d'étranglement selon votre charge utilisateur.

L'impact en termes de sécurité

Logger des chaînes de caractères comme "test", "coucou" et j'en passe... n'a évidemment pas d'impact sur la sécurité de votre application.

Mais imaginons un scénario :

Vous utilisez, derrière votre API, une base de données chiffrée car les données de vos utilisateurs ne doivent en aucun cas être consultable par quelqu'un d'autre que la personne elle-même.

Et maintenant, devinez quel sera l'impact d'un simple console.log(user) qui part en production ?

Les données des utilisateurs finiront alors en clair dans les fichiers de logs, sur le serveur de production...

Une cible de choix pour un pirate, mais également consultable par n'importe quel membre de l'équipe de développement. Adieu la base de données chiffrée.

Solutions

Pour palier à ce problème, il existe deux solutions pour être sûr de n'oublier aucun console.log en production :

À noter que pour les deux solutions, vous pouvez choisir de ne cibler que les console.log et pas les console.warn ou console.error !

ESLint

ESLint est un linter, ce qui signifie qu'il va parcourir votre code afin de détecter si certaines pratiques vont à l'encontre de sa configuration. Vous pouvez donc ajouter la règle "no-console" dont la documentation est ci-dessous pour être averti d'un console.log que vous auriez oublié :

Babel

Babel est un transpiler, ce qui signifie qu'il va prendre votre code pour le compiler de manière transversale d'une version d'un langage à une autre, et y appliquer des modifications que vous aurez déterminé.

Avec le plugin "transform-remove-console", Babel supprimera automatiquement tous les appels console.log lors de la transpilation, comme l'indique la documentation  :

Conclusion

Je privilégierai plutôt la configuration ESLint pour cette tâche, car il est possible de vouloir garder certains logs précis, notamment en NodeJS, et il est possible d'ajouter des exceptions dans le code pour ignorer une règle ESLint au cas par cas.