If you build it mobile first, they will come...
Why you should be building websites mobile first, no matter what your designers or UXer colleagues are doing.
When reading what people have to say about Responsive Design, 'mobile first' is a concept that comes up a lot. The core concept is pretty simple - when using a mobile device, users are more likely to have less screen space, processing power and bandwidth. So thinking first about what experience to give people with these limitations enables you to cut to the core of your site and provide the really crucial features in an easily accessible manor. I doubt that many people would disagree with that logic - the post iPhone, pre RWD web is littered with mobile only sites which strip out most of the content and provide users with just the core tasks.
Where the approach grows more contentious is with the question that mobile first advocates inevitably ask next - "If you don't need it on mobile, why do you need it on desktop?" Whilst I believe it's a very valid question that needs to be asked, and one that as a heavy phone user I support, I'm not going to debate its merits today. I'm not going to debate them because, as a front-end developer, I'm not really in a position to decide whether or not we use a mobile first approach on a site. That decision is more commonly made by a combination of the client and the UXers and IAs. I do, however, have control over the code I write and in that domain, I think we should always be working mobile first.
The web is littered with hundreds of examples of examples of (sometimes stunning) responsive sites where the mobile user has to download more content than the desktop user and this is lunacy. In the vast majority of cases, if you're building for desktop first and hiding things that are not in the visuals/wireframes for mobile, you're giving the ever increasing number of people who are going to be coming to the site you're building a sub-standard experience. Swap your
max-width media queries to
min-width ones and lazy load extra components with JS where it makes sense to do so!
On the fairly large corporate site I'm currently working on, we've done this and separated our CSS into 3 files across the 2 breakpoints (effectively mobile, tablet and desktop, although we don't like to call them that as more devices start blurring the lines between the 3 device classes). It may be that we end up concatenating them all into 1 file as the bandwidth hit for small devices isn't too big compared to the extra HTTP requests for large devices, but planning up front gives us the ability to choose later on (eCSSential can help with this).
Following best practices like concatenating and minifying your JS and CSS to save HTTP requests and bandwidth is something you should be aiming to do on every project, no matter what the platforms or devices you're required to support. Think about the size of images you're serving - is it practical for you to serve smaller images to devices with smaller screens? If so, Picturefill might be of use to you. How to lose weight in the browser provides a neatly compiled list of things you should be doing if you want more information.
Ultimately, optimisation is something we should all care about because it benefits users using all devices and platforms, but in my experience, if you start by thinking about the most underpowered ones, you'll end up with an experience that's better for all users that visit. Or to get slightly liberal with a quote from a 1980's Kevin Costner film:
"If you build it [mobile first], [t]he[y] will come [and not leave before your 10 meg of images finish downloading]."