Six reasons to ditch your m.site in 2014

In just a couple of short years, m.sites have gone from must-have to must-not-have. Here’s a short history of the m.site and why, if you haven’t ditched yours already, you should make it a priority to retire it in 2014.

The history of the m.site in 64 words

Waaaaay back in 2010, when smartphone users suddenly surged online, site owners realized their pages were brutally slow — or completely non-functional — on mobile devices. Panic ensued. Serving a pared-down version seemed like a logical stopgap solution.So, for a while, if you used a smartphone, the internet looked like this:

Which wasn’t great, but it was a lot better than this:

Or this:

Today, there’s no excuse for m.sites.

After a couple of years, the votes are in, and most mobile users are vehemently against m.sites. Fortunately, responsive web design and mobile-specific front-end optimization techniques have emerged as solutions for the problems of poor layout/usability and slow performance (though, admittedly, manual implementation of these techniques isn’t necessarily easy).

Before we get into the problems with m.sites, first let’s de-obfuscate a few key terms…

M.site, mobile-optimized, mobile-friendly… wut?

If you’ve ever found yourself stymied by these terms, you’re not alone. Let’s bring some clarity to the conversation.

M.site –  Also known as a mobile site, m-dot site, m(dot) site, and various permutations thereof. This is a separate entity from the full site (aka “desktop site” and “main site”), and is usually a stripped-down version of the full site, with simpler navigation, less content per page, and/or fewer pages. When a user attempts to visit a full site via a mobile device, they are automatically redirected to the m.site.

Mobile-optimized site — This term is used nebulously to cover a variety of scenarios — from m.sites to full sites that have been optimized to load faster and/or responsively. My opinion is that this term should be applied only to full sites that have been optimized to perform better on mobile devices.

Mobile-friendly site – I hear this phrase a lot, and it’s even more nebulous than “mobile-optimized”. The problem with “mobile-friendly” is that it sounds great, but it’s so vague as to be almost meaningless. For example, mobile user surveys that ask people if they’re more likely to shop at sites that are “mobile-friendly” or “not mobile-friendly”. Of course people are going to answer “mobile-friendly”. I would, too! But this leaves site owners completely open to interpret “mobile-friendly” in whatever way is most convenient to them. M.site? Yeah! Responsive site? Sure! Simply capable of loading in a mobile browser? Works for me!

So, to summarize:

  • M.site = not good
  • Mobile-optimized = good (so long as we’re talking about an optimized version of the main site)
  • Mobile-friendly = great as a philosophical goal, but not as a specific descriptor for a type of site

What? You’re still not convinced that m.sites aren’t the answer to your mobile performance problems? Read on…

1. Up to one-third of your visitors are going to go to your full site anyway.

That’s right. According to research we conducted a while back, analyzing millions of ecommerce transactions on our customers’ sites, 35% of mobile users will choose to view the full site when given the option.

2. Mobile shoppers spend up to 5.5 times more on the full site than they do on the m.site.

In the same study, we found that mobile users who shop the full site spend much more than those who shop the m.site. We found that, for every $7.00 of mobile-generated revenue, $5.50 (79%) was generated by mobile shoppers using the full site. Only $1.00 (14%) came via m.site, and $0.50 (7%) via the mobile app.

Mcommerce spending breakdown

3. When it comes to making pages faster, m.sites don’t help as much as you’d think.

In Radware’s 2013 State of the Union for Mobile Performance, we found that the median full-site load time on the iPhone 4s was 7.84 seconds, and the median m.site load time was 4.33 seconds. While the m.site was 44% faster than the full site, it still didn’t meet users’ wait-time threshold of 4 seconds or less. Why? Two reasons: Redirects and latency.

Let’s talk about redirects first. Unless users are specifically typing in your m.site’s URL, they’re being redirected from your full site to your m.site. Redirecting takes time. (As Google performance guru Ilya Grigorik says, “The optimal number of redirects for mobile is exactly zero.”)

Now let’s talk about latency. The median m.site page we tested contained 27 resources (e.g. images, CSS, etc.) – in other words, approximately one-third the number contained in the median full-site page. Given this, you might expect the m.site to be three times faster than the full site; however, other factors, such as latency and download speed – both of which can be very inconsistent on mobile devices – contribute to performance. For people using 3G networks, Ilya Grigorik states that you should assume 2 seconds of latency right out of the gate.

The takeaway is that site owners need to know that that simply stripping down their sites into pages with fewer resources is not a performance cure-all.

4. Google doesn’t like m.sites.

Speaking of Google… yeah, Google doesn’t like redirects, hence Google doesn’t like m.sites. If you care about SEO, then you should ensure that each page of your site has only one URL.

