Why should you remove your logs in production?

NicolasBrondinBernard

Author
@NicolasBrondinBernard

Do logs have an impact on the performance of your applications? TLDR: Yes.

Article published on 09/04/2021, last updated on 10/08/2026

The console is often used during development to check that the various steps of a piece of code are working properly, but do these logs have an impact on your code's performance?

Note that the best method is to use a debugger built into your IDE if possible!

The impact in terms of performance

While they have only a minimal impact when executed one by one, logs in production can have a very significant impact on your code's performance, especially when they are present in a loop, or in a piece of code very frequently called by your users.

To simulate this performance loss, I created a very simple benchmark script, whose execution time I measured with 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");

The principle is to execute a simple piece of code (an increment) within a loop of 1000 iterations, once without logs, and once with a log enabled.

Results

For the results to be sufficiently convincing, I ran this script on three different environments, two of which were on different machines.

Environment Time with log Time without log
Firefox (Laptop) 158ms 3ms
NodeJS (Laptop) 570.3ms 6.2ms
NodeJS (VPS OVH) 139.450ms 15.8ms

The difference is glaring, depending on the environment, our little log locked inside its loop multiplies our code's execution time by 9, 50, and even almost 100, which is huge.

Imagine if this log is present in a loop, called within a heavily used part of one of your APIs, the loss is considerable and can become a bottleneck depending on your user load.

The impact in terms of security

Logging strings like "test", "hello" and so on... obviously has no impact on your application's security.

But let's imagine a scenario: Behind your API, you use an encrypted database because your users' data must under no circumstances be viewable by anyone other than the person themselves.

And now, guess what the impact will be of a simple console.log(user) that makes it into production?

User data will then end up in plain text in the log files, on the production server...

A prime target for a hacker, but also viewable by any member of the development team. Goodbye encrypted database.

Solutions

To address this problem, there are two solutions to make sure you don't forget any console.log in production:

Note that for both solutions, you can choose to target only console.log and not console.warn or console.error!

ESLint

ESLint is a linter, which means it will go through your code to detect whether certain practices go against its configuration. You can therefore add the "no-console" rule, whose documentation is below, to be warned about a console.log you may have forgotten:

no-console - Rules

Babel

Babel is a transpiler, which means it takes your code and compiles it across the board from one version of a language to another, applying modifications that you have determined.

With the "transform-remove-console" plugin, Babel will automatically remove all console.log calls during transpilation, as stated in the documentation:

babel-plugin-transform-remove-console · Babel

Conclusion

I would rather favor the ESLint configuration for this task, because you might want to keep certain specific logs, especially in NodeJS, and it is possible to add exceptions in the code to ignore an ESLint rule on a case-by-case basis.


Daria Nepriakhina sur Unsplash

Finished reading this article?
Our complete courses
Take it to the next level with our courses!

Complete courses, exercises and certificates to really learn programming!

4.8 average rating

Comments (0)

to leave a comment

No comments yet