If You Are Not Mobile First You Are Not Developing The Web

If You Are Not Mobile First You Are Not Developing The Web

Yeah its another bold statement by Chris, but it is true. I have been preaching a mobile first approach for well over 3 years now. For me it started when I started building mobile web sites and analyzing all the different things I needed to do to make the web work on phones. And for the record when you hear mobile first in your mind translate that to make my web site/app work great on smartphones.

Before I get into the guts of today's pontification I want to point you to a great book on the topic called Mobile First. It was written by LukeW, one of the world's premiere user experience experts, who by the way wrote the definitive guide to web form design. I am going to summarize a few points I recall from Luke's Mobile First book and add some of my own observations.

1) Going mobile first forces you to determine what exactly what is the most important information or interaction to give the user. Think about all the data, content and forms you have on your current, desktop focused, web site. Ask yourself if it good for my customer? Does it make them successful as quickly as possible? Am I providing it to them in a format that is phone friendly? You would be surprised how much noise you have on the screen. Its distracting, it clutters the screen and ultimately makes users less successful.

There is a classic XKCD venn diagram illustration of content for a university web site home page. On one side you have the information and data visitors want on the home page. On the other is the information the faculty, administration, marketing, fund raising folks etc want. The only place they intersect is the name of the university.

Sometimes this is a tough pill to swallow. As developers and front-end engineers it is our job to stand up to the advertising and marketing types and tell them no to most of their cruft. An example I like here is the current trend marketing types cling too about rotating hero images. I am sorry but they simply don't work well on phones. They slow the site load time and push important information below the fold or out of view, causing the customer to work harder.

Consider the online banking experience. Its great you have great mortgage and car loan rates or can help me put my kid through college. But honestly I am at my kids soccer game and realized I forgot to pay a bill and need to login to the online banking to write the check and make sure it is sent. So think about the important content first and as you get more screen real estate fill in the white space appropriately.

2) Performance Matters - Did you know surveys show that 4% of you have thrown your phone waiting for a web site to load? This it true, when an application or web site loads slow it increases anxiety. Think about it as phone rage. I am a web performance nut. Performance techniques are just part of my development best practices and to be honest it forces to me write much better code.

I have a 1 second rule. I strive to make my web application load in 1 second or less. On phones this is harder to achieve because they actually turn off the wifi and cellular radios when they are not in use. When you request a url it causes the device to fire those chips up, and that takes around 500ms or half of that second. Then you have other natural latencies like DNS lookup that simply take time. For more details on how all this really works get the High Performance Browser Networking book by Ilya Grigorik.

Along those lines here is another stat, 12% of those surveyed by Equation Research in September 2010 said they expect a web site to load faster on their phone than it does on the phone. Wow, that is a large chunk. It s psychological thing because the phone is smaller they assume it is less content and therefor is easier to load. And to be honest even with a responsive web design it should be far less content so they are sort of correct. Again there are extra latencies built into mobile devices mostly to conserve battery life that make this very hard to actually achieve.

3) Responsive Design is a Must. Last year I was still skeptical, mostly over performance concerns. I was also very worried about greater development cycle, etc. But after trying responsive web design over the past year I have completely changed my mind. The biggest concern over performance centers around images. You simply don't want to download desktop appropriate sized images on the small screen and vice versa.

As I spent more time building and maintain two versions of every web site I determined that was a much bigger headache than having one site to rule them all. There are easy ways to manage content, especially if you build a single page application and utilize web apis that return JSON formatted data. LocalStorage and IndexDB are your friend here!

Lately I have actually been presenting about responsive and responsible design techniques to build modern web applications that scale to fit all screen sizes. Most of the process is contained nicely in the CSS layer of my application. However there are points where I sprinkle in some JavaScript to really make things sizzle. But the real benefit with the techniques I and others have developed over the past three years is the ability to properly render and request content. This means mobile optimized images on the phone and large sizes as the screen gets larger. So there is no excuse for a 400+kb file on your mobile targeting home page (Jack In the Box).

4) Don't make your customer spend more money on their data plan than it costs to buy your product. Cellular data is not cheap folks, AT&T charges as much as $20/MB (no joke). If your mobile web site has 2MB of data that could cost your visitor real cash money as they go over their 1 or 2GB data limits or are overseas. A typical mobile home screen should be 100-200kb max. Yeah I did say that. In fact your desktop site should not be much more than that.

Web sites today are fatter than the children of Pawnee Indiana. According to HttpArchive the average web page today is around 1.6MB with 94 HTTP requests! That is OBESE and a sad reflection of our craft. Go on a diet. Even this blog is driving me nuts and I wrote all the code.

The home page renders a list of articles using an abstract that may have images included. For the time being they are regular IMG tags, which means the images always get downloaded. The problem is I don't display the abstract on the phone. Resize the browser if you need to to see how this page adjusts (note if you are using an obsolete browser this will not work as I do not apply modern techniques to your 6 year old browser).  This is something on my todo list, adjust that content do the abstracts are either hidden or not rendered in the DOM until the browser's viewport is large enough to display the tiles.

Anyway this issue can add several hundred kb to my home page load, which of course slows the experience and of course can cost my customers money. When I change it I will let you know.

Where should you start? Open the developer tools or fire up Fiddler and see your waterfall chart in the network tab. Find the 404's, notice how many images you download. See what 3rd party scripts are blocking your site from rendering. Reduce those Http requests. Find those fat images and optimize them.


These are just 4 points, items to address to make your web site work well on mobile devices and ultimately all devices. Obviously this is not an exhaustive list, but a starting point. If you follow these guidelines and many others not mentioned today, and make a mobile first web application as you define the experience for larger devices your code should be cleaner, easier to manage and of course will render extremely fast.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel