In the example above, the text I am for will be printed 1000 times; however I am forEach will be printed only twice.

Avoid for…in

Especially in the case of object cloning, I’ve seen people using for...in loop. Unfortunately for...in is designed in such a way that it can never be performant. So avoid using it as much as you can. You can check other ways to clone objects in JavaScript.

Array literals are better than push

If you use an array literal, v8 will always understand the structure better than using an empty array and then pushing elements in it.

// good
var arr = [1,2,6,2,10,3];

// bad
var arr = [];
arr.push(1);
arr.push(2);
arr.push(6);
arr.push(2);
arr.push(10);
arr.push(3);

Now you may say who choose the second one? Everyone go with the first approach only.
No, not exactly. Cause sometimes, we unknowingly code like the second one. For an example, suppose you are modifying each and every element of an array with some certain rules and want to create a new array our of that.
Often developers creates an empty array first, then iterates on the previous array using forEach or something, and then after the operations pushes the modified elements in the new array. But the better way will be to use Array.map() method.

Web-workers & Shared buffer

JavaScript is single threaded. The same thread is used for event-loop. So your new request handling in node.js and dom rendering in browser, everything is processed in a non-parallel way.

So, whenever you have a task which takes more computing time, you should delegate it to some web-workers. In case of node.js, there is no in built worker, but you can use an npm module or spawn a new process for the same.

One common problem working with workers can be how to sync with them (without posting a message after finish). Well, SharedArrayBuffer can be a handy way for that.

It seems SharedArrayBuffer is disabled by default since 5th January 2018; but this (or kind of this) is already in stage 4 as ECMA proposal.

setImmediate over setTimeout(fn,0)

This is a point only for node.js developer. Many of the developers don’t use setImmediate or process.nextTick and go with setTimeout(fn, 0) to make a part of their program asynchronous.

Well, some of our experiments about setImmediate vs setTimeout(fn, 0) says, setImmediate can be upto 200 times (yes, times, not just percent) faster than setTimeout(fn, 0).

So use setImmediate more frequently than setTimeout; but be cautious about using process.nextTick unless you understand how it works.

Avoid static file hosting

The recommendation is not to serve static files from your node.js server.
Why? Because node is not made for that. Node can best serve your tcp/http requests, cause it works completely asynchronous.

If you are keeping it busy to read static files (this operation is handled by libUV’s threadpool), the performance will degrade, cause libUV has a predefined number of threads (by default 4), which you can extend upto 128 only. If there are more file reading tasks than the assigned threadpool size, the process will start getting synchronous.

Promise.all (async await)

Native Promises by ES6 definitely made our life easier. But what came up like a blessing is async await. Now we can write code which will look synchronous but will work asynchronous.

But, sometimes developers become too much comfortable and unknowingly create unnecessary synchronous code. One of the example is as follows.

// bad
async function someAsyncFunc() {
    const user = await asyncGetUser();
    const categories = await asyncGetCategories();
    const mapping = await asyncMapUserWithCategory(user, categories);
}

// good
async function someAsyncFunc() {
    const [user, categories] = await Promise.all([
        asyncGetUser(),
        asyncGetCategories()
    ]);
    const mapping = await asyncMapUserWithCategory(user, categories);
}

This is a very common scenario that for multiple async calls developers wait for one after another. However when you promisify them all using something like Promise.all(), they can be resolved concurrently.

Remove event listeners

We often use event listeners, especially in the client side. And often due to various reasons we may remove the element the event listener is attached to.
But one noticeable thing is event listeners are not removed if the element it attached to is destroyed. A repetition of this can cause memory leaks.

Thus you should be aware of when elements are getting destroyed and also remove your event listeners with them.

Use native instead of client libraries

Before the revolutionary node.js came into the picture, JavaScript was only used in client side programming.
Unfortunately the developers don’t know which user’s browsers is using what version of ECMAScript. This is why the JavaScript libraries usually used in the client side writes polyfills for different versions and they become a bit heavier.

But when you are using node.js you always know the exact version the server is running into. Thus, instead of using client side libraries for promises, colored console or something like that, it is always preferable to use the native code.

Binary modules

If you are developing big modules for your application and you want to take the performance to next level; you should compile and convert them to binary modules.

LinkedIn is one of the companies which uses node.js as their backend and they follow this practice.

Avoid O(n), try O(1)

I have seen developers to unnecessarily going with O(n) complexity rather than O(1).

In JavaScript objects are loosely typed and you can literally attach anything (which can be converted to string) as a key or property.

Now, suppose you have a list of N students with their roll number (which is unique) and totalMarks. If someone enters the roll number in a text field you display the totalMarks of that particular student in the page.
The common representation is you will create an array and push all your student objects there and when someone enters a roll number, you will iterate on the students array and find that particular student and display the marks.

In this way you are on complexity O(n). But if you were using an object instead of an array and set the roll number as a property and the corresponding student object as its value, things would have become O(1) for you, cause whenever someone enters a roll number, you had to show studentsObj[rollNumber] object.

This doesn’t mean you always should use an object instead of array. This is completely on the situation, problem statement and requirements.

Conclusion

Increasing your server’s configuration, scaling it out, distributing the services are some of the very well known processes to make your application performant.
But if your code is causing memory leaks or sequential processing; all those dev-ops steps will not able to save your server getting slowed down or even crashed.

Thus, while coding (irrespective of the language), you must be aware of all good practices, edge cases and performance points.

Happy coding :)