141

Will use of the debugging feature console.log reduce JavaScript execution performance? Will it affect the speed of script execution in production environments?

Is there an approach to disable console logs in production environments from a single configuration location?

Victor
  • 3,669
  • 3
  • 37
  • 42
Sudantha
  • 15,684
  • 43
  • 105
  • 161

11 Answers11

106

Actually, console.log is a lot slower than an empty function. Running this jsPerf test on my Chrome 38 gives stunning results:

  • when the browser console is closed, calling console.log is about 10 000 times slower than calling an empty function,
  • and when the console is open, calling it is as much as 100 000 times slower.

Not that you'll notice the performance lag if you have a reasonable number of console.… calls firing once (a hundred will take 2 ms on my install of Chrome – or 20 ms when the console is open). But if you log stuff to the console repeatedly – for instance, hooking it up through requestAnimationFrame – it can make things janky.

Update:

In this test I've also checked out the idea of a custom “hidden log” for production – having a variable which holds log messages, available on demand. It turns out to be

  • about 1 000 times faster than the native console.log,
  • and obviously 10 000 times faster if the user has his console open.
tomekwi
  • 2,048
  • 2
  • 21
  • 27
  • FWIW, I agree with Chris Nielsen [here](http://stackoverflow.com/a/1114232/2816199). In my opionion, debug info thrown in the user's face is unprofessional. – tomekwi Nov 12 '14 at 08:30
  • 2
    When a compiler sees an empty function, it executes nothing wether as it sees a line to execute it will have to run the function. the compiler simply doesn't run an empty, unused function as an optimisation. – SidOfc Apr 28 '15 at 13:05
  • 1
    @SidneyLiebrand thanks for the info, that’s good to know. The results of the second test can be optimized in the same way as `console.log` though. Both of them are functions which produce side-effects. – tomekwi Apr 28 '15 at 18:44
  • 2
    `console.log` by itself doesn't really impact performance in a way that you'll notice unless you bind it to a scroll / resize handler. These get called alot and if your browser has to send text to the console like 30/60x a second it can get ugly. And then there's that IE bug that didn't allow you to have `console.log`'s at all with the console closed :( – SidOfc Apr 29 '15 at 08:20
  • 1
    You’re absolutely right – I wrote that in my answer too. As a rule of thumb, I try to have no console calls in production code. But performance is not the reason – it’s rather because “its too easy for a layman to read your logs” as @Ramesh wrote. – tomekwi Apr 29 '15 at 13:00
  • BTW, I wrote this test while reviewing a library which shot tens of `console.log` messages per `mousemove` event. That did make a difference. – tomekwi Apr 29 '15 at 13:02
  • since jsperf is blocking me from creating a test, i made this fiddle that tests wrapping `console.log` with your own function that blocks it based on some `var`. I wanted to be sure that leaving my wrapped log statements in the code wouldn't hurt perf if the message included an object even if muted in prod. Turns out to be okay (negligible). https://jsfiddle.net/hcvycn9q/ BTW, you need to pop open the console to see results. – casey Apr 06 '16 at 23:23
  • 1
    `logging-on x 3,179 ops/sec ±2.07% (56 runs sampled)` `logging-off x 56,058,330 ops/sec ±2.87% (56 runs sampled)` `logging-off-stringify x 1,812,379 ops/sec ±3.50% (58 runs sampled)` `log-nothing x 59,509,998 ops/sec ±2.63% (59 runs sampled)` – casey Apr 06 '16 at 23:27
  • 1
    @tomekwi Both the links you provided are temporarily unavailable at the time of writing this comment. could you check ? – Ĭsααc tիε βöss Sep 27 '16 at 10:30
  • Brilliant answer! What performance will be if we have not empty function, but function with `return` in its head? I have a `console.log` wrapped in `console_color` so would like to do something like `if (!debug) return` in the wrapper. – Systems Rebooter May 26 '20 at 08:37
  • 2
    4 years later (checking @Ĭsααctիεβöss's comment), the links are still broken. – Aj Otto Nov 23 '20 at 11:37
  • 1
    They're on the wayback machine: https://web.archive.org/web/20170207014319/http://jsperf.com/console-log1337/14 https://web.archive.org/web/20170205185215/http://jsperf.com/console-log1337/16 – V. Rubinetti Apr 04 '22 at 16:40
  • Does this hold true in Server Side environments too like NodeJS or the new one Deno? – Anshul Sahni Jul 14 '22 at 13:42
  • I have not tested this server side @AnshulSahni – tomekwi Dec 30 '22 at 22:33
76

If you are going to have this on a public site or something, anyone with little knowledge on using the developer tools can read your debug messages. Depending on what you are logging, this may not be a desirable behavior.

One of the best approaches is to wrap the console.log in one of your methods, and where you can check for conditions and execute it. In a production build, you can avoid having these functions. This Stack Overflow question talks in details about how to do the same using the Closure compiler.

So, to answer your questions:

  1. Yes, it will reduce the speed, though only negligibly.
  2. But, don't use it as it's too easy for a person to read your logs.
  3. The answers to this question may give you hints on how to remove them from production.
Ramesh
  • 13,043
  • 3
  • 52
  • 88
  • thanks but still wrapping the `conosle.log` will still make a hit to the overridden function isn't it ? – Sudantha Jul 11 '12 at 05:58
  • @Sudantha Depends on how to implement it. Check this answer http://stackoverflow.com/a/5969752/30594. If implemented with write compiler flags, it would completely remove your call to log function. – Ramesh Jul 11 '12 at 06:00
  • thanks most probably we will implement this solution (answer for closure compiler) – Sudantha Jul 11 '12 at 06:13
  • 19
    Just a note - using `console.log` to log objects does cause memory leak as browser retains the object structure to allow developers to expand the log. – Shamasis Bhattacharya May 26 '14 at 11:25
  • 4
    @Gajus [Your edit is being discussed on Meta](http://meta.stackoverflow.com/q/321530/2982225) – Infinite Recursion Apr 22 '16 at 12:47
  • 21
    "it's too easy for a person to read your logs" — How is this a problem? It's JavaScript, they already have full access to the source code! – Quentin Apr 24 '16 at 21:31
  • It makes things more easy. – Ramesh Apr 27 '16 at 08:44
  • 3
    @Quentin That's true that the source code is already accessible, but the real risk comes in when that code is executed as there may be sensitive data being processed (such as personal customer data from a database on the back end). The best practice in my organization (and many others) is to never use console.log in production code. – BluDragn Dec 08 '16 at 15:09
  • 4
    @BluDragn — Why are you sending personal customer data, which you don't trust the customer with, to the customer? Even without console.log they can just look in the Network tab. – Quentin Dec 08 '16 at 15:12
  • @Quentin You're right on personal information, that was a bad example on my part. What I'm trying to get at is that there may be aspects of what you are processing and how you are processing it that shouldn't be exposed in the console. At the very least it can be confusing to users who aren't sure what they are seeing and if it indicates a problem. Good catch ;) – BluDragn Dec 09 '16 at 17:50
  • 1
    but anyone can write console.log() into the page's javascript, so most of this answer is spent on a pointless point – Andrew Mar 09 '17 at 19:37
  • 6
    Just to chime in: I just discovered, spamming the console.log even with the same static text (no object or array; literally just console.log('test') would do it) also causes a performance hit. This came to my attention as I was logging "called" within a function that got invoked on hundreds of React components during re-renders. The mere presence of the logging code caused very noticeable stutter during frequent updates. – SikoSoft Apr 28 '18 at 20:01
  • 3
    if people can hack your site because of your console.debug entries, they can hack it without it. But: if you need to debug production, and you have no debug to help you, well, that'll take a lot longer to fix. – Toskan May 12 '20 at 17:21
29
const DEBUG = true / false
DEBUG && console.log('string')
Sergey Guns
  • 451
  • 5
  • 4
20

Will use of the debugging feature console.log reduce JavaScript execution performance? Will it affect the speed of script execution in production environments?

Of course, console.log() will reduce your program's performance since it takes computational time.

Is there an approach to disable console logs in production environments from a single configuration location?

Put this code at the beginning of your script to override the standard console.log function to an empty function.

console.log = function () { };
holydragon
  • 6,158
  • 6
  • 39
  • 62
  • 3
    This seems to be one of the simplest solutions for disabling console logs in production environment. Wondering why it does not have more attention! We can control the definition of this empty function under a variable which we can toggle as true/false depending on which environment we are working on (prod or dev) – Anshuman Manral Mar 05 '19 at 10:24
  • 4
    This is such a brilliant answer! Thanks! – Systems Rebooter May 26 '20 at 08:46
13

If you create a shortcut to the console in a common core script, eg:

var con = console;

and then use con.log("message") or con.error("error message") throughout your code, on production you can simply rewire con in the core location to:

var con = {
    log: function() {},
    error: function() {},
    debug: function() {}
}
sq2
  • 575
  • 4
  • 11
8

Any function call will slightly reduce performance. But a few console.log's should not have any noticeable effect.

However it will throw undefined errors in older browsers that don't support console

Petah
  • 45,477
  • 28
  • 157
  • 213
4

The performance hit will be minimal, however in older browsers it will cause JavaScript errors if the users browsers console is not open log is not a function of undefined. This means all JavaScript code after the console.log call will not execute.

You can create a wrapper to check if window.console is a valid object, and then call console.log in the wrapper. Something simple like this would work:

window.log = (function(console) {
    var canLog = !!console;
    return function(txt) {
        if(canLog) console.log('log: ' + txt);
    };
})(window.console);

log('my message'); //log: my message

Here is a fiddle: http://jsfiddle.net/enDDV/

Paul
  • 12,392
  • 4
  • 48
  • 58
3

I made this jsPerf test: http://jsperf.com/console-log1337

It doesn't seem to take any longer than other function calls.

What about browsers that doesn't have a console API? If you need to use console.log for debugging, you might include a script in your production deployment to override the console API, like Paul suggests in his answer.

Jørgen
  • 8,820
  • 9
  • 47
  • 67
  • if i can select two answers this will go to top – Sudantha Jul 11 '12 at 06:14
  • 1
    Your test not only adds a console.log call, but also execute the same jquery operation twice. I've created the following revision of your test, hope it helps: http://jsperf.com/console-log1337/7 PS: thanks, I didn't know about jsperf.com :) – dubrox Oct 15 '13 at 16:06
  • 2
    It actually does seem to be a lot slower than a normal function call. In a direct duel the results are incomparable: http://jsperf.com/console-log1337/14 – tomekwi Nov 05 '14 at 09:45
  • 1
    Bad answer. Not even remotely correct. Wishful thinking up-votes as @tomekwi demonstrates the difference is remarkable. I've done several real world tests myself and can absolutely say without a shadow of a doubt spamming console.log definitely causes a performance hit. A few logs here and there every second or two, no big deal, but log something frequently (on frame updates, re-renders of massive components) and the difference with and without console.log is night and day. – SikoSoft Apr 28 '18 at 20:09
1

I do it this way to maintain original signature of console methods. In a common location, loaded before any other JS:

var DEBUG = false; // or true 

Then throughout code

if (DEBUG) console.log("message", obj, "etc");
if (DEBUG) console.warn("something is not right", obj, "etc");
ow3n
  • 5,974
  • 4
  • 53
  • 51
1

I prefer it doing this way:

export const println = (*args,) => {
   if(process.env.NODE_ENV === "development") console.log(args)
}

and then use println everywhere in your code.

Shivam Sahil
  • 4,055
  • 3
  • 31
  • 62
0

You can also test if if you're on production before replacing console.log with a empty function: (example on Vue)

//* disable console.log on production: 
if (import.meta.env.MODE === 'production') console.log = function () {};
Lepy
  • 152
  • 1
  • 12