Instant Web

Instant Articles are here, and the announcement is all about speed. From a user perspective, I think that Instant Articles are a good thing. But I bristle at the implications for the open web. Implicit in the sales pitch (and explicit in much of the commentary that followed) is the familiar criticism that the traditional HTML/CSS/JS web stack is too slow to deliver a first-class experience. Facebook may have been throwing shade, but others were more overt in their criticism.

John Gruber put it in stark terms:

I don’t believe that the web is inherently slow, although I do acknowledge that over-produced web design could give rise to that assertion. But that’s a fine distinction, because in practice it might as well be true—as Scott Jehl says so very succinctly:

That the performance of bloated websites is the norm is profoundly disappointing, all the more so because we’re the ones who made it that way. Users of all kinds need the open web, because it serves everyone—including people without a Facebook account and people without access to the latest mobile devices. But even without the Instant Articles bar to measure against, we’ve been shipping slow sites and thus failing those very users. Tim Kadlec gets to the heart of the matter in his post “Choosing Performance,” and it’s simultaneously simple and complex:

I think Tim’s point is dead on. Later in the piece he points out how culture change usually moves more slowly than technical solutions, and that’s specifically true for the folks building the web.

In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast. Unless you make some fundamental choices and set up clear constraints, you can—and will—build and ship beautiful sites without feeling a single ounce of the pain and frustration that your users encounter when all of that beautiful imagery, CSS, and JavaScript comes trickling down their mobile network.

My family and I are big fans of cooking-competition shows. I love how the judges save their harshest criticism for chefs who let their dishes leave the kitchen without tasting them. “Did you taste this dish before it went out?” they ask, and the chef can do nothing other than hang their head in shame and reply, “No chef, I did not.”

That’s my biggest takeaway from Instant Articles: we (designers and our clients) have to start tasting our work. Not just in our proverbial kitchen, but where our users actually eat the stuff. How do we do this? Some of it is tactical. Dan Mall has a great primer on setting up a performance budget. Scott Jehl’s Responsible Responsive Design has a lot of good, practical advice on tooling and testing to make things fast, in both absolute and perceived respects.

But again: we can’t just engineer our way to a faster web, because for every bit of extra speed we wring out, we’ll find a way to fill the gap with even more over-produced design. M.G. Siegler’s analysis of Instant Articles comes to this conclusion:

It’s a funny line, but it also rings a bit false to me. Because it isn’t just text, is it? Our sites feature more and more images, webfonts, CSS, and JavaScript layered over the basic text and markup. Siegler’s line raises a particularly difficult question, though: why? Of late it seems that many of those elements layered on top of the content are an attempt to emulate the slickness and behavior of native apps. And to an extent that can be a good thing—the web has always been great at absorbing and expressing characteristics of other mediums: books, magazines, movies, video games, apps—anything and everything, really. But that impulse needs a counterbalance: we can do this on the web, but should we, if it means users won’t even stick around to see the content?

I don’t want this to be tantrum trigger, where we throw up our collective hands and yell, “We can’t do anything cool on the web! Fine! Just make it all text! ARE YOU HAPPY NOW?” I think we do have to be better at weighing the cost of what we design, and be honest with ourselves, our clients, and our users about what’s driving those decisions. This might be the toughest part to figure out, because it requires us to question our design decisions at every point. Is this something our users will actually appreciate? Is it appropriate? Or is it there to wow someone (ourselves, our client, our peers, awards juries) and show them how talented and brilliant we are?

Lara Hogan’s Designing for Performance might be the most useful resource in this regard, because it talks about how to educate and incentivize our teams toward a performance-focused culture. If you, your team, and your client build that culture with your user in mind, then the sites you build can be beautiful and immersive without negating the accessibility and reach that makes the open web so vital.

What’s exciting about this user- and performance-focused mindset is that it will still be valid and useful even if we see some much-needed advances in browser-based capabilities. I hold out hope that components like HTTP/2 and service workers will allow us to build smarter, more performant sites. But we have the means to build sites faster right this minute. If nothing else, Facebook just turned that into a higher priority for the entire web community. And that’s a good thing.