We do do that. When we receive a report of a malicious ad, we report to ad ops. Then they speak with the ad network and have them remove it. Then another ad (possibly from another ad network) come along and the process must repeat.

Have you tried using ad networks that don't allow malicious ads in the first place? This is literally the only site I visit that has this problem.

We partner with ad networks that provide content most relevant to our users.

I count anywhere from four to five ads on this thread view alone. Is there any way one of them at a time can be removed in a dev environment to see if one of them is troublesome and causing intense resource usage due to an error in coding or some other reason? Just a thought.

I really don't believe the problem is malicious ads at this point, but rather something wrong with the way the ads are being rendered on the site itself. When I was testing the trending threads directory issue with/without ad blocker and with/without being logged in, there was a huge difference in the way the site rendered while logged in with ad blockers off. Chrome being the browser with the worst issues, I was never able to fully render a single FT page using Chrome with no ad blocker while being logged in, the loading icon just spun for eternity.

My guess is that at least one of the ads from the current ad network has a compatibility issue with the site and Chrome is trying to render it endlessly, causing a huge CPU spike, even though the actual content of the page fully loads and renders. Unfortunately, I have no idea how to possibly isolate a problematic ad or a potential coding compatibility issue from the user side so I don't think I'll be able to help there like I could isolating the trending threads directory problem.