Responsive approach vs Custom mobile templates


I hope I explain this clearly.

I’m getting a new site designed, a few popular sections of the site get high spikes in traffic regularly. I want to ensure that the site (especially the popular areas) serves up fast and in a way usable for mobile devices especially during those traffic spikes.

The design company doing the work for me suggested a responsive approach I went and read-up on this and my major concern with this approach is that while the page and images scale to view nicely on a mobile device the page size does not which means the page download size is the same on an iphone as it is on my 1024 × 768 and because I want my pages to be fast loading on mobile devices and because I get regular spikes in traffic the responsive option for mobile is not the optimal mobile solution for me.

  • Am I correct in thinking that responsive design was not the best approach for fast loading mobile pages? Did I make the right decision?

I instructed them to design custom mobile templates for the 5 top traffic (most popular) areas (these areas also have a lot of images in them), built to be light and most visually usable for viewing on a mobile device. They built a mobile site the landing page of which has 5 links which link visitors to custom mobile templates for that section. On the footer menu is a link to the Full Site.

Now… the design company has told me that the site will detect the user agent of the visitor and if it detects a mobile device it will serve up the mobile version of the site.

My concern is that someone coming to my site on a mobile device will see the most popular content sections (built with custome mobile templates) but will need to click on a ‘Full site’ link to see the rest of the site which hasn’t been built for mobile and i’m concerned about this transition and how the rest of the site will look to them when they move from mobile to non-mobile pages within the same site.

Someone I met today suggested doing a combination of custom mobile templates for the 5 most popular areas (as we have done) and responsive design for the rest of the site. Is this good advice?

I’m afraid that i’ve mucked up my approach to mobile and would appreciate any advice.

It’s a common misconception: responsive web design is not related to mobile web sites. One is about CSS, presentation, the other is about alternative content.

Responsive design can only help you with layout. What this means is that it will help you with those mobile templates as well, since mobile display sizes are from 240px up to 1024px and beyond.

It’s not the best idea to have only some areas of your website covered by a mobile approach. You have to consider this too: not all desktops mean uncapped 100mbs/s connections on latest i7, and not all mobiles means monthly 50Mbs at 7kbs/s on poor devices. Quite the contrary. So what you really should ask your self is if you need to build a lightweight version versus a more rich version. If that, I’d seek ways to streamline content/page.

Thank itmitica - this whole mobile business is a maze to me.

So what you really should ask your self is if you need to build a lightweight version versus a more rich version.

Part of my development/design was a lightweight build. Do you mean a seperate version of the site for mobile?

I’m still confused as to the best approach, responsive design addresses layout only however it doesn’t address page download size - it serves up the same size (kb) content irrespective of screen size - correct? What I want is an approach that also proportionally reduces file e.g. of images for mobile - how do I do this?

So for the high traffic areas of my site I got custom mobile templates designed. One of those areas presents cars for sale. The mobile templates will present the cars one at a time, obviously the presentation of the images will be smaller on a mobile device - but how to I make sure the file size of them image has reduced proportionally? I thought asking for custom templates would address this but what is going to proportionally reduce the image size for example - i’m using Drupal as a CMS.

What I found in the tender process for my website was that web shops presented responsive design as THE mobile solution. What they didn’t mention is that the page load is the same which for me isn’t a mobile solution.

How do I get a solution that not only presents layout proportional to the device viewing it but also file size?

Sorry for all the questions i’m just finding it very difficult to get a straight answer to this from the people working on my site.

One of the things that’s annoying to many mobile users is WHEN you make a dumbed down version for mobile; equally annoying for desktop users is when you have such a fat bloated wreck they’d rather use the mobile version. Really it needs to be a balancing act between the two.

There’s no easy answers either; Something I’ve discovered is you’ll get just as many iPhone users complaining about how you dropped the layout to one column so they can’t sideways navigate or pinch-zoom like other websites, as you will people complaining about having to pinch-zoom to get around.

Really though, the maintenance headaches of maintaining two copies of content is where I draw the line – the entire point of HTML is to deliver content in a device neutral manner to let the user agent (browser) best customize the appearance to the capabilities of the target device, just as the entire point of CSS to let developers specifically target devices.

