Programming Note: This site will be on break through the holidays and return in January. Be sure to subscribe or check back for updates!

Article: The Problem with the Mobile Web

by on July 25, 2015

The movie Live and Let Die opens in a rather ironic way: a MI6 agent sees a classic New Orleans funeral procession and asks a man standing on the street whose funeral it is. In a matter-of-fact way, the man replies “yours” and stabs in the agent. Obviously, it was a planned murder, but it would’ve seemed less foolish if the agent hadn’t asked a question he probably wouldn’t have liked the answer.

This is how I feel about Nilay Patel’s article on The Verge entitled The Mobile Web Sucks. I appreciate that there’s a high-profile technology writer questioning the performance of sites on mobile, but I don’t think writing about poor browser performance works if your post is on a site that is more advertisement than content. Still, he decided to cite RAM and processing power as cause for the problems:

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 can’t speak for Android devices, as I just don’t have the qualifications or experience, but I don’t dread opening Safari on my iPhone 6. Could his issues be related to the slightly more buggy nature of the iPhone 6 Plus, or maybe that he needs to do a backup or restore? Nah. It’s definitely a binary occurrence—the mobile web sucks for everyone.

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.

He cites Apple News and Facebook Instant Articles as ways to make it easier to consume content on mobile devices, as a solution to the poor performance user exhibit. I agree with this to a point, as it often loads a slimmed down, content-only version of an article, rather than the ad-cluttered garbage we’re used to. This is important if you’re browsing on a smaller screen and over a metered data connection. I disagree that Apple and others are throwing in the towel on the concept of web browsers, but rather offering an alternative for users on-the-go. Besides that, Flipboard has been successful, Newsstand was a flop, so it makes sense for Apple to refocus their built-in app. On top of that, creating a new product that aggregates existing content is going to ruin the Internet:

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.

I don’t think they’re turning their back on or trying to replace the web. Considering that Apple’s News app uses RSS with a few additions, that seems rather open to me. This is no different than iTunes providing additional options for podcasters to use in the RSS feeds or me making my site available through RSS. If I was so concerned about forcing users to use my site via the web, I’d turn off RSS. Instead, longer articles get a preview, and shorter ones can be consumed quickly and easily in a news reader or other RSS-based tool of choice.

In researching this article, Patel went for the argument of processing power versus web performance, looking at the arguably apples-and-oranges Geekbench scores of the iPhone 6 Plus and a comparable MacBook Air:

The thing is, most computers aren’t geared towards efficiency, both in terms of resource consumption and playing nicely with a data connection. This is why Chrome eats MacBook batteries for lunch and if you were using an LTE connection, your carrier might be sending you a bill. The iPhone errs on the side of battery life and low data consumption. Expecting the same performance is like someone who drives a Prius being frustrated that it doesn’t perform the same as a Dodge Challenger. They’re both cars and start in the $20,000-$30,000 range, but certainly not designed for the same experience.

As much as I like The Verge, I appreciated Les Orchard’s research pointing out how advertising-focused and bloated the site really is:

Holy crap. It took over 30 seconds. In the end, it fetched over 9.5MB across 263 HTTP requests. That’s almost an order of magnitude more data & time than needed for the article itself.

A bit of text, styling, and images typically won’t require that much—I think my site generally fits in the 500-600k category, depending on images (Retina Displays have forced me to use larger ones) and any special inline content. I dug out some old hardware and loaded my site, which had its last big redesign in 2012 to see if this is an epidemic across all sites. I also checked our a few other content-first sites I regularly read and found the same satisfactory performance on older iPhones. Still, Orchard puts this into perspective for the consumer:

Just to put this in some rough perspective: Assuming I had a 1GB / month data plan, I could visit sites like The Verge about 3 times per day before I hit my cap. If I’m lucky, some or most of this will get cached between requests so it won’t be quite that bad. In fact, another report tells me that a primed cache yields 8MB transferred – so maybe 4 visits per day.

Patel even owns the fact that things could be better on his site, and promises that some changes are coming:

Now, I happen to work at 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.

This leads me to believe that the crux of his argument is really that he and mobile Safari just have it out for one another and this was a good place to vent. Unlimited data plans are not coming back, and while processing power and efficiency will increase on the next iPhone and its replacements down the road, anyone running a web needs to focus on how to load it efficiently while monetizing responsibly.

So, while Apple, Google, Microsoft, Mozilla, and others should continue to find ways to make their browsers a bit more efficient, especially on mobile, I think there’s a very simple answer if Mr. Patel asked the question, “What’s an example of a site that’s making the mobile web suck?”


This post has been filed in Articles