5. M.sites make cross-platform sharing ugly.

Ever click on a link that one of your Facebook friends posts to their feed from their phone? And then discovered that it was a link to an m.dot page? But you’re on a PC or tablet? Uh-huh.

Or let’s look at this problem from the other end… have you ever been using Facebook on your phone, clicked on a link that one of your friends posted from their desktop, and then seen something like this?

This is what happens when we build websites in silos. Put it another way: Back when laptops arrived on the scene and site owners suddenly had to change their understanding of the range of specs they had to accommodate, did you ever hear anyone say, “I know! Let’s build a laptop-only version of our site!” (I hope you didn’t, but if you did, I sincerely want to hear that story.)

6. Managing multiple sites, each with unique content requirements, is a pain.

This practice — called “forking” — isn’t just difficult, it also makes you more susceptible to mistakes. Most CMSes aren’t cut out to handle the complexity of populating different design templates with different content, so maintaining an m.site means that you’re managing two distinct entities. This means that you need to apply all the same considerations — including identifying content requirements; writing and editing copy; sourcing, sizing, and formatting images; conducting usability tests; engineering performance, etc. — for every page of TWO separate sites. I don’t know of any site owner who is fully doing this. More often than not, the m.site is either an afterthought or a side project, when in fact mobile deserves its own share of focus.

Resolution for 2014: One web to rule them all

As I’ve said elsewhere, we live in a mobile-first world. But equally important, we live in a multi-screen world. 90% of people move between devices to accomplish a goal, and these devices are increasingly fragmented. Device fragmentation isn’t going to disappear. The line between phone, tablet, and laptop is only going to get blurrier. Siloed websites are not the solution, and as more time passes, siloed websites are poised to create more and more problems — from a usability perspective, from a back-end perspective, and from all points in between.

Over the past twenty-odd years, we’ve been spoiled as technology has evolved to give us unparalleled processing power, networks, and browsers. We’ve luxuriated in this… reveling in video, massive high-res image files, JavaScript out the yin-yang, and hundreds of resource calls across dozens of hosts. Page bloat is real, and it’s out of control.

Here’s a scary and exciting thought: Mobile is going to force us to radically rethink how we build websites and web-based apps. Let’s embrace it. Even if mobile devices and networks get ten times faster, people don’t want to — or can’t — digest the amount of content we’re currently throwing onto desktop screens. Screen size won’t allow it, and if you’re actually, you know, out there being mobile, you don’t want to sit down and read it all. (And my personal theory: I don’t think people want all this out-of-control content on their desktop, either.)

Let’s make 2014 the year that we desegregrate the web. No more mobile web. No more desktop web. Just one web — and let’s make it as fast, efficient, and beautiful as we can.

Related posts:

