Why is Everything So Slow?

Reading Brandur Leach’s article about Learning From Terminals to Design the Future of User Interfaces I found myself agreeing with many points, though not all. While I don’t agree that terminals are the answer to user interfaces, I was very keen on some of his points, notably:

We should be honest with ourselves and call out design anti-patterns that promote flashiness at the expense of efficiency.

I have found myself increasingly frustrated by bloat, whether in the form of stupidly large web pages that take forever to load while forcing the content to tip-toe around interactive elements, or simple apps that strain a last generation tablet.

I wrote a feature a while back about how I had tried to revive my 2012 Nexus 7 by switching to a different ROM (operating system essentially). I’ve been reasonably pleased with the switch but it’s far from perfect. It’s faster than the native Android ROM, but still a little sluggish.

Now, you could argue that it should be because the device is now more than four years old. In computer terms it’s more than a generation out of date, making it a virtual relic. Two more cycles of Moore’s law have passed since then, meaning recent devices are four times more powerful, in theory.

As I keep arguing though, we long ago passed the point of powerful enough. What all that extra grunt — which few people actually need — is doing is simply making developers lazy. Although it could also be that they’re driven by the new shiny too.

Instead of adding a flashy transition, or a higher definition image, or video to everything, why is no one focusing on speed?

The answer, I suspect, is that they’re all testing on super-high-spec development machines, or latest generation devices. Why spend time debugging a routine or looking for more efficient ways to do things — which often require a lot of creativity and clever-thinking — when you can just throw hardware at the problem?

Why worry about all those landfills pumped full of old devices that can no longer keep up? That’s not their problem. In fact, if you work for a device maker your job is to help move units. If anything, you want to make existing devices obsolete the moment a new one is launched. Slowing it down is one way to do this.

Bloat rules

Our software doesn’t have to be slow though. It doesn’t have to drain battery life incessantly, it doesn’t have to mean waiting endless cycles to render an interface or shipping useless bytes across the pipes. To give you an idea of the bloat, I reviewed the size of a few apps on my phone:

WhatsApp92.6MB
Amazon Music45MB
Twitter103.4MB
Kindle100.2MB
Google Maps61.5MB
Audible39.2MB
YouTube51.7MB

Just look at some of those sizes. Why the hell does WhatsApp, an app designed primarily to exchange text messages, clock in at nearly 100MB? Same for Twitter. The Kindle app is designed to display text, that is all, yet it’s also 100MB!

No wonder some devices struggle to open a few apps at a time. For comparison, Simplenote — also a text-based app — clocks in at 11.6MB. So they should all be well under 20MB. Part of that bloat is supporting multiple device types. I suspect the largest part comes down to using frameworks instead of writing code just for your app.

The underlying OS probably isn’t much better to be honest.

You’re safer online, but not for long. As Wired pointed out, the average web page size is now larger than the installer for the game Doom. Amazon’s home page is over 4.5MB to download. And those are relative minnows. 10MB isn’t even unusual these days.

While I agree design is a good thing, and that usability and good presentation make things more enjoyable to interact with, there’s a line that needs to be drawn.

Embrace speed

This is a call to arms for the developers out there. It’s time to fight the fat. Time to demote the bloat. If you’re developing a website, an app, or indeed any software or service, please spend some time on optimisation.

Consider whether you really need that whole framework to produce a simple popup. Check out resources like You Might Not Need jQuery, or even better You Might Not Need JavaScript — or optimisations and improvements for the framework you’re using, no matter what the platform.

Strip your app back to what it needs, instead of rolling it in glitter.

Future development

Of course, that doesn’t change the underlying issues.

What I’d like to see is:

  1. An OS that is absolutely stripped to the bone, where transitions and animations have all-but been ejected and where minimal RAM use is paramount
  2. Default apps that are similarly stark, notably a lean email client and a performance-based browser
  3. Support for third-party apps that are sandboxed to a maximum size and RAM use, and web apps being given greater support

I would say this needs to be taken out of the hands of the device manufacturers, because they clearly have a conflict of interest.

To be fair to Apple, they tend to support their ecosystem much longer. Perhaps other vendors will wake up and realise that customers may be happier with them if the products they purchased carry on running fine for a few years instead of being abandonware.

There have been a few half-hearted attempts to build alternative platforms, from Mozilla and Ubuntu for example, plus some independents like Sailfish. Android is the obvious contender with the most reach, and Google has the pockets to produce a lite version.

So come on people, let’s stop throwing hardware at the problem, let’s fix it instead. It’ll be better for consumers, better for the environment and go a little way towards helping us ditch the disposable economy.