On the importance of testing with content blockers

Published on by Hidde de Vries in thoughts .

I recommend everyone to browse with content blockers turned on. The goal: protection against tracking. Safari and Firefox have good tracking protection features. With more people using these features, we should test our sites with content blockers turned on.

Content blocking

In the age of surveillance capitalism, some browsers have started getting more aggressive in how they block ad trackers to protect the privacy of their users.

Firefox has had Tracking Protection since version 42. It works with a blacklist of domains. When something is blocked, it will show up in the Dev Tools Console (“The resource at X was blocked, because tracking protection is enabled”).

Safari not only can block trackers for you, it also allows third parties to define blocking behaviour. Third party blockers can match patterns in URLs and detect things like the domain a script is loaded on (same as site vs not same as site, the latter means third party). When a tracker is identified, developers can choose what to do: block it altogether, just block cookies or hide elements from the page. Users can install one or multiple content trackers. There is a “load without content blockers” feature (long press reload on iOS), but note users may be unaware of it. I know I was until very recently.

What can break

Four examples I encountered in the last few months:

Screenshot of Zara checkout with TypeErrors in dev tools console On this page, I could not select a store or press continue, because Facebook’s tracking script did not load

To understand the last example better, see Stephanie Hobson’s Google Analytics, Privacy, and Event Tracking, which shows how Google Analytics recommended tracking code breaks links for people who block the tracker.

We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link. Metrics can be useful, but they are rarely questioned.

A working website: some strategies

I understand companies want behavioral data in order to improve their sites. But if it puts a stop to taking people’s actual money, doesn’t that defeat the purpose of why you have a website as a company? Is figuring out how many people open your hamburger menu more important than having the feature work at all?

Use no scripts

This one is easy in theory. It is hard in the reality of modern web development, because people will laugh at the suggestion. If your site does not rely on JavaScript to build features like to take people’s money, search for opening times, show a navigation on mobile or go to other pages, these features can potentially just work.

Progressive enhancement

If you manage to develop in a way that does not assume JavaScript (or CSS), you’re likely doing progressive enhancement of some sort. It means that when you build new features, you start with the very basic building blocks, like headings and lists. Simple HTML that describes the feature in a way the most basic browsers understand. You then turn it into something fancy, using web technology a modern as you like. For example, use Web Components to make it tabs, as Andy Bell described. If the fancy thing breaks, the basic building block likely still works.

Not only should progressive enhancement help make your site more robust and resilient, if your whole team can think this way, it can help setting priorities sensibly. See also Resilient Web Design, Jeremy Keith’s free book on building resilient web sites and Dear developer, a talk by Charlie Owen.


To build good websites, I think we should prioritise working websites above gathering potentially useful data (if doing that at all). As developers, we should keep in mind trackers could get blocked and, consequently, never rely on their availability.

Comments & mentions (27)

Tom Bonnike likes this
Stefan Judis likes this
Jasha reposted this
Bernard Nijenhuis replied: Also, testing without content/and blockers can prove to be very useful. I'm not sure what percentage of users has content/ad blockers, but most developers do (oh the irony). Some ads can seriously fuck up the user experience.
Paul van Buuren replied: Ah. Nuttig advies. Onze collega's zouden ook meer moeten testen in browsers die standaard alle cookies weigeren. Er gaat opvallend veel stuk als je beleefd weigert.
Roel Van Gils 07 Jan 2019 10:00:48

Very relevant article, thanks! Last week, I found out that (the official TLD registry for .be domains) did not work in Safari with popular content blockers such as 1Blocker and in Chrome when the “I don’t care about cookies” add-on was enabled. I pointed this out on Twitter, but the team was not able to replicate the issue :( (Probably because they forgot to clear cookies first). I haven’t heard back from them. I’ll send them a link to your article ;)

Jewwy Qadri reposted this
Chris Heilmann replied: On the importance of testing with content blockers…
Pierre Burel reposted this
Johan Groenen replied:…
Eric Eggert replied: Hidde’s blog has all sorts of (not very hidden *scnr*) gems. This is only the latest:
Jewwy Qadri likes this
Roger Johansson replied: “We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link.”

Roger Johansson replied: “We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link.”

Jason Neel likes this
Steffen Jørgensen likes this
Alex Carpenter reposted this
Baldur Bjarnason replied: “On the importance of testing with content blockers”…
Alex Carpenter likes this
Rhian van Esch likes this
Chris Taylor reposted this
Chris Taylor likes this
Teodora Petkova replied:… h/t @csarven
Manuel Matuzović reposted this
Manuel Matuzović likes this
Johan Ronsse replied: A blogroll… thx @hdv
Roel Groeneveld replied: On the importance of testing with content blockers…
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.