There’s been some comments about this on Twitter.

You might have heard that the percentage of users without JavaScript is approximately 1% and that these people actively turn it off. And on that basis that it’s okay to exclude them.

First of all, 1% of a large number is still a large number. A 1% increase in users is not usually something to be sniffed at.

But more importantly, the problem is less about the 1% of users who always visit your site without JavaScript and more about the 1% of visits to your site which result in users experiencing your site without JavaScript. And through no fault of their own.

For Buzzfeed, for example, 1% of visits is actually 13 million requests per month.

Stuart Langridge visualises the difference between 1% of users not having JavaScript versus 1% of visits not having JavaScript in why availability matters.

Crucially, these users don’t turn off JavaScript nor are they using an old feature phone. They’re just like you and me.

Here I’ll jot down all of the reasons users experience sites as if they don’t have JavaScript and at the end I’ll explain what we can do about it.

1. The browser doesn’t recognise your JavaScript code

If your JavaScript file contains methods or properties the browser doesn’t understand, the script won’t run.

This happens a lot because every day new browsers come out and new websites are published which rely on new APIs and JavaScript frameworks that will only work in a narrow range of cutting edge browsers.

All it takes is for one method not to be recognised and users experience the site as if JavaScript is off.

2. Browser extensions can break JavaScript

Browser plugins use JavaScript to change and add functionality to web pages. But, this is at risk of breaking depending on how well the site’s JavaScript and the plugin’s JavaScript is written.

Specifically, if JavaScript is written without feature detection, it can cause the interface to break.

As a result, users get the ‘JavaScript off’ experience.

3. Some browsers turn off JavaScript on slow connections

Chrome on Android, for example, automatically turns off JavaScript on slow connections in order to speed up page load times.

Again, under these circumstance users get the ‘JavaScript off’ experience. So all the links you put inside a hamburger menu will be laid out somewhere (or not at all) depending on your implementation.

4. JavaScript might fail to download

Like any HTTP call, the request for your site’s JavaScript can fail to load. This can happen—and has happened to me—on a train because the connection stops before the script is downloaded.

Similarly, Content Delivery Networks (CDN) can go down, so even if your connection is stable, the server responsible for sending back JavaScript might not be.

DNS lookup failures can also prevent the script from being fetched at all.

Intermittent connection or intermittent server means: the user gets the ‘JavaScript off’ experience.

5. Third-party scripts can break JavaScript

Third-party scripts running on your page—analytics tools, for example—can conflict with your own JavaScript and cause it to fail.

This is similar to the browser extension problem, except the conflict is between scripts you’ve chosen to include yourself.

6. Corporate firewalls and mobile operators block JavaScript

Some corporate firewalls block or change JavaScript files before they are sent to the browser.

For example, Sky Broadband once accidentally blocked Jquery which caused lots of sites to break. And this is another one I’ve experienced myself—when I worked at T-Mobile they blocked certain scripts to improve performance.

Personal firewalls and antivirus software can do the same. And on unsecure connections, internet service providers have been known to inject their own code into pages, which can conflict with or break your JavaScript.

It’s not the users’ fault, but once again they are denied the use of JavaScript.

7. Some browsers don’t run JavaScript

Some browsers, such as Lynx, don’t run JavaScript. So if your site shows nothing without JavaScript, then that’s what users will get— nothing.

(And that’s just one of the problems that I noted in my discussion of single page applications.)

What to do about it

The more your site relies on JavaScript, the more fatal the experience is likely to be when JavaScript is unavailable.

So the first thing to do is follow Tim Berners-Lee’s rule of least power by doing as much work further down the stack as we can.

In other words, if you’re dealing with text, images, video and forms—which is most of us, most of the time—then render the HTML on the server. No JavaScript needed, more robust and more performant.

For the remaining enhancements that genuinely need JavaScript to work, use feature detection to stop browsers that aren’t able to apply the enhancement and therefore breaking the interface unnecessarily.

Summary

While some users actively turn off JavaScript, the vast majority of users experience an equivalent experience through no fault of their own.

It’s not a matter of if your users don’t have JavaScript—it’s a matter of when and how often.

The answer to that is around 1% of the time.

If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.

The same goes for JavaScript. It’s not about people who turn it off. It’s about the nature of the web itself.

When it fails, it’s our job to make sure we don’t exclude users from accessing the products we make by designing resilient interfaces.

Thanks a lot to Caroline Jarrett for her feedback and suggestions.