No clue how I am learning this only now, but better later than never: HTTPS keepAlive is not enabled by default in Node.js, and it has severe performance implications to network-intense applications.
Just to illustrate the impact, assuming that your server is hosted in us-central1 and it is talking to a service in us-east1, just the network latency is ~20ms. Since a TCP handshake is a 3-packet event, this means that ~60ms are going to be allocated just to establish TLS handshake.
You can test that with a simple script:
const got = require('got');
const main = async () => {
  const response0 = await got('https://posthog.com/');
  console.log(response0.timings.phases);
  const response1 = await got('https://posthog.com/');
  console.log(response1.timings.phases);
};
main();
In this scenario, the above will produce:
{
  wait: 1,
  dns: 20,
  tcp: 72,
  tls: 74,
  request: 0,
  firstByte: 79,
  download: 222,
  total: 468
}
{
  wait: 0,
  dns: 1,
  tcp: 67,
  tls: 69,
  request: 1,
  firstByte: 73,
  download: 234,
  total: 445
}
However, watch the total time if we enable keepAlive:
const got = require('got');
const https = require('https');
https.globalAgent = new https.Agent({ keepAlive:true });
const main = async () => {
  const response0 = await got('https://posthog.com/');
  console.log(response0.timings.phases);
  const response1 = await got('https://posthog.com/');
  console.log(response1.timings.phases);
};
main();
{
  wait: 1,
  dns: 27,
  tcp: 77,
  tls: 75,
  request: 0,
  firstByte: 75,
  download: 220,
  total: 475
}
{
  wait: 0,
  dns: 0,
  tcp: 0,
  tls: 0,
  request: 0,
  firstByte: 77,
  download: 83,
  total: 160
}
The second request is 70% faster than the first request!
If your application relies on making many HTTPS calls, then simply enabling keepAlive is going to result in a significant performance improvement.
 

 
    
Top comments (2)
Just wanted to add this caveat by pointing to this article: connectreport.com/blog/tuning-http...
That's Helpfull. :)