On the web, size matters

The web has a problem. Most web sites (weighted by volume of traffic) are made by and for wealthy able westerners with fast computers and fast connections, and are borderline unusable by anybody outside that group. What makes this a problem is that these websites are inaccessible for stupid reasons. Web designers have adopted a cargo cult programming mentality. While cargo cult programming in real languages mostly just makes code hard to read for other programmers (idempotent imports, shared libraries, & the removal of unused symbols limit bloat at runtime), on the web bloat accumulates quickly. We use third party pixel trackers for analytics (often several different ones), CDNs for displaying static text (and RDBMSes for storing static text), CSS for styling (and JavaScript for modifying the CSS, and JavaScript for modifying the HTML, and JavaScript for modifying the other JavaScript), and we use automatic generators for building structures that would be less effort to write by hand. We force styles and behaviors on users based on our large screens and fast CPUs and hoards of RAM, and the users (if they are sufficiently savvy) fight back with extensions that chop out portions of our websites based on lossy heuristics. We don’t need to be at war with our users, and shouldn’t be. Rendering a blog post shouldn’t involve twenty HTTP requests, a bunch of JavaScript, multiple draws (as new styles override previously loaded ones), and downloading as much content as the original Doom. Choosing bloated cargo-cult methods are, essentially, discrimination: discrimination against anyone with slow internet (i.e., most of the world) or slow CPUs (anyone who didn’t upgrade their computer in the past five years — i.e., the middle class). Too much forced style information (or too many widgets and sidebars) constitutes discrimination as well: against anyone who is blind (and thus must listen to every label and alt-tag in the order in which they occur in the original HTML) or has poor vision (and thus requires higher contrast and larger fonts — ruining any kind of overly-precious color or layout dickery). Fancy style and layout is an art, and has its place, but its place is in print magazines, where style doesn’t actively defeat usability. It’s ultimately up to you, as a web designer, whether or not you want to exclude these groups. (Many things developed in the Valley are ultimately absolutely useless outside the Valley, and people often have no problem with that: it’s where the money is.) But, if you think reaching a sufficiently wide audience is worth making the occasional design snob feel scandalized, here are some tips: . They are selling you information from their access log, and you have your own. Processing your own access log saves every user an extra request. Avoid third party trackers/analytics . They won’t make you money anyway, and each one means at least one extra request — usually more. Savvy users will block ads, and less savvy users will thank you for not hosting them. Don’t host ads . Static HTML is small and fast; CDNs are big and slow. If your site is entirely static, you can use a specially priced plan from a web host that doesn’t include RDBMS access or server-side scripting. (On top of this, static HTML associated with consistent URLs will be properly cached by browsers — meaning that repeated views will not lead to repeated requests. If you pay for bandwidth, this saves you money.) Where possible, use static HTML . CSS takes lots of resources to process. Fancy CSS still isn’t consistently rendered across browsers, and is likely to break spectacularly if you drastically change scale or selectively override certain elements (such as font sizes). External CSS, while more flexible, also requires extra requests. If you stick to one small external CSS file — or better yet, avoid using any styling at all — your users will save bandwidth and rendering time. Minimize style . Under load (on client, server, or network), you can expect JavaScript or CSS to fail to be processed: it might fail to download, or it might take too long to render. Some users can’t make use of it at all (for instance, blind users with screen-readers) or disable it for performance or security reasons. Constructing a website that looks and behaves as close to correctly as possible when only the HTML has loaded will make these users feel confident in your work; a website that looks broken without CSS or JavaScript seems unreliable (and CSS and JavaScript fail). Fallback gracefully will . Most images used in the design of websites (and even many images used in post bodies) are for primarily aesthetic purposes. However, image loading should not be expected to be reliable: after all, each image is yet another request. In headers and sidebars, consider using text & minimal formatting rather than images, particularly when usability would be more impacted by the failure to load images than it would be by having text in the first place. (Again, some users will have sporadic image loading failures, and others will simply never see the images at all.) In posts, consider whether an image serves a real purpose: would you make your point better if you took more care explaining it? An image should only be included in an informational blog post if the amount of text it would take to adequately explain its content would be larger than the image itself. Use images only when necessary . Generators can save programmer time when doing something fancy, but fancy websites are fragile and generators can create very bloated code. It’s not hard to write simple HTML and CSS, and writing sites by hand discourages bloat. A website written by hand by one person will, generally, be small enough to load quickly on even a very poor connection. (If you require headers and footers, or if your content is highly structured and repetitive, I recommend writing your own specialized simple generator, rather than taking some off the shelf templating engine or CDN and configuring it. A three line shell script can produce small, fast, reliable, and beautiful websites in a way that large systems like WordPress struggle to, and even a beginner programmer can write such a generator.) When possible, write your website by hand . A visually impressive website is rarely a usable website, because the concerns are very different. Unless your target audience consists solely of design snobs, you are better off making sure your site loads quickly and is easy to use. Don’t be afraid to make it visually uninteresting: your users will thank you for making navigation easier. Write for usability, not for looks . Introducing new toys is always tempting, but those new toys interest you much more than they interest the users. A fast-loading site that does what it’s supposed to and nothing more will be more useful than a slow site that performs flashy but unnecessary tricks. Keep it simple is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories