The mobile site is the site
On the two codebases that drifted, the April update that ended the debate, and what actually convinces a client who's already paid for a mobile site.
The “m.” site is mostly over and I want to write down why partly because I argued the wrong side of this at first.
The idea, if you missed it: you build your normal site, and separately you build m.example.com, a stripped-down thing for phones, and you sniff the user agent on the server and redirect. Two codebases, two designs, one product.
Which sounds obviously bad today but was a completely defensible decision just a couple years ago when phone browsers were much weaker, connections were much worse, and responsive design was a blog post rather than the industry default.
Let’s maybe not separate these concerns
The reason it fell apart isn’t performance and it isn’t philosophy. It’s drift.
Two codebases means every change happens twice, and the second one is always the one that slips. So you get a promotion that runs on desktop and not on mobile. A form field added to one. A price that’s stale on the mobile site because the deploy failed and nobody noticed because nobody on the team browses the mobile site.
I watched a client discover, in a meeting, that their mobile site had been showing the previous season’s opening hours for four months. Nobody was at fault exactly. It’s just that a duplicate is a thing that needs continuous effort to stay a duplicate, and nothing in the process supplied that effort.
Then the sharing problem, which is the one users actually feel. Somebody on a phone copies a URL and sends it to somebody on a laptop, who lands on the “m.” version which either looks broken on a big screen or bounces them through a redirect to a different URL. And links get shared far more than they used to, so an inconsistency that was practically invisible in 2010 is now much more widespread.
And the tablet, which broke the taxonomy entirely. Is an iPad mobile? It’s got a touchscreen and it’s got a big screen. The user-agent sniffing has to pick, and whatever it picks is wrong for somebody, and now you’re maintaining a regex against a device landscape that changes every fall.
A duplicate is a thing that needs continuous effort to stay a duplicate, and nothing in the process supplies that effort.
Google weighs in
What ended the debate was Google, in April, changing the ranking algorithm to favor mobile-friendly pages in mobile search. The press called it mobilegeddon which is a silly name for a thing that mostly worked as advertised.
Suddenly there was a number attached. Not “your codebase will drift” but “your listings will drop,” and a testing tool the client could run themselves that gave a pass or fail. Ultimately, it wasn’t the technical content of the argument that proved persuasive, but the fact that someone external had put a price on it.
I don’t love what that says about how this works. It’s the same lesson I got from the browser support thing last year: the technical argument doesn’t move on its own, it moves when it’s denominated in something the person across the table already cares about.
How I learned to love responsive design
I want to own the part where I was on the other side of this because my reasoning wasn’t stupid and I think the failure is instructive.
My argument for the “m.” sites was payload. A responsive site sends the same HTML and the same CSS to everybody and hides what it doesn’t need, so a phone on a bad connection downloads a desktop-sized page and then throws most of it away. That’s genuinely wasteful and it was a much bigger deal when the average page was mostly markup.
What I missed is that the waste is a consequence of how people build responsive sites, not of responsive design. You can send one HTML document and still not send the desktop images to a phone, and now with srcset and picture that’s straightforward. Conditional loading for heavy components. The savings I wanted were available without the second codebase; I’d just conflated the technique with the sloppy implementation of it that was common at the time.
Which is a mistake I’d like to make less often, and which I suspect I make constantly: judging an approach by the median example of it rather than by what it permits.
What to do with the m.’s now
If a client already has one of those “m.” sites and it works, I don’t suggest ripping it out. That’s their sunk money and telling someone their investment was wrong is a bad opening. What I do is put the maintenance cost in the quote explicitly, as a line item, every time: this change, twice, because there are two sites. After two or three rounds of that the conversation happens on its own and it’s their idea, which is a much better place for it to come from.
And for anything new, it isn’t really a discussion any more. One codebase, one URL, content-driven breakpoints, and the phone layout is the base case rather than the degraded case.
That last part is the bit I’d emphasize if I only got one sentence. The phone layout isn’t the small version of the site. On most of the sites I’ve worked on it’s over half the traffic. It’s the site, and the wide layout is the variant.