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 de suivre une méthode de conception pilotée par les tests (TDD), ce qui évite d'utiliser des logs pour débugger le code.

L'impact en terme 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 < 1000000; 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.

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.

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é :

no-console - Rules

A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.

ESLint - Pluggable JavaScript linter

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  :

babel-plugin-transform-remove-console · Babel

## Example

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.

J'espère que cet article vous aura plu, et à bientôt sur le blog !

À propos de l'auteur

Hello, je suis Nicolas Brondin-Bernard, ingénieur web indépendant depuis 2015 passionné par le partage d'expériences et de connaissances.

Aujourd'hui je suis aussi coach pour développeurs web juniors, tu peux me contacter sur nicolas@brondin.com, sur mon site ou devenir membre de ma newsletter pour ne jamais louper le meilleur article de la semaine et être tenu au courant de mes projets !

Photo par Daria Nepriakhina sur Unsplash