It seems that you've followed [1] by the similarity of what that suggests to what you've suggested. tcp_nodelay seems to force it to not wait 0.2 seconds, which nginx does so that it doesn't send lots of really small packets. I can see this increasing speed by 200ms (a lot) but increases network traffic as a cost.
tcp_nopush seems to be about optimising each packet sent, reducing the total size of them.
Interesting stuff though!
[1] https://t37.net/nginx-optimization-understanding-sendfile-tc...
Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2).
In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again.
That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".
The problem with webapps is a compounding effect of many requests.
a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that.
b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.
Variation in page load times far outweighed any difference the config change might have brought.
So, YMMV.
From a theoretical standpoint I agree http/2 should help (although in practice I didn't measure any difference). I can't see why tcp_nodelay would help except in extremely niche applications (sending tiny responses with lots of pauses?)
Indeed, given that HTTP/2 forces TLS (for any mainstream browser) which forces an extra RTT, for light pages my evidence is that HTTP/2 makes things marginally worse...
RTT hurts in my world.
Why would you use nginx for security? I see over 100 CVEs for nginx.
This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness.
If you want security, why not use a (possibly slower) simpler product written in a safer language?
Of course, it doesn't support HTTPS or HTTP/2, so... there's that.
Also, lots of CVEs indicate only one thing: that lots of people are checking it.
Also that it has lots of vulnerabilities.
Instead, you could use a product that's secure by design.
Doesn't it also mean they're finding lots of problems with it?
Will wait for something else.
Add these lines to your nginx config file:
It reduced our page load time by around 75%, and more for people accessing the site from the other side of the world.