What Being Responsive Really Means


When a new client asks for a responsive site, I always ask them what they mean by “responsive”. Many are still unsure of what this means, and often end up quoting back a lot of industry buzzwords they’ve heard a long the way, usually to do with some kind of framework or jQuery plugin. What a lot of clients don’t realize is that they often need something much smaller.

I’ve noticed that a lot of the big name developers and designers in our industry often talk about the best case scenario of a website: a website that’s built from the ground up, uses responsive images so the mobile version loads in a quarter of the time, and works on everything from a tiny 1″ smartwatch to a 60″ big screen TV with a PS4 and every browser from IE5 to the latest Firefox.

However, unless the client can afford to spend $25,000 on their website, spend 6 months on testing, and hosts to thousands of visitors a day, this isn’t practical. The average website doesn’t need to work on everything, and the goal of designers and developers is to figure out how to get the best website for the client’s budget.

If, on looking at the client’s traffic stats, 95% of their visitors use Browser A, 4% use Browser C and the rest are using Browsers D and E – is it worth spending time debugging and testing on D and E?

Does the client’s website (who, for example, sells fishing rods to males aged 50+) really need to work on an Xbox? Support for more devices means more testing time, more money and the potential for more bugs. Couldn’t that budget go towards something more useful, like making sure users don’t get lost in a menu somewhere?

Writing great, usable code is only one of a developer’s responsibilities, and making sure the client is getting the type of website they really need, while helping them use their budget as well as possible is another. It’s up to us to explain that the more proprietary features and plugins they use, the more bugs and expenses they’re going to acquire.

So what does being responsive really mean? We’re talking about making our websites usable on multiple devices, making them fast loading for various connections, while still looking great and allowing the user to do what they need to do, regardless of what kind of device they’re using. I’ve found a few go-to techniques that almost always ensure a very usable website, without a lot of overhead.


Fluidity & Media Queries

The first step, and most obvious when it comes to responsive design, is to create a fluid structure. This is done by using percentages instead of fixed pixel widths. I’ve found that it’s actually a good idea to use both, depending on the needed design, and to use media queries to reshape the layout, once it starts becoming usable.

This means that I don’t create media queries based on any device size – but rather when the actual layout or usability starts breaking down. This prevents bugs and ugly layouts when a new device comes out that has a different viewport width that the current standards.

Because I work with designers and am given set designs, I’ve always preferred to work top down, instead of mobile first. I’ve recently begun doing a bit of both, however, and while starting top down, am sure to put larger pieces of styling only in the media query needed – for example different sized backgrounds, or image backgrounds that will only be used on desktop sized viewports. I call this technique going “outside in” and it allows the developer to anticipate bugs at any viewport size a lot easier that doing one end at a time.

Working from top down ensures that IE doesn’t get a minimum experience like mobile first, but instead gets a nicer-looking gracefully degraded design. It also allows me to get the working website as close as possible to the original designs, as I don’t have to try to guess what the mobile version should look like when given just the desktop designs.



Using retina or not should be dependent on your website design and user needs. If you’re using a lot of flat-colored icons, the pixelation is going to be a lot more noticeable than if you’re using just a few regular images. For the majority of websites, just having the logo in retina format is enough, and the image quality isn’t noticeably off on retina screens.

The drawback to using retina is that the images you’re having to download have to be twice the size of the viewing area – which means instead of downloading a 500px wide image, you’re downloading a 1000px wide one.

While this may not be a huge problem for users with a fast internet connection, when you’re on a train in the middle of nowhere on something less than a 4G connection, your website suddenly becomes unusable. So is the trade-off in picture quality worth it?

For those that do need retina images, it’s important to make sure you’re only downloading these large images if you need them. Using retina media queries, for example:

