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.

Article Continues Below

John Gruber put it in stark terms:

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.

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:

It’s not because of any sort of technical limitations. No, 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.

This goes back to what many have been stating as of late: performance is a cultural problem.

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:

Not only is the web not fast enough for apps, it’s not fast enough for text either.

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.

3 Reader Comments

  1. Web performance is definitely an always uphill battle. Websites are like closets, if you don’t take the time to clean them out every now and then you will have an overflowing closet that is difficult to use.

    That is why performance budgets are so important and why we must make sure that speed is a priority from all departments, starting with the design team all the way to whoever manages the server. If you are a WordPress developer then making sure your plugins are optimized for performance and using image compression plugins for your site users is extremely useful.

    The bottom line of any business is to ultimately make money and it isn’t difficult to explain to a client why performance is so important because a slow site will directly impact their revenue, brand image, and pretty much everything else. Amazon and Google have proven numerous times that even a few milliseconds can result in millions of dollars in lost revenue and I’m sure many of the people who visit this site have personally seen and can attest to that as well.

    This article also states the important missing piece of the puzzle which is network speed. Most of us develop on a cable network connected computer with fast connection speeds. It is really easy to think that we are the standard and not the exception but that is far from the case.

    I wrote a post a while ago on vacation that focused on the importance of network testing: http://lukepettway.name/web-development/what-a-vacation-can-teach-you-about-web-development/. For anyone who travels even a moderate amount I can assume you’ve probably been frustrated by hotel wifi. It is easy to forget how much of even just the US lives in rural areas with only DSL connections which match those slow hotel speeds.

    I am personally happy to see that speed is taking the front seat at the moment, and hope that it makes the web better for everyone.

  2. 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.

    This is a great point. Web producers need to experience these problems in order to truly be motivated to solve them. I recently decided to take one day out of my work week to throttle my internet connection and feel the web at mobile speeds.

    Join me! Make today a Throttled Thursday!

  3. information about css and html code that is very helpful for me who is studying deeper .. keep working , thanks to quality article..if you need more information about adidas try visiting Harga Sepatu Adidas

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

Nothing Fails Like Success

Our own @zeldman paints the complicated catch-22 that our free, democratized web has with our money-making capitalist roots. As creators, how do we untangle this web? #LetsFixThis