pixelserv-tls : More is Less

This article is about performance benchmark of pixelserv-tls and why people would want to use it.

As the first article about blocking ads/trackers/malware websites, this is probably not the right place to begin. Nevertheless, let's jump to the meat, and I'll try to fill up gaps with one or more articles in future.

DNS-based adblocking

Today's preferred strategy for adblocking is based on operating DNS records in home routers' DNS server/forwarder. This strategy compliments adblock plug-ins in browsers though personally I no longer use such plug-ins.

The common practice is to configure a DNS forwarder such as Dnsmasq to have overriding entries of host names of known advertisers and trackers to IP address 0.0.0.0. Some people might additionally have these records pointing to a LAN ip where a full-duty web server such as lighttpd or ngnix serves a 1x1 pixel image, logs browsers' access and graphs a few fancy charts of access statistics.

pixelserv was created specifically by a few enthusiasts on the net for doing such a task quickly and in a tiny footprint of resource. About two years ago, the author of this article added HTTPS functionality to pixelserv and it became known as pixelserv-tls. Over the past months, a few major performance enhancement were added.

With ads increasingly served over HTTPS, any adblock solutions combined with lighttpd, ngnix or any general purpose webserver won't be able to process HTTPS requests. Hence, fancy charts are increasingly only telling a diminishing story of statistics.

pixelserv-tls comes to the rescue. But some people ask why they want to redirect ad requests to a web server? They aren't interested in statistics. The same people want to keep things simple and let browsers bump into wall and continue to hit 0.0.0.0.

The following benchmark attempts to offer a reason for these people to reconsider, and hopefully to adopt and proliferate the deployment of pixelserv-tls.

TLDR: pixelerv-tls speeds up webpages, offers a more snappy browsing experience, and saves battery on mobile devices.

The benchmark for pixelserv-tls

A development version of pixelserv-tls, KL-test4 is tested. Five adverts intensive websites are picked for page load time tests in Chrome 61 on PC.

The five pages are loaded in two rounds with host names of advertisers and trackers in case 1) pointing to pixelserv-tls and case 2) pointing to 0.0.0.0. Each round of tests is repeated on two different days.

Before testing each case, pixelserv-tls vs 0.0.0.0, browser cache is emptied but left enabled to mimic real world usage. Chrome's DNS cache (need Chrome to open the previous link) is flushed.

Each page is initially loaded, then refreshed with F5 once, then refreshed with F5 the second time. After every page load or refresh, the timing of three events are recorded: DOMContentLoad, Load and Finish. All three timings are available from Chrome's build-in Developer Tools.

DOMContentLoad: when the initial HTML page is completely retrieved and parsed by the browser without waiting for pictures, stylesheets, and other assets.

Load: when the pictures, stylesheets, and other assets are retrieved and rendered on screen.

Finish: when all asynchronous actions are completed. Note that if a page is designed to fire async events upon other events or conditions, the 'finish' time may get updated when such events are completed.

From users' perception, 'load' time means a page is loaded and ready for reading.

The benchmark results

In the following tables, DOMContentLoad time in pale blue . Load time in red. Finish time in black. All values in seconds and lower means faster and better. Green box indicates winner of the respective item.

The first group of three



These three websites are known to be heavy on adverts and trackers. The result shows that pixelserv-tls is the categorical winner across the board. All trials of loading the pages finish faster with pixelserv-tls! Note in particular the 'Load' time in red.

The second group of two


For post852.com, pixelserv-tls is a clear winner mostly but loses once to its competitor on initial page load.

For the Ubiquiti forum, the result is mixed. If counting only DOMContentLoad, pixelserv-tls and its competitor each wins twice and loses once on different days.

I was curious about the Ubiquiti forum. Look into their page and reveal that they don't have adverts and only one blocked asset load (to https://ssl.google-analytics.com/ga.js). Does that justify the mixed result? I don't quite figure but let's leave it for another day.

The REASON that I included these last two pages because both pages will not finish loading on mobile Safari with the '0.0.0.0' configuration. The two pages display and appear to be complete but the loading animation never stops.

With pixelserv-tls, no such problem, saving battery on mobile devices.

If you read up to here, a big thank you :-)

comments powered by Disqus