Fast loading or not fast loading has little to do with ANY of that. Fat bloated markup, excessive content, presentational content in the markup where you can’t remove it via the media queries, and endless pointless javascript for nothing are a much, much greater concern.

Though without seeing the page in question, anything we tell you on that front may as well be gibberish… As there are questions we’d need answers to; what’s your code to content ratio on the markup? How much CSS are you using? How many images? What size are those images? Are they presentation or content? Are they divided up properly between the CSS and HTML. How much javascript have you used? Did you provide hooks to disable broken JS on small screens? (something I’m still in the process of adding to my own pages.)

Not seeing your markup, CSS, content, AND all your methodologies – we really are just guessing. I mean, if your total page (HTML+CSS+SCRIPTS+IMAGES) is <100k in a dozen files WITHOUT resorting to any trickery (like white-space stripping), I’d say you’re worried over nothing… if it’s a megabyte total in 50 to 100 separate files with at least half of that as scripting, I’d tell you to throw it out and start over.

There is little if anything on a properly written site in regards to responsive or not that should have a significant speed impact on a website.

Well, unless you count the things that make scrolling painful if overused on a page in mobile – like text-shadow, box-shadow, rounded corners, linear-gradient, etc, etc… which is why on my smallScreen.css files I usually disable all of those.

I’m none the wiser.

Is responsive design the optimal solution for viewing a website on a mobile device?

My understanding is responsive deals with page layout only by rendering a device appropriate layout.

However it renders a page with the same page load for every layout view.

Speed (fast page load) is an especially important factor for mobile devices, and if the site gets spikes of mobile traffic then its even more important for the page to be fast to load.

So should I have agreed to a rsponsive approach or what should I have asked for for the optimal solution for viewing my site on a mobile device?

It can be. But that depends on each website.


Let’s digress a little.

Responsive design is something like dynamic CSS. A modern browser can query. It involves the so called media queries and it can be used to apply core modifications to layout, typography, all style really, based on what it’s getting back when asking:

Browser: I’m @media (min-width:240px) ? What should I do?
CSS (media query): Please dear UA, can you nav a { display: block; }? Thanks.

Browser: The user has rotated the device from portrait to landscape. I’m now @media (min-width:320px) ? What should I do?
CSS (media query): Thanks for letting me know about user activity, browser. Can you please now nav a { display: inline; }? Thanks again. Hope to hear more from you.


Going back to the problem you have. Having a optimal site for mobile is like being half right. You should first have a optimal site. If that, you don’t need a mobile version, responsive will do.

But if your site has to have heavy content, which means it’s a lot per page and some items on the page really need a big screen, not that is not optimized!, and if your so called desktop users are majority and main target, you should consider a shorter mobile version.

What a mobile shorter version will do for you? It would provide a temporary alternative option for your desktop users, that are now on the move. It will also attract and give a (good) taste to occasional users that use mobile more to go home and use your desktop version for the complete features.


To address your question directly: optimization of resources and responsiveness of layout are complementary: RESS, they don’t exclude one another. You need responsiveness for desktop too, and you need content optimization for desktop too.

You need simple to understand sites on desktop too. That is to say that mobile websites don’t have to look poor.

I don’t agree with the example, since it takes ages to load on desktop, even on my 20mbs connection, or with the, which has some issues because it relies too much on JS, but I believe RESS can grow into an alternative better way for having to build,,, and whatever *** the future may ask from web devs on a single web site.

Optimization together with responsiveness. Old web dev concepts, some may say, and I agree, though I believe it’s about a more mature level now, in the approach we take, since today’s technology is so much different.

“Responsive design” is currently a buzzword/phrase for using newer kinds of styling methods to style content differently on different devices. It’s not a complete solution to designing for mobile, as your question about page load illustrates.

There are moves afoot to deal with this too. For example, several people have proposed (and continue to work on) solutions for servicing up differently sized images depending on the requesting device. Examples include:!/guide/src

I believe so when done properly, but it can just as easily be done poorly. Good content semantically marked up SHOULD be good enough for all devices assuming you don’t shoe-horn too much crap on the page. IMHO if it’s too slow for mobile, it’s too slow for desktop too.