12 thoughts on “Six reasons to ditch your m.site in 2014

  1. You do realise that the vast majority of visually impaired users DEPEND on the m.site versions of popular webpages so that they can use them right? Screen-reader technology will often read out long lists of nothing interspersed with random bits of content or just simply nothing at all on the full sites because people fill them with GUI elements that have little content in them. The mobile version of the site is all business and text so the screen-readers just work.

    Without the mobile version of facebook for example, many visually impaired users would not be able to use facebook at all.

  2. Glad I didn’t act on my idea of an m.site version! I agree with you where you mention that it would be a side-project. Most sites just have a layout for the mobile version and there’s always bugs to find. I also agree heavily on the click-for-full-site, I find services that I actually need always absent in mobile version of websites.

  3. I’m not convinced you know what you’re talking about. A proper implementation of m dot sites do not have to suffer from any of the ailments you just mentioned. SEO issues are addressed by canonicalization, load speed and redirect issues are negligible with a proper content delivery network, and users are still going to use multiple versions of your site whether your mobile site is m dot or not.

  4. Pingback: Pixels & code #19 – Web Design weekly links not to miss - Stéphanie Walter: Webdesigner - UX-UI designer

  5. Wow, I don’t want to be only critical, but there are so many flaws in this article…
    Points 1 and 2) The research is all-but useless – no context ever given except ONE opening slide per customer. What if the purchase-pages are horrid? What if they are phone-size but the user is on a tablet making the ‘full site’ fully usable? Your conclusions are not based on data but your own bias.
    Point 3) 44% is ‘not’ a faster load-time? Just because the site is just barely over the 4-second ‘standard’… Further, testing sites that are poorly optimized for phones is just feeding your own bias. Again.
    Point 4) The link you give explicitly says Google is 100% fine with mobile sites! Did you read the article?!?!
    Point 5) This point works. But is simply a a mark of the fact that we are in a transition period.
    Point 6) Whatever. Managing multiple CSS versions is also a pain and extremely error-prone.
    You don’t even begin to touch on dynamic sites nor sites that use images wisely… no media-queries for dynamically determined images! Just a super-slow mobile experience (and now we’re back to your point #3). And how about “hover” and other ‘desktop’ niceties that don’t translate in Responsive Design? Or the swipe mobile-interaction that has no mouse-driven equivalent? So let’s rob the users of the gestures they’re expecting? You don’t think that will impact what a customer thinks of the site?
    This article, to me, is a re-hash of – sadly – the most non-helpful misconceptions about mobile web. Perhaps it is more a justification of using WordPress where most of the options one _would_ have for good mobile-web are unavailable? I think this needs a rewrite as “Some reasons why Responsive Design are easier, but will not always get you what you want.”

  6. Pingback: Six reasons to ditch your m.site in 2014 - Web ...

  7. To respond to your points, David:

    1 and 2: This is aggregate data — millions of transactions over a number of sites — not a heuristic evaluation of the individual sites. We found this trend persisted across sites. This is significant.

    3. My point here is that some people wrongly believe that if they cut their payload down to one-third, they’ll also cut load time down to one-third.

    4. This was badly worded on my part. In June, Google said they prefer a single URL. Yes, you can use the canonical link tag. Google may respect it, or they may not. In their own words, when asked directly if rel=”canonical” is a hint or a directive, Google says “It’s a hint.”

    5. This obviously depends on your perspective. You choose to take the long view that it’s a blip on the radar. I take the view that we live in a content-sharing world, and this is a serious usability problem that affects millions of links on a daily basis. If this is a transitional problem, as you suggest, then can you speculate as to when the transition phase will end?

    6. I don’t see this as a whatever problem. Mis-matched content presents potentially huge liability headaches for site owners.

    Regarding “hover”, there are a number of people who think that hover events should be phased out, precisely because of mobile. They’re a nice-to-have feature for desktop, but the web functioned just fine before hover. And there are JS libraries that let you add swipe navigation to RWD. So I don’t see how users are being egregiously robbed of features.

  8. Thanks for your comment, Kevin. In response:

    - As I mentioned in my reply to David, above, Google does not consider rel=”canonical” a directive, just a strong hint.

    - CDNs don’t deliver a huge or consistent performance boost to mobile users. Hooman Beheshti presented this at Velocity — http://www.youtube.com/watch?v=7-F0C694aQA — and we covered it further here: http://www.webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/

    - “…users are still going to use multiple versions of your site whether your mobile site is m dot or not.” I’m not sure what you mean by this. Can you clarify?

  9. Lloyd, you raise a really interesting point. I didn’t know that m.dot sites have become an accessibility hack for visually impaired web users. I just tried looking this up, and there’s little to nothing that’s been written about it. Do you have any resources you can point me toward?

  10. To respond to Tammy’s response to my points – Tammy’s response dated “Dec 12, 2013 @ 08:43:31″

    1 and 2: Still not addressing the quality of the sites. If you only surveyed horrid sites, you’ll get horrid results. If you mistakenly assume companies with a lot of money make ideal sites…

    3: I was clearly not addressing payload size. Load-time is all I was addressing. Take out redirects (which is easily do-able!) and m-dot sites can easily be made fast. Further, since dynamic sites can’t media-query their images (hypothetical example: cover-images of books at the library), load-times on “responsive-design” sites suffer _even more_ from latency (download time, image conversion, etc.).

    4: So when I go to Google’s own page on this topic (https://developers.google.com/webmasters/smartphone-sites/details) – updated 2013 Nov 24 – I don’t see any indication of the ‘hint’ perspective. Regardless, the article you site clearly states that rel=”cannonical” IS a valid option. You stated it does not say that. I call that spin.

    5: I am NOT saying the cross-platform is a blip. I’m saying that the mechanisms currently in-play for various screen-sizes, various SEO tasks, etc. are still changing rapidly. @media is pretty new! Or look at the way various browsers hack CSS (prefixing). We’re still rapidly changing some of the basic pieces of web-page-presentation. I didn’t say “blip”, I said “transition” – on purpose.

    6: No doubt that mis-matched content presents problems. But so does CSS that doesn’t match my viewer. For example, I have come across a large number of ‘contact’ pages that have required/important fields totally hidden because of bad CSS. My point is that maintaining CSS is as much work as maintaining programming code. I don’t disagree with the problem you present – but the ‘solution’ is just as wrought with problems. (of note, we usually do this in IT circles, I perceive… cf. the relational vs. document database debate :-) )

    You are making my point about hover. The web functioned just fine before JavaScript, too. Hovering can be of great utility, ease-of-use, and/or fun for desktop users. Cutting it out “precisely because of mobile” – read: because one really wants responsive design to be the better option – is rather arbitrary. Removing functionality just to make a desktop site more mobile friendly seems kind’a silly.

    And I’m not sure how swipe-navigation replaces hover. Can you help me understand that?

  11. To respond to David’s response to my response about this blog post… ;)

    1 and 2. I can’t share which sites we gathered this data from, because it’s customer data. You’ll have to take my word for it that these were sites run by companies who know what they’re doing. If you’d rather not take my word for it, then we’re at an impasse with this point.

    3. I didn’t say you were addressing payload. I was addressing payload in my original point.

    4. https://support.google.com/webmasters/answer/139394?hl=en

    “Is rel=”canonical” a suggestion or a directive?

    This new option lets site owners suggest the version of a page that Google should treat as canonical. Google will take this into account, in conjunction with other signals, when determining which URL sets contain identical content, and calculating the most relevant of these pages to display in search results.”

    5. If I retract the word “blip”, can you answer my question about when this transition phase will end? Because until it does, it’s a big problem.

    6. This seems like a tomayto-tomahto debate.

    Re: hover. I agree that it can be useful and fun, but it’s not essential. Flash can be useful and fun, too, but it’s slowly on its way out because of iOS.

    I wasn’t saying that swipe replaces hover. That point just ended up in the same paragraph as the point about hover. You had written “And how about “hover” and other ‘desktop’ niceties that don’t translate in Responsive Design? Or the swipe mobile-interaction that has no mouse-driven equivalent?” I was just pointing out that there are JS libraries for swipe.

  12. My response to Tammy’s response to my response to Tammy’s response (I love dialog – thank you for engaging with me!)

    1 and 2) I understand the ‘privacy’ piece. Your latest reply basically addresses my concern. Coming from a research-driven education, I can say confidently that no researcher should ever feel super confident (sic). For the sake of this post, I can believe that the sites are ‘good’ but I’d still be suspect because no experimenter ever accounts for every variable.

    3) If you weren’t addressing my critique, I’m not sure why you replied to it. I do recognize that your main point in #3 that payload size does not have a one-to-one correlation with speed. That point I do not take issue with. I fully agree that while intuitive, such an assumption is wrong (as you point out).

    4) I SO with people would put “updated on…” dates on their web-pages! When you go to the link I posted, you’ll see the following:
    “When you use different URLs to serve the same content in different formats, the annotation [show just above this paragraph] tells Google’s algorithms that those two URLs have equivalent content and should be treated as one entity instead of two entities. If they are treated separately, both desktop and mobile URLs are shown in desktop search results, and their positions may be lower than they would otherwise be.”
    Implication seems clear (to me… yikes!) that using the system they have (where canonical link points to alternate AND vice versa) will produce one ‘result’ where not using the system/method produces two, diluted results. Looks like Google is not internally consistent OR one of our links is more accurate than the other… but we cannot tell. Grrr.

    5) Are you perceiving me to be a prophet?!? (haha) Based on the weirdness-of-timing with which “HTML5″ and CSS3 are being adopted… and then throw in netbooks that are asking for that which was never dreamed of in ‘local’ processing… and then counter that with Amazon’s AWS rollouts of grid-graphics-cards and some variant of ‘lease a desktop’… and mobile’s touch-heavy approach followed by Windows 8′s touch-heavy approach (which may not work out very well!?!)… Yes it’s a big problem. IE6-like in many ways. But we’re in it!

    6) Yup – that’s kind’a my point. There are benefits and difficulties depending on the site, the history of the development team, etc.

    As to hover et al – I suppose hover CAN be essential if I program it to be so. Just like making swipe essential or not. I think my point in all of this is that choosing “mobile-first design” is not an assumption one should make. Most of what I have seen shows more money is being spent in purchases made from the desktop – that people research on their phone or tablet but then go buy on a desktop. Personally, I think that this is because purchase-pages in Responsive websites are WAY too limiting. But that’s my projected-reason. Regardless, if a company wants to make good money, Responsive may not be the way to go. And for some sites/companies, I’m sure they make MORE money on phone/tablet-screen purchases.

    Point: mobile may be on the rise, but going from 10% to 20% of purchases-by-platform (hypothetically) does not warrant jumping-ship. Rate-of-change is never consistent :-)

    As to Flash… maybe it’s because of the circles I run in, but that thing is like a petri dish for viruses and malware! Personally, I really don’t care for iOS so my hatred of Flash has absolutely nothing to do with iOS. Flash is a technology that got WAY too big, being built by a company that cannot seem to figure out how to do things securely. But then that puts us in another blip/transition/whatever with video codecs. Bringing this back around to transition-periods :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>