While it's theoretically possible for replication on the Publishing database to be affecting your application's write performance to that database (dependent on many factors) it's less likely that's your issue.
When you change servers, even if it's an exact replica server to the same specs (hardware and software) and same exact version of SQL Server, there's still going to be performance affecting differences such as statistics that will need to be calculated (and potentially change on recalculation) on the new server.
One way it's theoretically possible is if your Distributor lives on the Publisher's server, and is causing resource contention, but this is highly unlikely to be the case. Depending on which kind of replication you're using, there may be other applicable ways it can affect performance as well. For example, Snapshot Replication is more resource intensive than Transactional Replication when it's creates a snapshot (since it's recreating everything, not just the differentials, and locks the table the entire time it's snapshotting it), and therefore isn't meant to be used for as real-time of data synchronizations as Transactional Replication is meant for. If you were using Snapshot Replication and had it scheduled very frequently (e.g. every 5 minutes) then I could see that being more of a potential problem.
But most likely your issue is arising from somewhere else. I'd recommend comparing the old execution plan (if possible) to the new one, and comparing the Time and I/O statistics to try to trace your issue for your application's slow queries. You'll more likely find the root cause going that route.