That’s why my target for the average page on a website is 72k in 16 or less separate files; which makes it fast EVERYWHERE. Media queries and shifting the content around doesn’t change that. You have a megabyte sized train wreck built from dozens or even hundreds of separate files, it’s going to suck EVERYWHERE, just more so on mobile… and unless it’s something inherently heavy like a image gallery, I refuse to deploy any page larger than 144k in 32 files.

Setting meaningful size limits helps EVERYBODY.

Which has NOTHING to do with if it’s responsive or not, and everything to do with how good your markup is, how minimalist your content is, and if you’re packing it full of presentation for nothing – which again without seeing the site in question means we can’t tell you anything useful in that department.

Though responsive CAN help you reduce the bandwidth use – while CSS is often loaded used or not, background images for example if you strip them off the layout with the media query aren’t even loaded – poof, faster page.

Responsive done right is great on modern phones; done wrong it’s rubbish… and a fat bloated slow poorly written site is a fat bloated slow poorly written site REGARDLESS of if you are using media queries or not.

Because while people like us may be sitting on 20mbps or faster broadband connections, my neighbor at 768kbps or the folks 50 miles north of me for whom 33.6kbps dialup is a good day, fat bloated sites still suck on the desktop – without even getting mobile in the equation… which is why I still try to keep them in mind.

It’s one of the few places I agree with the “mobile first” crowd – making a fat bloated slow page for desktop users is better how exactly? But again that goes into design philosophy differences – there’s a bitter pill that really stings most ‘designers’ need to have shoved … “I can’t swallow that!” <farnsworth>Good news everyone!</farnsworth>

… and that pill says: “People visit websites for the content!” – NOT the goofy layout elements, stupid distracting animations and images we hang around it… cut down to the bone what people are actually visiting for, give it a wee bit of decoration, and move on.

You may want to look at some of the questions I posed… what’s your code to content ratio on the markup? that’s HTML… if you deleted all the tags and just had the plaintext, and compared it to the size of the HTML output, what’s the ratio? Anything in excess of 3:1 code to content is usually fat bloated poorly written rubbish; which means slow to load and slow to render… how many DOM elements are there? More DOM elements the longer it takes to render (part of why I think HTML 5 is rubbish, encouraging the use of all these pointless extra structural tags)… How much CSS do you have total? Honestly if you have more than 48k for desktop/screen (one media target) for AN ENTIRE SITE, your CSS is fat bloated trash… Did you take the sleazy shortcuts of ‘frameworks’ like YUI, Mootools, blueprint, jQuery? Welcome to extra pointless slow overhead.

Which is why responsive layout is a non-issue when it comes to site speed.

Honestly, I’ll take responsive over custom for each any day, but you have to plan that way from the start, or start out with a minimalist website from the start. If you have good clear content, logically divided into separate pages, don’t play any of the goofy content/ajax tricks to replicate what we’ve been told for a decade NOT to do with framesets, the so called “responsive” layouts just make sense – even more so if you’ve just been practicing fluid or semi-fluid layouts all along; you should already HAVE a layout that adapts to screen width, this is just a simple extra step.

Though if you’ve been sleazing out crappy fixed width layouts with crappy fixed metric fonts using outdated presentational markup techniques, not only will you fit in well with the HTML 5 crowd, “responsive layout” may as well be an alien language.

Many thanks for all you’re comments.

responsive layout is a non-issue when it comes to site speed

Now deathshadow60 this is what I don’t understand, on my site images are content, you can sell your car and upload images of it that you can scroll through. If i’m using responsive design as my solution for mobile devices then responsive will resize these images for my iphone but the image file size will not reduce proportionally so the page size is the same for a iphone as it is for a desktop. Its not that the page size is bloated but that i’m more likely to have a faster connection via my desktop than mobile device hence the page load speed is likely to be slower on my iphone for the same size page.

Is it fair to say that responsive design is ‘just’ a solution for layout for different size screens? It is not a solution for the presentation of content for mobile devices in and of itself until it develops to the point (or in conjuction with other techniques) where it proportionally reduces the size (kb’s) of the page elements it reduces in size e.g. images.

