To understand what's happening, I'd suggest capturing some metrics.
First, query performance metrics. You're posting in the SQL Server 2012 forum. Assuming that's what you're running, the best tool for the job is Extended Events (if it was 2016 or better, we can also add Query Store). So, I'd suggest creating a session with rpc_completed and sql_batch_completed as the events you're monitoring. They'll allow you to understand query behavior over time. This can produce a lot of data, so, three things. First, output to a file and then consume that. Second, filter to a particular database, one at a time. Third, only capture information for a relatively short period, say 48 hours, or maybe less.
Data in hand, look for the top queries in various categories: most frequently called, longest running, most cpu, most i/o, most memory. You'll probably see a pattern that it's a few queries, or a few common query patterns causing most of the problems.
So, second set of data. For the queries in question, determine when they're running faster, and when they're running slower. Then, capture the execution plans at those times.
With the metrics in hand and the execution plans, you can determine what the heck is happening.
For an index rebuild, and just the defragmentation aspects of the rebuild alone, to help with performance, you'd expect to see lots and lots of scans in the plans. Second, you won't see the plans change much, if at all, between the times that it's running faster & slower. If this is what you're seeing, there's a chance that fragmentation itself is causing your problems. Honestly, this is somewhat unlikely.
What's more likely has already been mentioned. Statistics. Rebuilding indexes also updates the statistics with a full scan. Evidence that this is the solution will be changes in the execution plans. Slow plans will be different than fast plans. Further, you'll see the plans change immediately after the index rebuild. This is a strong indication that it's the statistics, not the fragmentation. More than likely, this is the issue.
So, probably, you're better off getting more frequent statistics updates in place than constantly rebuilding the indexes. Remember, if you're seeing lots of fragmentation, you're either getting page splits from updates & inserts on your indexes, or lots of deletes. If it's the page splits, that's a massive hit on performance. You're effectively in a loop then. Defragging, which is a hit on performance, followed by page splits, another hit on performance. This is why a lot of people these days are focusing on fill factor for the indexes and just letting them fragment, rather than sit in the loop.
For info on Extended Events, Microsoft documentation is pretty good. I also have a lot of blog posts & videos on the topic. For execution plans, get a copy of my book (free to download, or you have to buy the paper version).
Hope all this helps.