Followup: How many users have JavaScript disabled?

My last post, How many users have JavaScript disabled?, got a fair amount of attention followed by several questions around both the methodology and the implications. The aim of this post is to provide additional details to help everyone better understand our results and how to use them.

How were requests filtered?

I talked a bit about our filtering of requests as the baseline for our investigation in my last post. As one of the most-visited sites in the world, Yahoo! has had to develop techniques for identifying traffic that doesn’t come from real users. For our investigation, we had the benefit of pre-filtered data based on what the Yahoo! network believes to be valid requests. For a lot of small companies, this is one of the toughest parts of analyzing traffic information. Our investigation benefited from the already-existing filters on the Yahoo! network, ensuring that we weren’t incorrectly counting requests as valid.

The requests in our research are also split off from the total amount of traffic directed at the homepage. Mobile users, for example, are automatically redirected to the mobile homepage ( even if they enter directly.

Additionally, C-grade browsers are served a light experience. Neither the mobile nor C-grade requests were considered as part of our research. As a result, our findings can be accurately described as correct for A-grade and X-grade desktop browsers.

How was the measurement done?

As for the actual methodology, we used a series of four beacons on the page. The first was located at the top of the page and the second at the bottom. These two were implemented using a regular <img width="150"> tag. The third beacon was fired using JavaScript and a dynamically-created <img width="150"> tag (this obviously would not fire for JavaScript-disabled users). The fourth and final beacon was a <noscript> tag containing an <img width="150"> at the bottom of the page.

If we received three beacons for any given request, it was considered a valid user request. If we received just a top beacon, we considered the page to be abandoned, which is to say it never finished loading for one reason or another. A top and bottom beacon indicated that the page finished loading, and the addition of the JavaScript beacon or the <noscript> beacon let us know if JavaScript was enabled. A simple skeleton HTML file to do the same might look like this:

<!doctype html>
   <title>Sample Tracker</title>
   <img class="editorial" src="top-beacon.gif" width="1" height="1" style="position:absolute" alt="">
   <!-- page contents -->
   <img class="editorial" src="bottom-beacon.gif" width="1" height="1" style="position:absolute" alt="">
       var img = new Image();
       img.src = "js-beacon.gif";
   <noscript><img class="editorial" src="nojs-beacon.gif" width="1" height="1" style="position:absolute" alt=""></noscript>

An obvious downside to this technique is that users who have chosen not to download images will not register using this technique. While I don’t have any numbers indicating just how many people do this, it’s our belief that the number is small enough to have not affected the results of this study.

The same can be said for those using other plugins to block downloads, such as an ad blocker. Keep in mind that when you’re dealing with the volume of traffic that the Yahoo! network receives, small outlier groups tend to be statistically insignificant. We ran the same test on multiple days during peak usage times in each country to verify that the trends were valid.

Which users have JavaScript disabled?

We didn’t track which browsers were JavaScript disabled, so I’m unable to share if one browser or another has a higher rate of JavaScript disabled users or not. I can say, however, that you cannot assume JavaScript-disabled users are automatically using assistive devices such as screen readers. Screen readers do not replace the web browser, they work with it (please see my colleague Victor Tsaran’s screen reader talk for more information).

Should we care about JavaScript-disabled users?

One of the more interesting themes among the reactions to my last post was whether or not it’s necessary to design for JavaScript-disabled experiences. My point, which I’ll restate, is that even a small percentage of Internet users is a large number.

If you were to assume the 0.25% number for Brazil (the smallest rate of JavaScript-disabled users from my last post) as the basis for the estimated nearly two billion Internet users (source), you’re still talking about 5 million users. At 1%, you’re talking 20 million users; at 2% it’s now 40 million. Since percentages are a relative measure, they can obscure the significance of the actual number.

On the Yahoo! homepage, we’ve taken the design approach that everyone should be able to use the page, regardless of the capabilities of their browser or computer. While some have claimed that it takes longer to create a JavaScript-disabled version of the page or an accessible page, we’ve not found that to be true.

There is very little overhead when a site is designed with progressive enhancement in mind from the start. Starting with the content and then layering on the appearance and then the behavior is the best way to have a site that the largest number of people can use. Earlier this year, Victor and I did a talk about how accessibility was built into the Yahoo! homepage from the start. This didn’t make the development take longer, it just required a different mode of thinking when at the beginning of the project.

This doesn’t mean that every user gets the exact same experience. It means that each user gets an experience that is the best possible, given the capabilities of the browser and computer. So a screen-reader user interacts with the page in a way that is different than a mouse user, and a JavaScript-disabled user interacts with the page differently than someone with JavaScript enabled would.

That’s the beauty of progressive enhancement: you build one product that is usable by a large number of users. It doesn’t take more time or effort, it just takes different thinking. It’s a process that worked on the Yahoo! homepage and we’re happy to recommend to anyone looking to reach as many people as possible.


To us, this research validated our approach by reminding us that people do navigate the web without JavaScript. Some purposely turn JavaScript off, while others are forced to through their companies. Either way, there are still a large number of users who will attempt to use your site without JavaScript. I’ll echo my conclusion from the last post once again: progressive enhancement is the best approach to ensure the maximum number of users can user your site with smallest amount of development effort.