Performance
Easily disregarded as a purely technical aspect, performance (the swift and resource-considerate delivery of web pages to the end user) is an important aspect of inclusive design. A well-performing website is most usable for people with old devices, on slow or metered connections, or with limited attention.
Tim Kadlec making the case for "Performance as exclusion" (social) and "Performance as waste" (ecological).
Because of page size, a child in the U.S. – or anywhere – may have to choose between eating lunch or doing homework. Here is why…
The problem of "web bloat"
This post from Dan Luu discussing how web bloat impacts users with slow devices caused me to reflect on the supposition that faster connectivity means faster websites.
A comprehensive collection of arguments, data and sources on web bloat and its impact on users with slow devices
While this can be hard to believe for designers and developers in offices with fiber internet, websites with long loading times (most often due to excess transfer of bloated scripts or poorly optimized media files) can not only be an annoyance but a financial burden for some:
The size of websites is commonly a metric related to performance and loading times. This tool puts a twist on that and uses the metric to instead highlight an other aspect:
Find out how much it costs for someone to use your site on mobile networks around the world.
Creating heavy, bloated websites is not inclusive. It excludes people on metered mobile connection that are paying for every megabyte they download (also people on slow network connections, with old devices etc.etc.).
The website of this tool also visualizes some calculations on how much loading an average website will cost a user in different countries around the world.
Strategies
When serving and storing files on the web, there are a number of different things we need to take into consideration in order to balance ergonomics, performance, and effectiveness. In this post, I’m going to break these processes down into each of:
- Concatenating our files on the server: Are we going to send many smaller files, or are we going to send one monolithic file? The former makes for a simpler build step, but is it faster?
- Compressing them over the network: Which compression algorithm, if any, will we use? What is the availability, configurability, and efficacy of each?
- Caching them at the other end: How long should we cache files on a user’s device? And do any of our previous decisions dictate our options?
Reference projects
Tool to embed WOFF2 version of a Google Font inlined as Base64 in CSS