To "improve query" response on reading data, replication will help. You could write away to your primary and read from secondaries to distribute the queries. Also the primary then is relieved of the expensive reads, and can be busy with only writing. Just be aware that there can be some lag on the data. For example a forum, it's not 100% necessary that readers can see the post within milliseconds after the insert. 1 or 2 seconds are acceptable.
The biggest advantage of replication is "backup and high availability" in case your primary goes down.
There is a some improvement with sharding if you choose a good shard key. Writing queries away 'might' be distributed if you do that correctly.
The main reason for sharding is to "horizontally expand your database". Working with big data, and not wanting to create/insert bigger and bigger disks ... you can just create new servers next to it, as much as you want. So, instead of maintaining 1 disk of 10TB, you could have 10 server is 1TB and grow bit by bit.
So, both can improve, ... on a write intensive system you might want to choose sharding, ... on a read intensive system, replica might be advised. But if you have a lot of data, choose sharding with replicas.
Example:
Server 1 : Shard1Repl1 + Config (datacenter/zone/network 1) write
Server 2 : Shard1Repl2 (datacenter/zone/network 2) read
Server 3 : Shard2Repl1 (datacenter/zone/network 1) write
Server 4 : Shard2Repl2 + Config (datacenter/zone/network 2) read
Server 5 : Shard1Arbiter + Shard2Arbiter + Config (datacenter/zone/network 3) small server addon