Thanks again to all of you for your comments, it looks like I signed up for custom mobile templates for the top areas of my site and in my rejection of responsive design may have made a mistake - I don’t even know how the custom templates will manage the images, for all I know my developers may plan to just bring the large versions into the mobile version resized and i’ll have the same issue of large file sizes for small images and won’t have gained anything in taking the custom route.

I’m talking to them next week so i’ll have a lot of questions .

For what it’s worth I would always try for one website, i.e. a responsive design.
Separate mobile versions of content are sometimes necessary but most sites out there are in real need of simplification.
I’m a fan of Responsive Design and Mobile First, they force you to focus on the most important stuff and present that first on both mobile and desktop.

The nature of the web is presenting content to users in a medium that allows anyone, anywhere access on any device.

Responsive images are a hot topic at the moment, it’s possible to serve different res images to different screen sizes.

Is it fair to say that responsive design is ‘just’ a solution for layout for different size screens?

It’s the most obvious case but there are others, responding to print / projection media types are others.
Responsive web design is about embracing the flexibility of the web and making your content present nicely under more circumstances.

I would advise against a mobile specific site because having that split means more to maintain and both will suffer.

And by “hot topic”, mark here also means that right now there is no great solution. They all suck in some way. Some rely on user agent sniffing (and then you hope you’re right), some try Javascript detection (slow since by the time your JS starts running, the browser’s pre-parser may have already grabbed all the img src urls and maybe already requested them… so now double-requests),

and some people let the one website always start with the smaller image (for everyone) and either uses Javascript again (so this assumes desktop users don’t mind 2+ requests per img… might not be true) or offers a link to a larger image (this is kinda nice, allows even mobile users to download the larger image if they want it for some reason! For buying and selling cars/products I would maybe prefer this).

You could also go for text-heavy pages and lots of thumbnails+links so when people ask for an image, they’re doing it consciously rather than a robot on your server trying to guess what the user wants.
Mobile Funda (a real-estate site, so lots of house pics) does this. The “main” home photo is loaded by everyone (and it’s big in filesize and shrunk design-wise to fit in any sizes viewport), while all the other photos are behind a link. Users who find photos important will only download them when they actually click a link to request them, and we know photos are quite important when selling houses. example house page

You know, why not do some testing? You could try it one way for a while and then another way, see what people say. Or try to send some IPs one version and others another. There will always be mobile users out there who are more than willing to put up with a slow-loading site (and maybe all sites are slow-loading for them anyway because of their network) in exchange for all the content available to desktop users… and there will always be mobile users who pay per kilobyte and want to rip you a new one because you loaded a 600kb detail image for whatever reason.

I’m sure your design company recommended a reponsive site because your content is varied and changing quickly and regularly. This would make having separate sites more difficult to manage, even if you bought software to do a lot of that management for you.

In any case, since you’re meeting with them again next week, educate yourself and check out those links ralph posted. Know especially that right now there is no one good way to do responsive images and the standards bodies and browser-makers are wrestling with that as we speak.

Yes, that’s a pretty good summary of where responsive images are at :slight_smile:
I haven’t had a need to worry about serving different images myself but for certain sites like news it would have a big impact.

Scott Jehl’s polyfill works if you need it, most sites/apps don’t though.

Mobile is really testing the standards process.
The developers are trying to solve real problems and can’t wait for the standards bodies and browser vendors to implement it for us.
There’s the potential for implementing something non-standard and then falling over when the ‘real’ solution is available, but code can always changed. I feel where we(developers) can improve something we should.

I am in the process upgrading an old site and trying to make it a responsive layout.

Is it safe to use test the PHP $_SERVER variable and if “mobile detected” then render a different page?

The current page works on my old iPhone and curious to know if it always manages to detect a mobile.

To test the site I have a page with a single link to the modified test site. Mobile detection is shown in red at the top right hand of the screen.

Currently if a mobile is detected then a reduced size image is displayed and no Google Adverts.

Test site:

It looks like you’re on your way to reinvent RESS:

Mobile detect?


I use a PHP Framework that has a comprehensive “user_agent” detection library. It is quite easy to detect for mobiles and select the modules to output.

Did you open the page with a mobile and if so was correct mobile detected?

Why is additional overhead of Javascrript required?

