Where are the Mobile First Responsive Web Designs?

Written by Jason Grigsby on

Lyza and I entitled the second chapter of our forthcoming book “Mobile First Responsive Web Design (RWD)”. Because this is a Head First book, we can’t simply explain the theory of Mobile First RWD. We have to teach our readers how to do it.

For those unfamiliar with the phrase, Mobile First RWD takes the concepts that Ethan Marcotte taught in his A List Apart article on Responsive Web Design and flips the process around to address some of the concerns I raised about media queries.

Instead of starting with a desktop site, you start with the mobile site and then progressively enhance to devices with larger screens. As a bonus, you benefit from the advantages of Mobile First design that Luke Wroblewski espouses.

In practical terms, I think a Mobile First RWD approach requires addressing some of the following challenges:

  • The need to start over and design for the smaller, more limited devices first
  • Ability to replace images with higher resolution images as the size or dpi of the screen increases
  • Ability to test for screen size and capabilities
  • Ability to add more javascript as capabilities and/or screen real estate increases
  • Ability to add more markup as capabilities and/or screen real estate increases
  • Ability to modify the layout as screen real estate increases
  • Decision about how to handle doctype and other markup if you’re going to support older phones that primarily support XHTML-MP

This list was just a starting point for exploration. I wanted to review how other developers are approaching Mobile First RWD in an attempt to find techniques that I might not be aware of and to see how they are thinking about these problems.

So I set out in early April to find examples of Mobile First RWD by reviewing every site listed in the Mediaqueri.es gallery which at the time was just over a hundred sites.

How do you know if something was designed mobile first?

Mobile first design is primarily about the starting point. After a site is complete, how can I tell whether or not the developer started from the mobile and built up to desktop or started from the desktop and whittled down to mobile?

I didn’t want to have to tear apart over a hundred sites in the Mediaqueri.es gallery to find the handful of mobile first sites. I needed some way to narrow the number of sites I cared about to some sort of manageable number.

I believe that mobile first RWD sites will exhibit common behavior as either a direct output of or a byproduct of their mobile first focus:

  • The total size of the markup and assets for mobile web will be significantly smaller than that delivered to desktop web.
  • The total number of http requests for mobile web will be smaller than those delivered to desktop web.

So I set up Charles proxy and loaded every site on mediaqueri.es and a few others that I knew of in both Mobile and Desktop Safari. I recorded the total size, number of http requests (as resources) and the time to download for each.

My theory was that the sites that showed the biggest jump in size when going from mobile to desktop would be the ones most likely to be using mobile first techniques.

The Results Weren’t Promising

Out of the 106 sites I reviewed, 64 of them had mobile sites that were less than ten percent smaller than the desktop version. Twenty-six of the sites had mobile web sites that were larger than the desktop equivalent.

Mobile is Larger 26, Same Size 4, Less than 10% Savings 40, 11 to 50% Savings 22, 51% to 100% Savings 4, Greater than 100% Savings 10

While the numbers were disappointing, I wasn’t terribly surprised. I sorted the results by the percentage difference in size in order to find the sites that were most likely to have been design as Mobile First RWD.

I just dug into the 22 sites that have the greatest percentage difference between their mobile sites and their desktop site. I made notes on what I found in the a spreadsheet which I’ve shared on Google Docs.

After all of that work, I only found five sites that may be Mobile First RWD:

  • Yiibu.com — Bryan and Stephanie’s site continues to be the gold standard.
  • EthanMarcotte.com — Shocking, huh? 🙂
  • Elections.ChicagoTribune.com — Uses the Less framework. Mobile site is about half the size of the desktop version, but still downloads assets that aren’t needed in the mobile view.
  • Calebogden.com — I need to dig into this site more. I think the difference may be a weird issue with gzip on the desktop site.
  • Sleepstreet.be — Appears to be using the Responsive Images javascript library.

Needless to say, I was hoping to have more than five sites to review.

Why are Some Mobile Sites Bigger than their Desktop Counterparts?

