Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed.
But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).
Yes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages.
I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.
I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand.
And I am painfully aware that the bottleneck is the code, not the network.