Is it safe to use test the PHP $_SERVER variable and if “mobile detected” then render a different page?

Yes, detecting for mobile browsers is always done by inspecting the userAgent string sent from the browser. As long as your using an up to date detection script you should be catching most browsers you care to support.

But like I was saying in my previous post this is normally not the best solution, it’s better in my opinion to create one website for all devices and use javascript / css to modify that content for the users device.

I think that screen content should vary according to screen size. Using server side userAgent to tailor the content seems logical rather than downloading one page then modifying the browser to suit the content.


I have just been looking at the new mobile site for the I was impressed at how the images retain the same source file names BUT dynamically vary in size when the screen is resized!!!

file-size screen-size
2.61kb 165x92
16.1kb 555x312
24.3kb 736x414

When resizing the browser I did manage to obtain an incorrect image which can be see in the following screen dump:

Only if
a) it’s not a disaster if it screws up (some new something comes out you don’t have in your DB, or someone’s managed to modify their UA string)… just maybe not ideal
b) your db listing is regularly updated with new UA strings

Steph Rieger from Yiibu has a slide set regarding I think responsive content and shows some examples of having a separate (or someone else’s) db holding a listing of these UAs… you aren’t updating a never-ending list, someone else is, and only the first time an unknown client makes a request to your server is an additional request sent from your server to this UA DB to check… then Steph recommends having your server “learn” from each new/unique client (she called this latent knowledge). Not only screen size but possibly other things like JS and CSS capabilities, certain native things and whatnot.

Suppose your users disagree with you. What are their options then? (ideally, if you won’t give them the “full” content, offer them a link. That way, if they click it for more “desktop” content, they can’t complain (much) about bandwidth issues… they made a manual request for it).

Again, keep in mind there are desktop users who use the while on desktop+ (maybe it loads faster? maybe it works better with assisstive technology (this is definitely true with Twitter)? Maybe it fits on a squished browser while the user has multiple other applications/windows open and is a power user?), and there are mobile users who do what they can to reach the “desktop” version (they feel they’re being cheated of information? the are familiar with the desktop version and don’t want to spend the time re-finding where the information has gone now in this other design? They want to view pictures?). I think so long as users have this as an option, trying the detection at first-contact isn’t necessarily bad.

When the new Boston Globe was first released as a responsive poster child, before the paywall stuff was added, I saw something similar, though it only worked if a clean, cookie-less browser opened the page with a small width. The smaller image loaded by default, and I believe it was Javascript and the server on the back working together to check screen size and update the image. Once I got the large image (and it was really really wide… almost wider than my screen), shrinking my browser didn’t do anything but cut the image off (it was a background image so could not be shrunk like you could with a content image).

So I think your screenshot is either in-between some script’s threshholds, or a hiccup.

Yes, it was detected correctly. You have probably something like below 10% cases to worry about, where the user agent string will be the wrong one.

The problem is not that: detecting mobile.

The problem is this: detecting connection parameters like speed, bandwidth, and info about the user’s data plan, like how much has he left before the bandwidth starts to drop from 2mbs to 154kbs, and user wishes, like he really really wants that big image, despite being on mobile, despite using EDGE, despite having to pay 1$ per extra minute, or like he really really wishes you wouldn’t send him that big image, despite being on desktop, despite having a 20mbps connection, despite negligible costs. Can you do that?

Thanks for your replies.

So I understand that reponsive is a good “mobile solution” if my content is optimised for fast page load but what if, as in my example, I have a need for people on mobile devices to scroll through a number of images e.g. car for sale. I keep coming back to the same problem, its ok saying my content needs to be optimised but at the end of the day a desktop connection tends to be more forgiving and if my visitors need to scroll through a number of images of the car they are thinking of buying then a desktop connection can usually support this - the problem is if they want to view the images of a car for sale via a mobile device - responsive design will scale the layout and images in pixels but not in kbs (needlessly adding kbs to the download aweight nd sucking up my visitors data allowance) so how should I handle this situation - responsive seems to me to fail when you need to present, on a mobile device, content other than text?

Responsive cannot scale images in kbs as well as pixels - correct? I’ve read through the links above that there’s work being done on trying to address this but its not there yet. So now what, responsive does not sound like a solution for my my needs.