It has been the case for years now that you really have to include ad and tracking blockers for browsers in your testing process somewhere, even if it&#x27;s just a manual run-through in the smoke test section. Though I think that more than that is needed; e.g. adblock-enabled pools in your Selenium grid.<p>You really have to start from the bottom up assuming that things are going to get blocked for some people and build in graceful degradation of performance:<p><a href="https:&#x2F;&#x2F;www.exratione.com&#x2F;2014&#x2F;12&#x2F;practice-defensive-javascript-assume-blocking-of-third-party-resources&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.exratione.com&#x2F;2014&#x2F;12&#x2F;practice-defensive-javascr...</a><p>Though the problem in this article looks more in the way of something to be caught by a sufficiently well constructed QA process, followed by a bug filed with the ad blocker in question.