I would recommend deleting a lot of the old duplicated patch content from that shared site. I am also a little confused why that content is being duplicated in the first place, but also the relevance evaluation of duplicated patch content is going to be much worse in a custom site because it looses some of the optimizations that are made that can only be done in external sites and do not work within custom sites.
Globally hiding old content can enhance the performance of the console for NMOs or MOs that are not showing hidden content, but it does not affect client evaluation loop.
it is generally ideal to keep the actionsite as small as possible and minimize the content stored within it.
If you create a new custom site that all computers subscribe to and put everything in there instead of the actionsite, it can create the same problem to some degree, but it is still generally better than putting things in the actionsite because of the frequency at which the actionsite can be updated for other reasons.
I generally recommend having something like:
and then put the appropriate content in to the appropriate site and limit the site subscription criteria.
I am concerned that the issue could actually be the report processing speed from the relay and/or root server, especially if all of the machines reporting to the same relay have the same issue, while machines reporting to a different relay do not. You may need to tune some of the settings on the relay.
Optimizing the client eval loop is a very good ideas as well, but you might have more than one issue going on simultaneously.
Do your relays have slow disks? or slow NICs? Ideally the volume which runs FillDB on the root server, or processes incoming reports from clients on the relay would be on faster disks. (SSDs)