@media only screen and (-webkit-min-device-pixel-ratio: 1.5) {

ensures that images are only being downloaded on retina screens. You can also combine these with regular viewport media queries to fine tune these images even farther:

@media only screen and (max-width: 680px) and (-webkit-min-device-pixel-ratio: 1.5) {

For normal images not in the CSS, I suggest using a javascript plugin called Retina.js that will automatically search through all the images in the HTML document and compare it to the one in the folder the image path points to.

If it finds an image with the exact same name and ‘@2x’ added at the end, it’ll replace it with that image. For example, an image with the path /images/logo.jpg would be replaced with /images/logo@2x.jpg.

Note that this being a JS plugin means that it comes with a bit of extra overhead and an extra document to download. I again place emphasis on whether having retina is essential to your website to make this trade-off or not.



Responsive menus have been a point of contention in the industry. Some take the position that the hamburger style menus (having your menu collapsed under the three line button) is confusing to users – but I disagree with this point.

While I’d rather have a client use the word “Menu” instead of the three bar icon, I think it’s been in use long enough for the majority of users to know what it means.

When it comes to responsive menus, I prefer to use MeanMenu, which is a very lightweight javascript plugin that creates an absolute positioned dropdown menu with the normal hamburger icon (which can be changed if you prefer).

If javascript or the plugin itself fails, you’ll still have your regular menu and it’ll still work. It works on the fly too, so if a user is playing around changing their viewport size, it’ll load and unload itself at the correct cutoff width.


Responsive Images

Responsive images is still in its very early stages. So much so, I’ve only used the recommended <picture> HTML element on one or two sites. However, if you’re using a ton of images on your site, especially high-res ones, using responsive images can drastically reduce your download time, especially when combined with picturefill.js and media queries. Picturefill.js allows the <picture> HTML element to work in all browsers, with a fallback in ones that don’t support it.


The downside to responsive images, is that it forces you to create 4-5 versions of an image for every image. If you’re using a CMS like WordPress, this can be easily mitigated by using WordPress’s auto image sizer for each size.

However, if you want to manually control each size’s crop, then you’d have to create and upload each image manually, which can get tedious.


Coding Styles

There’s a lot of back and forth between coding styles and using things like frameworks and preprocessors. To be 100% honest, usually the use of these items are more for the developer than the user. (I’m personally against both). A user shouldn’t be able to tell whether you’re using a preprocessor or not.

I’ve actually had clients ask for “LESS”, because they heard about it on a podcast or read about it on a blog. I had to explain to them, that unless they were going to code on the site themselves (they weren’t) or if they had developers on staff that used the preprocessor and preferred it (they didn’t), then it wasn’t something they needed to be concerned about.

It is simply a preference of the developer that makes no real difference in the long run, like what kind of IDE they use. While some would argue that preprocessors do wonders for very large sites with multiple developers, for the average site, it doesn’t really make a difference.


Testing & Optimizing

You’ll start to notice that your website quickly fills up with a ton of plugins, from responsive menus, to polyfills and fancy animations. This is where you can start to get in trouble with loading times and potentials for bugs. Even pure CSS animations can slow a website down.

Make sure you’re only including large pieces of JS or plugins on the pages you need them. When I’m using something crazy, like Isotope or Masonry, I make sure to separate that out from other JS, as it can be a resource hog, and is pointless to load it on 100 pages when you use it only one 1.

Also remember that iOS and Android hate fixed position items and parallax – and these things can also slow down the site anyways so remove them for smaller viewports. Minify your code as much as possible, as well as optimizing images in an image editor. Make sure you’re not downloading JS or CSS includes or images you’re not using as much as possible.

Testing can get tedious and expensive and I’ve seen developers who have a “200 device” device lab. Most of us don’t have the space or money for that, and so far, most of the mobile testing websites out there are pricey as well.

I suggest testing on at least 1-2 Android devices, and iPad, an iPhone, the latest versions of Firefox, Safari and Chrome, and right now (early 2015) IE versions 9-11. If the client’s traffic history shows use of other devices or websites, find someone to borrow a device from (or a Twitter friend) and test on that too.

The majority of your mobile bugs will be found using iOS and Android, and the majority of users are usually on either of those platforms.


In Conclusion

There’s no “one way” to build a responsive site, and you could write volumes on the subject. The most important piece of advice any developer could follow is to look at the users. Develop for the real world use case, not the “best scenario”. Especially if a client is on a limited budget, develop for his users and not for who the experts talk about.

Responsive means adapting to different situations, and not having one layout for everything. If the site’s users are all browsing the site on a 1980’s Atari (don’t ask me how!) then develop for a 1980’s Atari. Otherwise, stick to the main browsers and devices (especially if you don’t have any traffic stats yet) and keep your code as simple as possible.

Happy developing!

Share This