I/O performance has two aspects that you must distinguish: lag and throughput. One measures how long you have to wait for the first byte of a response, the other how long you have to wait additionally for the last byte.

As pjc50 said, if your network link is already saturated (no more packets can go through) it doesn't matter how smartly you organize your program - even a quantum computer couldn't help you.

But if your bottleneck is mainly lag (e.g. a web API that takes five seconds to respond at all), then sending requests in parallel will absolutely speed things up, and multi-threading is a convenient way of doing that.

I/O performance has two aspects that you must distinguish: latency and throughput. One measures how long you have to wait for the first byte of a response, the other how long you have to wait additionally for the last byte.

As pjc50 said, if your network link is already saturated (no more packets can go through) it doesn't matter how smartly you organize your program - even a quantum computer couldn't help you.

But if your bottleneck is mainly lag (e.g. a web API that takes five seconds to respond at all), then sending requests in parallel will absolutely speed things up, and multi-threading is a convenient way of doing that.