Static/manual diff is between you and the pool, most common is adding "+" after the wallet, but there's no guarantee it will be accepted or honored.

I've written about this before, but Nicehash and CN GPU mining really is a bumpy ride. The job switch time for CN at Nicehash can be really short during long periods, new jobs sent out every 5-10 secs. The way you run CN on a GPU (and this goes for all miners) is that you fire away 1000-2000 hashes that are computed in parallel, but it takes 1-1.5 secs before they are all done, and they pretty much all finish at the same time. When you run against a pool that (1) send out new jobs every 5-20 secs and (2) will reject shares for most previous jobs, you will waste hash capacity one way or the other as new jobs will be received when a hash round is being computed. You can either let the hash round complete and send any shares anyway hoping the pool will accept them, or you can introduce an early abort mechanism where the work in the ongoing hash round is wasted whenever a new job is received. Both approaches will have an impact on your realized hashrate vs your theoretical miner hashrate.

For Nanopool, I'm a little surprised though. As long as there is no new network block, and a new job is only sent out due to e.g. a new ntime value in the block header or new pending txns in the network, shares for the previous job should be accepted. For a 2 min block time network, you should then expect maybe ~1% rejected shares, assuming some additional network latency as well.