The fact that JSON is used so commonly for web stuff seems like an argument against wasting your time optimizing it. Network round trip is almost always going to dominate.

If you're pushing data around on disk where the serialization library is your bottleneck, pick a better format.

You’re assuming request-response round trip between each call to encode/decode. Streaming large objects/NDJSON would still have serialization bottleneck. (See elasticsearch/opensearch for a real life use case)

But in that case your last point still stands: pick a better format

There is no better human-readable format. I looked. The only alternative i considered was Amazon Ion but it proved to bring no additional value compared to json.

This is an interesting perversion of Amdahl's law.

Yes, if you are looking at a single request-response interaction over the Internet in isolation and observing against wall clock time, the time spent on JSON (de-)serialization (unless egregiously atrocious) will usually be insignificant.

But that's just one perspective. If we look at CPU time instead of wall clock time, the JSON may dominate over the network calls. Moreover, in a language like Go, which can easily handle tens to hundreds of thousands of parked green threads waiting for network activity, the time spent on JSON can actually be a significant factor in request throughput. Even "just" doubling RPS from 10k to 20k would mean using half as much energy (or half as much cloud compute spend etc.) per request.

Changing formats (esp to a low-overhead binary one) might yield better performance still, but it will also have costs, both in time spent making the change (which could take months) and adapting to it (new tools, new log formats, new training, etc.).