Last week, a couple of blog posts came out from Catchpoint and Rigor discussing the performance implications of ad blockers, with a focus on user experience. These posts were timely; as it happened, I presented on ad blockers impact on site performance at the Velocity Conference in Santa Clara, CA last week. This post summarizes the findings I discussed in my talk (and the aforementioned blog posts) for those who were unable to attend the conference.
Measuring web performance can be like peeling back the many layers of an onion due to various interdependent components, such as web server stack, network stack, characteristics of the device and browser, and the application itself. All these components MUST work together to deliver a great user experience to the end user.
To drive higher business metrics, web publishers want their pages to render fast and be ready to be consumed quickly by their users.
Thus far most of the performance focus has been on network-level optimizations like HTTP/2, and application-level optimizations such as optimizing the critical rendering path and image compression. As applications are becoming richer, more personalized and more interactive, performance bottlenecks are tending more and more toward user endpoints. Thus it has become really important to look at factors that might impact application performance in the browser.
One factor that we looked into are browser extensions. BY FAR, ad blockers are the most popular of the browser extensions. In May 2016, one such ad blocker, Adblock Plus, announced more than 100+M active users.
In researching tools that could provide visibility into the impact ad blockers have on web sites, apart from a little anecdotal evidence and a few independent studies, we couldn’t find anything that would allow us to measure the impact of extensions, particularly ad blockers, in a reliable and standard way.
What became clear was the dearth of tools available to measure the impact of ad blockers on a site’s performance, so I added support for browser-based extensions on our private instance of WebPagetest. (I’ve published a separate blog post with detailed instructions on setting this up in your own private WebPagetest instance.)
With this tooling in place, we ran multiple experiments across different industry verticals such as eCommerce (2016 Internet retailer 150) and Media (2016 Top 150 media sites). Here are some of our observations:
- eCommerce sites tend to have fewer ads and trackers that ad blockers were able to block. On average, we observed ad blockers block two to three times more content for media sites than eCommerce ones.
- Ad blockers spend CPU cycles determining what content should be blocked. Below is a waterfall showing this particular scenario. The area highlighted in red shows that during a delay in the download, no bandwidth is being consumed, while the CPU is pegging constantly at 20 to 30%
- Adblockers have to look up and evaluate a given resource against a huge list of patterns and access controls (a.k.a. filter lists). Take a look at these filter lists.
- There is CPU contention between browsers trying to render the page and ad blockers trying to block ad content, so end user experience is pretty likely to be worse.
- Performance varies on a site-by-site basis. While ad blockers might improve performance for ad-heavy media sites, eCommerce sites with no ads may see worse performance.
The results of our tests of these sites with and without an ad blocker demonstrated the impact of ad blockers on site type.
For moviemistakes.com, a media site with multiple ads and 1,102 HTTP requests, we witnessed both a better Speed Index and a faster Start Render with ad blocking, as expected. For Parents.fr, we also saw an improved Speed Index but a slower Start Render.
With Apple.com, a site with no advertisements, we see something that we may not have anticipated – if there is nothing to block, ad blockers have a negative impact on performance. With Apple.com we saw that Speed Index was worse and Start Render slower. Etsy.com, another site with no third-party advertisements, showed the same thing.
For all sites, there was either a longer time to first byte (TTFB) with AdBlocker Plus, or no statistically significant difference between the tests. Ad blockers starts to kick in as soon as the request is made. For media sites like moviemistakes.com, the increase in TTFB is offset by the performance improvement of ad blocking. For eCommerce sites in which there was an increase in TTFB but no content to block, we obviously saw worse performance.
The table below shows the TTFB, Speed Index and Start Render results for a single run of the sites tested and mentioned above. As noted, in one instance both metrics improved, in two both were worse, and for Parents.fr we saw one metric improve and one worsen.
(click to side-by-side WPT result)
|TTFB (ms)||Speed Index||Start Render (ms)|
|Without ad blockers||With AdBlock Plus||Without ad blockers||With AdBlock Plus||Without ad blockers||With AdBlock Plus|
|Moviemistakes.com||320 ms||494 ms||4255||2830||3197 ms||2300 ms|
|Parents.fr||105 ms||107 ms||5981||3523||1297 ms||2105 ms|
|Apple.com||104 ms||136 ms||1361||2360||497 ms||1550 ms|
|Etsy.com||188 ms||182 ms||902||2107||1355 ms||2299 ms|
Given these observations, what does it mean to you?
- Ad blockers definitely have overhead, including consumption of your system’s memory and CPU.
- Never assume ad blockers will improve performance across the board – it depends on the site.
- Ad blockers do show a benefit when the tradeoffs of blocking content are greater than the overhead of ad blocking.
- Invest in tooling to measure the impact of ad blocking for users coming to your site. Extending your private WebPagetest instance is a step in that direction.