The Cost of Performance
The recently launched Facebook Instant Articles homepage featured the following claim:
Leveraging the same technology used to display photos and videos quickly in the Facebook app, articles load instantly, as much as 10 times faster than the standard mobile web.
Facebook must’ve hit a nerve, because bloggers came out swinging.
First, John Gruber talked about the “ill-considered trend toward over-produced web design”:
Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.
Then Peter-Paul Koch reacted, declaring that “tools don’t solve the web’s problems, they are the problem”:
The web definitely has a speed problem due to over-design and the junkyard of tools people feel they have to include on every single web page. However, I don’t agree that the web has an inherent slowness. The articles for the new Facebook feature will be sent over exactly the same connection as web pages. However, the web versions of the articles have an extra layer of cruft attached to them, and that’s what makes the web slow to load.
Tim Kadlec also wrote a much more nuanced piece about “choosing performance”:
If a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.
Tim makes a great point: it’s not that sites can’t be performant, is that they choose to prioritize other concerns. But why?
More Than One Web
The mistake articles talking about performance often make is that they tend to assume that there is only one web: the web of static, text-and-image content.
They focus on their favorite news site’s slow loading times, but forget to consider that the web is also made of things like complex web apps, amazing WebGL showcases, or Chrome experiments.
Now these things admittedly sit on the two opposite ends of a vast spectrum, but I believe they’re getting closer.
Getting Closer
Just look at the New York Times’ famous Snow Fall story, or TheNextWeb’s recent redesign.
It’s an online news site, yet it features effects straight out of the latest Codrops demo: hover interactions, rotating thumbnails, and even sliding article pages.
Sure, some will think this is all superfluous cruft, and long for the days of text-only web pages.
Yet I’m also willing to bet a big portion of TheNextWeb’s audience will appreciate the attention to details, and be delighted by the subtle animations.
But wait! All these extra animation frameworks will bloat your site, hurt your performance, and decrease your traffic. If you value your bottom line, surely you’re better off coding everything from scratch?
The Cost Of Performance
There’s no better way to illustrate the cost of bad performance than the old story about every extra tenth of a second of load time costing Amazon millions.
But good performance has a cost too: development cost.
This is why following Peter-Paul Koch’s suggestion of just “ditching tools” isn’t that easy:
We use tools in order to prove that we’re seasoned and mature, and not because they solve problems that we couldn’t solve on our own with some basic knowledge of CSS and JavaScript and spending a few days extra on each project.
The solution is simple: ditch the tools. All of them. (No, I’m not being particularly subtle here.) Teach the newbies proper web development. That’s it, really.
It’s one thing to blame web developers for using heavy libraries and frameworks like jQuery or Angular instead of coding their own ad-hoc solution when you’re a developer with decades of experience who blogs about cross-browser problems and performance issues for a living.
But it takes more than “basic knowledge of CSS and JavaScript” to emulate modern frameworks, and most developers just don’t have that skill level or the time to acquire it. Especially when their boss is breathing down their neck talking about approaching deadlines.
Maybe using tools will slow your site down. But not using tools will slow your site’s development down. Which one will you chose?
So it’s not like developers are building heavier sites on purpose. Just as Tim Kadlec pointed out, they just have different priorities.
Maybe the solution is not just to beat developers over the head with the performance hammer, but also to make it easier to build performant sites.
We Need Tools
Which brings us to tools.
Now I should explain where I’m coming from on this issue. I’m a big fan of the Meteor JavaScript framework, and while I love Meteor I’ll be the first to admit that it’s not geared towards web performance in the traditional sense.
You need to load a big chunk of JavaScript to do about anything with it, including just displaying “Hello World” onscreen.
So if we’re just considering load time, Meteor loses. But that same big chunk of JavaScript can also help you build complex, real-time web apps in a record amount of time. It can enable a junior developer to build in one week something that would take even more experienced programmers months to build from scratch.
It’s a bit disingenuous to talk about the web getting slower and all the “JavaScript cruft” without mentioning any of the benefits we got in the process. Before frameworks like Angular, React, or Meteor, building web apps was a mess of unstructured, unmaintainable code.
The way I see it, we just went through an “expansion” phase, with new frameworks and libraries popping up left and right. Now that we’ve had a little time to think and that the dust is starting to settle, maybe we’ll enter a “contraction” phase and turn our focus back to simplifying and consolidating our infrastructure.
And hopefully, we’ll figure out a way to keep all the added benefits we got from our shiny new toys, without having to keep paying a performance tax.
The Right Balance
I’m not saying I want every single website to end up featuring spinning images, animated diagrams, and loading 5 different frameworks just to display three lines of text.
But I also don’t want every single website to look like Daring Fireball.
So maybe the right balance is somewhere in the middle. But we’ll never find that sweet spot if we don’t allow ourselves to go a little overboard first.
