The debate boils down to amount of work versus performance with just a hint of preference.
On powerful desktop computers, with their nice broadband connections, downloading something like the jQuery JavaScript library is almost negligible. It's so common that many people include it by default whether they make a lot of use it or not.
At the time of this writing, a minified copy of jQuery clocks in at around 84 KB. That's not a huge factor until you're downloading that from your dinky 3G smart phone while cutting into and out of single. Then it can be excruciating and even turn a lot of users away. How many times have you become frustrated at how slow a site was loading on your phone and started violently mashing your screen trying to get some response out of it?
The Mobile-first camp states that we should leave everything we possibly can, out (JavaScript libraries, media, fancy stuff) and only add it when it's absolutely necessary, or replace it where possible. This dramatically cuts down on page load times, but, as with any optimization, it requires more effort.
The Desktop-first camp states that since the majority of users browse the Internet on desktop computers (although there's some debate even about this), we should all design rich experiences with desktops in mind and just provide the bare minimum experience for mobile users.
The battle can be summed up as graceful degradation (Desktop-first) versus progressive enhancement (Mobile-first), only the degradation isn't always graceful.
The major points to consider while making your site Mobile-first are:
JavaScript load
CSS load
Image load
Think about what is actually happening with your JavaScript. Is it a library? If so, do you need it on every page? Are you just making an alert box? Do you need to even load a library? Could you write that alert box script in pure JavaScript?
By going through that simple checklist you can get rid of a huge chunk of scripts and optimize your site for all devices. What if you really want a script for desktop but not for mobile? There's a way around that. A site called detectmobilebrowsers.com provides you with code in various languages to detect whether or not the user is on a mobile device. If they are, it typically returns true. With that knowledge, you can choose to load or not to load the script.
This is a finicky fix though. This script will need maintenance by someone, so that it is able to detect newer and newer browser agents. It seems to target everything now, but perhaps in the future, you'll have to maintain your own script. The other problem with this particular script is that the actual pure JavaScript function doesn't return a variable as true or false, it simply redirects to another page. Serving various sites dependent on a device is not responsive. In fact, it's very anti-responsive.
Let's modify the code a bit so that we get a simple true or false value if the agent is a mobile device: https://gist.github.com/CorySimmons/6140696.
Create a file called detect.js
and save the Gist above to it. Hang on to that.
With this updated code, we can now use the isMobile
variable to detect if the user is on a mobile browser. Nice! Let's jump right into making our first Mobile-first site.
Create a new file called mobile-first.html
and add the following:
We've added a load.js
script that will make it possible to load CSS and JS within <script>
blocks.
You'll notice detect.js
is doing its job. It's detecting if the user is on a mobile browser, if they aren't, it sets isMobile
to false
. After that, we're using a neat, lightweight, script called load.js
(https://github.com/rkitover/load-js) written by Rafael Kitover to load CSS and JS within a <script>
block. That JS isn't available until the next <script>
block, so we need to create a new <script>
block and repeat our isMobile
test to make sure we're not trying to use jQuery when it's not available.
Upload mobile-first.html
to your web host and navigate to it. On desktops and laptops your headers should be blue as set by jQuery; on mobile devices, they will not be blue.
Let's review. We're loading a small detect.js
script and the small load.js
for every visitor. This detects if they are on a mobile device. If so, we don't load anything. If they aren't on a mobile device, we load and execute some jQuery.
There are a myriad of ways to load/not load JavaScript and it can get pretty abstract, but this is a great way for Mobile-first beginners to jump right in and see some massive savings on mobile page load time.
Back to the fun stuff! Create a file called mobile-first.css
and add the following:
Notice that we're using min-width
now instead of max-width
.
Does this code look familiar? It should, it's just fluid.css
rearranged a bit.
Tip
If you can make Desktop-first sites, you can rearrange the code a bit and turn it into a Mobile-first site fairly easily.
Notice it's a bit (two lines) smaller? That's because we're not overriding any CSS. We're building on the defaults. As the page grows, we morph our layout into something that looks better on desktops. We're progressively enhancing.
Save mobile-first.css
and refresh mobile-first.html
, expand and contract. Looks just like fluid.html
, doesn't it? Except this time around, it's a bit faster. Two lines may not seem like much, but by using this approach you can eliminate hundreds, if not thousands (for bigger sites), of CSS that was before being rendered, then overwritten and re-rendered. This can make for some pretty big page load optimizations especially on mobile devices.
Finally, you should consider images. Images that are too big can make all your other efforts completely worthless, but we need images right? Well, maybe!
We can eliminate a lot of imagery altogether with some nice CSS. For instance, there are a countless number of CSS button generators out there. One of the more interesting projects is layerstyles.org, where you can effectively replicate the Photoshop Layers palette, create custom elements, and grab the CSS. Naturally, as you get better, you won't need fun tools like this. You might even replace them with some incredibly efficient CSS preprocessor mixings, but that's a book for another day. The point is, CSS has come a long way and you don't need nearly as many images as you'd think. Replace as many images with CSS as possible for the easiest/largest savings.
Here's a quick CSS button:
Any element with the .button class applied to it will look like a button. See how flexible these are?
Naturally, you can't get rid of every image. You'll have logos and such. The solutions for these situations range from serving a small image and using JavaScript to detect if the user is on a desktop and replacing the src
attribute with a larger version of the same image, to things as complex as editing your Apache configuration to do something similar, to even wrapping every image in a <noscript>
tag with data attributes and writing a chunk of JavaScript to add and size imagery.
These solutions are constantly evolving. Since Ethan Marcotte coined the term "responsive web design" a few years ago, there have been dozens of independently developed solutions and it seems like a new standard is coming out every other day.
To go over them all, or to pick one from the batch, would escape the scope of this book and probably be outdated by the time you get this far, but if you're particularly interested in these page load savings, check out a fairly thorough article on the topic written by Jason Grigsby at http://blog.cloudfour.com/responsive-imgs-part-2.
In short, and to avoid confusion, just use as few images as possible. This is a huge reason for the current "flat" (Google Flat UI) trend in web design. It's clean, fast, and doesn't burden the developer with having to maintain multiple image sizes and huge chunks of code just to serve images.
It's entirely up to you whether you prefer a Desktop or Mobile-first approach, but the data and most experts agree that Mobile-first is the wave of the future so it would definitely behoove an aspiring web designer to at least become familiar with developing Mobile-first websites.
In the next section we'll cover some common and strange behavior that might cause you to freak out a bit. Particularly making images and video responsive, and pixel-sizing this may make your responsive sites, not-so-responsive.