The number of mobile sites that were significantly larger than their desktop siblings surprised me. The source for the big differences were:

  • Font usage — Some of the sites were using an old version of Typekit that downloaded SVG fonts on iPhone. These font files made the mobile version much bigger than desktop.
  • Retina images — Sites that were using retina images. In one case, I’m not 100% certain they are retina images because they are routed through tiny src so I can only tell that file size is much bigger for the images on mobile than desktop, but not why. In the other case, both the mobile images and the retina mobile images are getting downloaded for a double hit.
  • HTML5 Audio — HTML5 audio is embedded on the page. The browser is downloading the full mp3 file regardless of whether or not the user presses play. This balloons huffduffer.com from 122k on desktop to 2.9MB in Mobile Safari.
  • HTML5 Video — Mobile Safari starts downloading a portion of the video in order to validate the video will work and to grab a scene from the video to use in the player. Desktop Safari wasn’t doing this.

The lesson here is that if you want to really know what is getting downloaded, you need to test using something like Blaze.io’s mobile test or better yet, use a proxy like I did.

Why so Few Mobile First Responsive Web Designs?

This shouldn’t be a huge surprise. Here are some of the reasons why Mobile First RWD isn’t more widely spread:

  • Mobile First RWD may require a redesign — If you’re moving an existing site to RWD—especially if the existing site has fluid grids—you can with minimal work make it responsive. If you decide to do Mobile First RWD, you’re likely going to have to redesign the site or at minimum refactor your markup.
  • It presents larger technical challenges — What do you do about the img tag and the fact it only has one source? How do you make sure javascript only gets downloaded when needed? How do you modify your content management or processes to make sure images get resized appropriately?
  • Few frameworks support mobile first approach — Only recently have frameworks that take a mobile first approach like 320 and Up and the HTML5 Mobile Boilerplate been released.
  • Javascript libraries are just beginning to evolve — The Filament Group is leading the way here with Responsive Images and Respond.js. Different approaches are being developed like Adapt.js. As more people try to tackle mobile first designs, I expect more libraries to be published.
  • We’re still waiting for equivalent of the ESPN and Wired redesigns — The ESPN and Wired redesigns kickstarted the web standards movement. We all have high hopes that the work Ethan and The Filament Group are doing for the upcoming Boston Globe design will be a shining example for mobile first RWD.
  • The technique is still young — For as much as has been written about RWD, it is hard to remember that the ALA article was only written a year ago. People only started working on mobile first RWD last summer. There is still a lot of work to be done before the techniques are well known.

For us, the results of our research meant that we postponed the chapter on Mobile First RWD until later. Our hope is that by the time we return to the chapter, that there will be more examples to learn from.

What Sites Did I Miss?

Since I did my analysis in April, another 30 sites have been added to the Mediaqueri.es Gallery. Eventually I’ll take a closer look at them as well.

In the meantime, do you know of a site that qualifies as a Mobile First Responsive Web Design? Did you help develop it? Does it tackle some of the tough problems like img tag src and progressively enhancing based on screen size?

If so, I’d love to know about it. Sooner or later we’re going to have to get back to writing that chapter on Mobile First Responsive Web Design, and we could use as many examples to draw from as possible.

Jason Grigsby

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Never miss an article!

Get Weekly Digests


Very good information, thank you for posting it. I’m excited to learn more about mobile-first, because the typical media queries stuff (which I’ve done on my own site) leaves me wanting a really solid, dependable approach that is as mobile-friendly as possible.

I think you hit it on the head with the last one: the technique is young. People are still learning what it means to think mobile first. A lot of what has been done currently is just a retrofit of existing sites and see how it all works.

The problem, as I see it, is that many will just stop there and call it good. It’s hard work to think mobile first and how. Much of what we do need to be rethought, for instance navigation. There are certain patterns that work better on smaller screens but don’t work so well on a larger screen.

Thinking through these things is handwork and a lot of times there might not be budget, time or both to do it properly, So the tendency will be to fall back on what’s easy.

Half-tempted to send you a picture to show you the tear rolling down my cheek. Beautiful article.

Your posts are always so helpful. We’ve been learning a ton from you over the years. Our first mobile site just went up last week. http://www.medicalsolutions.com. We’ve done a lot to incorporate some of these things you’re talking about here and in past posts, but still have a long way to go. Still learning. Would love to know what we could do to keep improving here.

Does it really make sense to loom at size difference? I design with mobile in mind from the beginning so tend to create resource unintensive sites, both standard and mobile web. Just a thought…

@Elia I believe it does make sense to look at the page size. Or at least it does for the items I’m looking at.

If you start with images optimized for mobile, the difference in size can be significant. In my article on CSS Media Queries, I saw a 80% size reduction.

I mention above some of the challenges I see associated with Mobile First Responsive Web Design. One of the is handling img tags and replacing the source based on the size of the screen. I consider this one of the first things someone will face when trying to apply Mobile First RWD.

If a site starts to tackle that problem, then it is an indicator to me that there may be more to look at on the site. Perhaps they’re doing interesting things with video, etc.

All of this said, I watched 106 sites load in the proxy server. I dug deeper into 33 of them (22 where mobile was smaller and 11 where it was larger). I feel pretty confident that my conclusions about the number of sites that are tackling things like replacing the img src attribute is very low.

@syd Nice. I really like the wide screen version of the site. Also, the source code is nice and clean.

As far as I can tell, you haven’t had to do anything with img tags because you have the same size images through all the different sizes.

Anything tricky that I should look at in more detail on the design?

@elia: It just occurred to me that the disconnect may be that I’m actually more interested in how people are solving the challenges I outlined above (like img tags) than I am whether or not they started from a mobile first design.

As I mentioned, the list of challenges was just a starting point, not definitive. I’m looking to see what other people have run into.

I don’t doubt that people can build attractive sites that avoid these issues by finding ways to use the same mobile-sized images on all device sizes, but it seems to me that sooner or later someone is going to need to deliver different assets, progressively enhance content, etc.

The people who are trying to solve those problems and what they are doing is what I’m most interested in.

Works for me, Jason. Just questioning your assumptions. 🙂

@elia You’re right in that creating a good mobile site will scale up to tablet and desktop size, but *optimizing* for each of those contexts is where the challenge lies. Creating “resource unintensive sites” sounds great and falls in line with the mobile context, but that doesn’t mean we shouldn’t try to push the envelope in contexts that can handle larger assets and more functionality. Quick example: a basic e-commerce site photo gallery. Load small images by default, but as screen size & horsepower increase, it makes sense to load in larger assets and include extra scripts for loading huge image sizes for product zooming. You’re optimizing for the mobile context, but giving extra tools for contexts that support them. Users can make purchasing decisions as optimally as possible in each context, and hopefully that translates to more sales.

@jason I think a huge challenge is video, as it’s a pain in the ass enough just in the desktop context (flash or no flash? MPEG4 or OGG? Video chrome or no?). Throw in how different tablets handle HTML5 video and you have a hot mess (does it play inline? Is there a thumbnail? Is there a built-in play icon? All these change from device to device). And then mobile, which requires WURFL or DeviceAtlas just to know whether or not to serve up the right type of video file (and the entire disgusting array of codecs and nuances that go with it).

So does it look like this?
Link to 3GP file >
HTML5 MPEG4 (mobile-size vid) >
HTML5 MPEG4 (tablet-sized vid) >
HTML5 OGG (Firefox vid) >
HTML5 MPEG4 (large vid) >

You’re looking at a potential 6 major steps just to serve up a context-optimized video and that first mobile step involves server-side detection. It hurts my head a little to think about actually trying to implement that. That’s not to say it can’t be done, but it’s definitely a monkey wrench in the otherwise wonderful mobile-first RWD strategy. I’d love to hear someone who actually did this.

@brad and @grigs and *ALL* of the various MPEG4 profiles – http://www.w3.org/TR/html5/video.html …IMHO the current design of the video tag is a train wreck. Doesn’t take screen size into account (HD video is wasted on most devices as many pixels are simply discarded) and no concept of available bandwidth and appropriate alternates (QuickTime had the with RefMovies ~10+ years ago).

Thanks Jason for this insightful article. I did the Sleepstreet.be website design you mentioned. It’s good to see it was included. Thanks for that.

