The Mobile Web Sucks, but You Can Do Something About It, Nilay Patel

There’s a lot to pick apart with Nilay Patel’s whiny article about the sluggish mobile web. Let’s start at the top — with how browsers apparently suck – and take it one claim at a time from thereon:

But man, the web browsers on phones are terrible. They are an abomination of bad user experience, poor performance, and overall disdain for the open web that kicked off the modern tech revolution. Mobile Safari on my iPhone 6 Plus is a slow, buggy, crashy affair, starved for the phone’s paltry 1GB of memory and unable to rotate from portrait to landscape without suffering an emotional crisis. Chrome on my various Android devices feels entirely outclassed at times, a country mouse lost in the big city, waiting to be mugged by the first remnant ad with a redirect loop and something to prove.

I don’t know what sites Patel frequents, but I do not regularly experience achingly poor performance with Safari on my iPhone. Mind you, I do have a 5S, which also has 1 GB of RAM but doesn’t have to drive nearly as big of a screen as the 6 Plus. Apple has regularly shipped underpowered large-screened iOS devices, and I hope that practice changes.

There are improvements coming in software. Safari in iOS 9 takes advantage of Metal, so that should improve rotational performance. Last year, the WebKit team also rolled out a vastly better JavaScript compiler, and they’re working on performance all the time.

But a “disdain for the open web”? How Mobile Safari and Chrome on Android exhibit this Patel does not explain.

The overall state of the mobile web is so bad that tech companies have convinced media companies to publish on alternative platforms designed for better performance on phones.

An alternative way to read this is that media companies’ sites are so bad that Facebook and Apple were compelled to build alternative ways of delivery that strip out all the crap and allow the user to actually read the articles.

And yes, most commercial web pages are overstuffed with extremely complex ad tech, but it’s a two-sided argument: we should expect browser vendors to look at the state of the web and push their browsers to perform better, just as we should expect web developers to look at browser performance and trim the fat. But right now, the conversation appears to be going in just one direction.

In Patel’s mind, no major browser vendor considers performance a serious problem. This is complete nonsense. The conversation is in the other direction currently because browser performance has gotten markedly better over the past several years, but websites have become increasingly bloated. Any advantage gained by browser vendors has been eaten away — and then some — by bad web developers.

Taken together, Apple News and Facebook Instant Articles are the saddest refutation of the open web revolution possible: they are incompatible proprietary publishing systems entirely under the control of huge corporations, neither of which particularly understands publishing or media. […] Apple and Facebook are turning their back on the web to build replacements for the web, and with them replacements for HTML and CSS and every bit of web innovation it’s taken 20 years of competitive development to achieve.

This, I suppose, is the part where Patel proves a “disdain for the open web”, but it is not proof of Chrome or Safari contributing to that. The web is gunked up with all sorts of performance-sapping scripts, ads, and trackers — even Vox Media, the company behind the Verge, admits as such.1 But, for whatever reason, Patel cannot really admit to this, except in couched and defensive terms:

Now, I happen to work a media company, and I happen to run a website that can be bloated and slow. Some of this is our fault: The Verge is ultra-complicated, we have huge images, and we serve ads from our own direct sales and a variety of programmatic networks. Our video player is annoying. (I swear a better one is coming, for real this time.) We could do a lot of things to make our site load faster, and we’re doing them. We’re also launch partners with Apple News, and will eventually deliver Facebook Instant Articles. We have to do all these things; the reality of the broken mobile web is the reality in which we live.

So: “We built a very complex site that is disrespectful of readers by taking many seconds and over a hundred HTTP requests to fully render a multi-megabyte page containing barely three paragraphs of text — much like many of our competitors — but it’s the fault of Apple and Facebook for not accommodating to these atrocious circumstances.”

But we can’t fix the performance of Mobile Safari. Apple totally forbids other companies from developing alternative web rendering engines for the iPhone, so there’s no competition for better performance, and no incentive for Apple to invest heavily in Safari development.

Bullshit. Apple is — as demonstrated above — actively pursuing a much better Safari experience on both mobile and the desktop. Just listen to this week’s Debug (NSFW language). Even Nolan Lawson, who wrote that famous “Safari is the new IE” article you’ve seen floating around, disagrees with Patel here.

That’s a recipe for stagnation, and stagnation is what we have. It’s leading powerful players like Apple and Facebook to create ersatz copies of the web inside their walled gardens, when what we really need is a more powerful, more robust web.

I empathize with the Verge and Vox teams. I really do. But Apple and Facebook’s news apps are a response to an already-bloated web that shows no signs of slowing down. Giving developers a more powerful JavaScript compiler or a more robust browser will only allow them to stretch them to their limits. But providing them with incentives to not use all of the resources allocated to them will ultimately create a better web.

Dan Chilton of Vox Product:

We’ve finally reached a tipping point where we can devote full-time resources to the performance of our platform, and we want to bring you along for the ride. This post will introduce you to our newly-formed Performance Team and describe the first steps we’re taking in pulling ourselves out of performance bankruptcy.

The Verge — like any other site — should not have performance tacked-on at the end; it should be the primary goal. Anything less is disrespectful to readers.

Update: It’s worth pointing out that Chilton’s post is from May, and that Patel’s article was written in July. In the two-and-a-half months between those posts, it doesn’t seem like they’ve dramatically reduced page weight.


  1. “Performance metric tools often use our render time to show off the upper limits of their graphs!” ↥︎