Remember...

...the wise words of Donald Knuth:

Premature optimization is the root of all evil

That aside...

some pretty obvious rules to follow:

• Use asynchronous versions of functions (e.g. readFile instead of readFileSync) wherever possible.
• Don't read from the file system in a request handler. Rather read the file beforehand, in your app's startup phase (it's ok to use synchronous versions of functions during this phase). This rule applies to other types of IO operations as well, but most of the time you use other forms of IO, they're dynamic and can't be guaranteed to work appropriately in the startup phase, thus this rule can't be applied in those cases. It's best to use your discretion.
• Try not to nest function definitions unless absolutely required. Otherwise, you'll be defining that function each time the parent function runs, which V8 will have a hard time optimizing.
• Also try to extract any try / catch statements to their own function, as V8 has a hard time optimizing functions that contain try / catch operators. Better yet, use a continuation monad like Promises or Tasks/Futures for async work that will emit errors and rely on the rejection mechanism of your monad. For sync work, consider an Either monad.
• Avoid leaking function arguments. That means instead of _slice.call(arguments), define an empty array and loop through the arguments object, pushing each item into said array.
• Make sure to perform necessary cleanup - unbind event listeners when no longer needed, close DB connections when no longer needed, close socket connections when no longer needed, etc.
• If your app consists of pure functions, memoize them by implementing a caching mechanism. lodash.memoize(fn) will work.
• Implement a request caching mechanism for your server endpoints that fetch from a database. Doing this with Redis is pretty easy.
• Offload the responsibility of serving static assets to a reverse proxy (like Nginx). This means less work for your Node.js application.
• If your node app is a website, then be sure to serve a favicon. Browsers tend to request them for every route in your app, paying no mind to whether or not they exist. A lack of a favicon results in extra load on your server, slowing down performance. (reference)

For anything outside of the realm of these rules, you can do something about that too...

Profiling Performance

Run your Node.js app with the profiler enabled:

$ node --prof server.js

This will generate a log file ({id} is just a placeholder):

isolate-{id}-v8.log

At this point, if you have Node v4.x or above, you can run:

$ node --prof-process isolate-{id}-v8.log

After some time, your console should have some output on how many CPU ticks were spent on different parts of your app. I won't go into too much detail on how to refer to this output (you can research it yourself) as I prefer to pass the log file into Chrome DevTools:

Just click the "load" button and import your log file from the previous step. Your profile should appear on the left hand sidebar, where you can click to access it and see an overview of your app's performance profile. There are 3 modes: bottom up (heavy), top down and chart. I find chart to be the most easy to grep.

The chart above is just a profile for a minified browser build, so passing in your node.js log file won't look as "hieroglyphic" as this example. You can click on any of those data points to open the DevTools source editor to see the source code - to the left will be a sidebar that contains numbers - these numbers represent the number of milliseconds the function defined on that line took to execute.