That being said, I have to admit I did NOT code the website from a “mobile first” point of view. It was my first responsive web design and I learned a lot from it. It was hard getting the CSS right for the different viewports as I started out making just a 960px version and then applying mediaqueries to it to scale the design down for mobile and scale it up for wider viewports. The problem with the Sleepstreet website is that it doesn’t scale well to non-apple mobile devices or non-safari mobile browsers. I’m confident this is because I didn’t use a “mobile first” methodology.

The good thing about my “mobile second” approach is that it works out of the box on older but still widely used browsers that don’t interpret media queries, such as IE7 and IE8.

Currently I’m working on a new responsive design, to be released soon, and I did use the “mobile first” idea. I can tell you it is a LOT easier to make everything work across different viewports and devices as it pretty much works on most mobile browsers out of the box. This is a huge step forward. Using media queries is much easier and because I’ve started with mobile I have to write less code as I only have to scale it up whereas for sleepstreet.be I had to both write CSS to scale the design up AND to scale it down.

The biggest problem is of course IE7 and IE8. Out of the box they’re showing the mobile version on wide viewports. I’m currently using respond.js to make the design work on these older browers as well and it has a few hick-ups that I hope to fix in the days to come. There’s an ugly jump as these browsers first show the mobile design then after a second jump over to the right design via respond.js

And for some reason I can’t get it to work in IE8, while everything is acceptable in IE7.

About the responsive images: we did use the Filament Group responsive images idea. It seems to work great and that’s probably the only reason why we ended up in your list of “mobile first” designs. I would recommend it to everyone at the moment.

There’s quite a lot of noise about responsive design in email marketing circles – traditionally there’s been little scope to serve up different content based on the device used, as things like JavaScript and server side redirects don’t work in email. Campaign Monitor have a good example, we’ve been working on a few too for some of our UK clients..

Thank you for posting this. I am wondering how/what you used to run the proxies for mobile safari? For instance, did you run an iphone simulator on your desktop?

Thought I’d pop in and say thanks for the work you did here. Great depth in this post, and nice attention to the questions that RWD raises (more than it answers, thus far). Looking forward to reading more of your thoughts.

@cewinstherace are you doing anything with img tags?

Also, does the ce in cewinstherace mean Windows ‘CE’ or something else? 🙂

Ha, nothing tricky going on, just my initials. 🙂

My approach provides a responsive experience while disabling the ability to scale the UI by changing the browser’s dimensions. Meaning, images do not scale in real-time. However, I still have a need for the delivery of device-appropriate images. For this I use Sencha.io Src.

Sencha.io Src sizes your images to the device that is requesting them, then caches and optimizes them for efficient repeat delivery. http://www.sencha.com/products/io/

I think the relative newness of responsive mobile design and mobile first design cannot be understated. Granted, there are web designers way ahead of everyone else who have been designing for mobile for a few years and are at the cutting edge of best practices. And that is fantastic — but not everyone moves at the speed of the web. I think I’ve read that over half of web designers have never done a mobile design of any kind. So we can’t just think about cutting edge techniques, we need to think about how to help everyone catch up more easily, and do *something* for mobile. Anything.

I’m writing a book that does this, and instead takes more of a “mobile last” approach. It is not focused on the most complex, cutting edge mobile practices and how to begin with mobile first. Those ideas are awesome yet also intimidating for many designers. Rather, I’m helping designers who are scared to jump into mobile see how they can iteratively mobilize an existing fixed-width web design. Baby steps. And starting with human-oriented, user experience reasons for doing so, not technical or performance reasons.

Web design today is about delivering content to people on all sizes of devices, so I’m glad we’re tackling this challenge at all levels, many of them already advanced. But let’s remember that half of all web designers aren’t yet concerned about making their file sizes smaller or optimizing mobile performance — they’re still concerned about getting into mobile just from UI and visual optimization perspectives, still trying to persuade their bosses that mobile should be done in the first place, and trying to assess whether mobile / responsive design can be implemented without tearing apart existing web sites and starting over.

Let’s discuss your project! Email Us