Running a random test over all visitors to dslreports.com shows that over 26% of visitors use a browser Adblock extension to remove ads. This is the percentage measured from the population who do not block most scripts, including google analytics, by default (by using NoScript or Ghostery etc). It is likely the uncounted "dark matter" visitors almost certainly also block ads.

Among just Desktop Chrome and Firefox users, the percentage of Adblock in use is higher - almost 50%, leaving Internet Explorer Safari and Mobile to pull the balance back to 26% overall.

Wondering why the Facebook "Like" button count is the same as the "Share" button count? it is because the count in a "Like" button:

is actually Likes+Shares+Comments

For example the Like or Share button for google.com is broken down as follows:

https://api.facebook.com/restserver.php?method=links.getStats&urls=http://www.google.com
 

Take aways:

The "Like" count is not likes, it is engagement.

The "Share" button count is not shares, it is the same engagement number.

XHR2 - Browser XMLHttpRequest() is a boon and also a curse. Here are just a few of the ways you can be tripped up.

1.

I did some testing on the different ways that setInterval() can go wrong in Javascript across different browsers. Here is the result in table form using a 1hz test.

"Creep" means the intervals creep forward over time.

"Accuracy" means how many ms late from 1000ms the call occurred.

Tests were done on OSX and Windows in Virtual Box.

This is an interesting result in that Apple has gone nuclear against battery power and cpu hungry web pages with Safari, by heavily throttling their access to interval timers unless they are "in use".

In theory, the browser javascript performance object lets you do this:

window.performance.timing.responseStart - window.performance.timing.requestStart

which will return the time in milliseconds it took the browser to fetch the page from the server. This sounds exciting from the point of view of guesstimating bandwidth.

Unfortunately the reality is that at least for small pages it is nearly useless. Plotting actual measured download speed in megabits vs this browser timing metric (milliseconds) shows how useless it is:

That row of dots basically along the X axis? those have values of 1 or 2, and they are from our good friend IE 10 and IE11.

There is a small correlation, the worst bwtimer results do tend to be weakly associated with the slower end of the speed spectrum. That's about all you can really say. Don't use this performance timing object to make big decisions!

This jsfiddle I whipped up seems to demonstrate a strange problem with IE11.

What is demonstrated is an XHR2 http ping, with millisecond timing. Every browser except IE11 takes the same time to do each of the 10 fetches.

Here are the different possible browser navigator.platform values I have collected:

| masking-agent                                       |
|                                                     |
| bite me                                             |
| Commordore C-128                                    |
| None of your business.                              |
 

Perhaps this is useful to someone. It triggers in Firefox only.

try {
   // Some stuff that will do an XHR2 req.send()
} catch(e) {
  var msg = e+"";
  if (msg.match(/0x805e0006/)) {
    // Issue an error message to the user telling them
    // that NOSCRIPT (probably) broke it
  } else {
    // Other error handling.
  }
}
 

Here are some of the more unusual http request headers that I've been collecting along with an example value for each. Yes I realise some values have cookies, IPs, and there are other probably private information but without context this information is useless to anyone.