This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
The term ‘accessibility’ is commonly used to describe the ability of a website to be utilized by people with disabilities. While this is an important piece of the accessibility puzzle, it is not the only piece. I believe a commonly overlooked piece of the accessibility puzzle is that the content of a website is largely inaccessible to some based on internet speeds and the capability of the devices available. This problem has commonly been referred to by the development community as the ‘Wealthy Western Web.’
In summary, the Wealthy Western Web is the idea that modern web applications driven by large amounts of JavaScript are not accessible to much of the world because certain internet speeds and devices can’t provide a usable application experience. Imagine that you live in a place where the internet connection is slow, your only option to connect to the internet is a phone, and your phone isn’t a flagship device. So often we test and build for the web on our blazing-fast development machines or our new iPhone and Android phones which use a high-speed internet connection. This works great for the West but terribly for the new emerging market connecting to the internet for the first time. For many, the web is not accessible because of slow internet and poor web experiences with applications that have more JavaScript than needed.
The easiest and most obvious answer is to be very selective about what JavaScript dependencies you add to your application. When I’m trying to solve a problem and I know that there’s a dependency that solves the problem I like to ask myself “How hard is this problem to solve? Is this something that I can do in less code for my use case? What is the cost of taking that functionality on myself?” If I don’t need the dependency and I can solve it myself without incurring too much cost, I will create the solution myself.
Another “solution” to the problem is Server Side Rendering your heavy JavaScript application. This is a somewhat short-sighted solution as you can show content, but the content won’t be interactable until all of the JavaScript is loaded and executed. Rendering on the page and being able to scroll doesn’t mean the application is ready and interactable. The experience is better since you can see something, but the app is still broken in this state.
Reducing the size and number of assets your application tries to load on initial render can greatly improve the overall performance of your JavaScript application. Bundling JavaScript, minifying, and compressing JavaScript is an obvious way to reduce the load time of the application. Still, it will have little impact on the execution performance of your application. If the hardware isn’t top tier, then animations and other intense operations may not be as smooth as you want them to be. Reducing the number of images and other assets can also impact the performance of your application. If your image doesn’t add clarity, then it is probably best to get rid of it if you care about performance. Sure, your hero image is cool, but unless it has a compelling reason to be there it could be degrading to the experience for your audience. Auto playing videos can also be a problem as your application is attempting to load or stream the video as the site is loading.
The more you can embrace the web in the way that it is, the better performance you will get. New APIs that solve the problems we have been handling in JavaScript frameworks and libraries are being released all the time. The latest great example I can think of is shared-element-transition API. This provides a way to transition the content of the page that changes without removing the content that’s shared across multiple pages. It gives a Single Page Application like experience without the need for a JavaScript library or framework that acts as a router. Incorporating changes like this today and then polyfill them for a year or so is far better than using the library that will never be built into the browser natively. We also have a proposal for things like built-in JavaScript types which, personally, I am very excited about. Maybe we won’t require things like TypeScript in the future…as the platform continues to evolve, we can use these features to reduce the amount of custom JavaScript code we need to use to build our applications.
Well, if your audience is on Fast Internet, then you don’t have to worry as much about the size of your assets. However, you need to remember that mobile networks are often unreliable and slow. Additionally, you should consider that your reach could expand if it becomes accessible to more people. Who knows? Maybe your next emerging market is halfway around the world. Being able to deliver a good experience on a slow internet connection with a slow device could be the differentiator between you and your competitor.
I think that keeping your assets around 500KB is a good way to keep the application accessible to most of the world. However, if you are building a heavier web application, remember to be sure that the reason the application is heavier is because it needs to be.
The internet was created to be a common communication platform that people could share a wealth of information on – it’s called the World Wide Web for a reason. The internet is meant to be accessible to anyone who can connect to it, so why contribute to the Wealthy Western Web?