Skip to content

24 ways to impress your friends

Conditional Loading for Responsive Designs


Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.


This topic is so incredibly important for web developers to pay attention to.

Where I run into some confusion is identifying the fine-line-difference between responsive and scalable. Responsive implies that there are needs (inferred or gathered) to be addressed. We all know that a user viewing our sites on mobile devices have needs that are different than those on desktop screens. Responsive design goes a long way to begin addressing those needs. But what happens when I simply resize my browser window? Do my needs change? Or does everything just need to scale?

Responsiveness and scalability appear to be closely related, yet remain distinctly different. The former aims to solve needs, while the latter ushers/facilitates a design to the point until the user’s needs change.

Daniel Van Cuylenburg

I think there should be a beginning design (mobile) and ending design (large screen) put together in the early stages which can then be used as the boilerplate constraint (so to speak) for whatever then needs to come in between. This way, you can account for what elements need to come in and go out.

From a building point, yes I probably agree, mobile first.

Rob Tarr

I think this is great, I did something recently when loading in twitter follower avatars. Paul Hayes recently wrote an article ( about triggering JavaScript based on events fired from CSS properties. It’s still not a perfect solution, but I think it will help with these sorts of problems.

Being able to trigger JavaScript events based on media queries allows us to be sure that if the page triggered a smaller media query when it loaded and then the browser was resized, that the additional content gets loaded in. Jeremy’s if statement works great on page load, but won’t load the content if the page size changes.

Jeremy Keith

I was talking about this technique at a workshop recently and Andreas Nebiker pointed out that it feels a little wrong having to specify the breakpoint (640 pixels in this case) in two different places: the CSS and the JavaScript. He pointed out that you could instead test for some updated CSS value in the JavaScript.

I’ve written some more about it on my blog if you’d like to know more. Basically it means you only have to specify your breakpoint once: in the CSS.


IDA: I think that if we look at the business implications of design techniques such as the one in this post, it is undeniable that the needs of mobile users are VERY different than those of a user on a desktop screen. And it is not necessarily a need rooted in speed all of the time. Of course the needs of users on different screen sizes do converge at points, but the underlying needs are different.
I think Jeremy inadvertently touches on this in the example. Was Jeremy displaying the the results of a google search on a larger screen size simply because he had the screen real estate to do so? I don’t think so. I think that there is an underlying assumption about user intention as screen sizes change.
If a user is on a tiny screen and is mobile, every business behind a website needs to ask why would someone sitting on a train look us up on their phone? What would they be looking for?
I believe that it is short-sighted of us as web developers to assume that the needs of those on smart phones are the same as those on a desktop. At the end of the day, this becomes less about actual screen size and more about user behavior and how we respond to it in our designs.

Elliot Lewis

I have the same query as Paul (Boag). It’s not the focus of the article and I know it’s the concept rather than the implementation but…

‘It’s taking progressive enhancement to the next level’

This is a technique that’s dependant on JS, so is JS not a consideration for progressive enhancement now? With JS turned off a desktop user gets a sidebar with a link away from the site. Is this an OK trade-off? I guess it depends on the content but it’s getting harder to build dynamic sites that don’t rely on JS.

Mark Stephenson

Merry Christmas Jeremy.

The technique you described on your blog to test for a specific CSS property to avoid specifying your breakpoint more than once still violates the DRY principle. For example if you decide the sidebar is no longer to be floated right you still have to change both your CSS and Javascript.

Do you have any ideas how to avoid this, Oh Wise One?


Can I quibble just a teeny bit with the use of “bloated” to describe the desktop version of a site? Perhaps I’m being over-sensitive, but to me it suggests that Mobile-First isn’t so much a design strategy, intended to make it easier to properly accommodate the wide range of modern browsing devices, but is instead an attitude towards those devices. It hints that the desktop site is really just the mobile site with a bunch of extra crap sludged on top.

Nicolas Chevallier

Be careful with this technique: it can lead to big problems in terms of SEO because even if Google indexes and load AJAX, the easiest way is still to have much of the displayed content in this original HTML file.

But the example is obviously a very good solution and you can even extend it to widgets like Facebook, Twitter and others that may be useful on the desktop version but unnecessary for the mobile version.

Sumana Harihareswara

Thought you might want to see a similar strategy that Wikipedia uses:


slides: (sorry, Textile doesn’t work because of the parentheses in the URI)

Jeremy Keith

Divya, I’m sorry to hear that you think this technique is antiquated but I think you may be focusing on the specifics of the width detection rather than the idea.

As I said, I’ve posted some follow-on ideas on my blog about detecting CSS changes rather than directly measuring viewport width with clientWidth.

But in any case, I hope you can see beyond the specifics of my unworthy antiquated if statement and recognise that it is the thinking behind conditional loading that is important rather than the code itself.


I’m trying to do a mobile first design and thought conditionally loading Google DFP ad tags depending on size would be a good idea. Can’t seem to get the JavaScript to be executed once it’s loaded into the document.

I’m completely new to DOM manipulation but I think what I need to do is causing me pain because you have to insert new HTML and JavaScript into the document because the ad call is dependent on a like-named id. See here:

Any advice would be greatly appreciated.

Ron Zasadzinski

Jeremy – thanks for leading the way. Concise and brilliant synthesis of responsive web design, progressive enhancement and the mobile/content first approach. What an exciting time this is to be a web developer.


In this mindset you expect that mobile will be more important then desktop in the future?
I like the idea because if you think of it, it is much simpler to start with the basics for mobile and than upgrading it for desktop. Starting with a desktop design and than stripping it to a mobile version can give much more problems.

Ivan Wilson

“In this mindset you expect that mobile will be more important then desktop in the future?” – Kurt

Why the either/or? It this point, I am changing my strategy to be more “device” focused instead of mobile or desktop. Same process though. Which makes loading of assets (may it be content or scripts) even more important in terms of performance/speed (i.e. do you really need that much for this situation?)

James Wragg

The view condition on which this code runs is undoubtedly simple & good for this example, but anything more complicated and it may be more useful to use window.matchMedia which allows you to test @media rules (inc. pixel-ratio, orientation etc.) from your Javascript.

A polyfill is also available in matchMedia.js.

Matt Stauffer

I wanted functionality like this, but I wanted to be able to use PHP to actually display different content on the initial page load, so I hacked together Simple RESS (inspired by Lukew’s article imagining RESS).

It doesn’t benefit from the delayed page load, but it might be something to pair together with this technique to responsively adjust content.


The issue is that the technique will not work with a browser you are resizing manually. I’m not sure what is the proper solution though.

James Pearce

It’s worth binding size-queries to the document’s load event (or even, in some cases, to a point some time after that).

On Android v2.3 for body.clientWidth, for example, (and other platforms, if there are different measurements you’re querying), these values can change radically during the page’s lifecycle.

There’s data here

Paul Boag

I guess the only problem with this is it is reliant on JS. If there is no JS then there is no cat news. Should we care about this? I guess its only secondary content so isn’t the end of the world.

Mike Mella

Great article, but am I missing something?:

<blockquote>Visitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.</blockquote>

When I view the “See the result” page, it’s the same on my iPhone as it is on my desktop. The sidebar is always visible. I don’t see any link to the search results.

That page should be a working demo, right?

John Smith

It seems to me that a good solution [for those worrying about lost content] would be to load the additional content once the user scrolls down to it, seeing as in this specific example (and in most mobile designs) the floats just end up beneath the main content. Having said this, as a user I really hate seeing my page lengthen just when the end is in sight; a button may be a less violent approach.

On a less logistical note, the question is ‘who needs to see this aside’ (1) vs. ‘who wants to see this aside’ (2). The first may be possible to deduce from the content of your website, but I’m not sure (2) can be (as I assume has been done here) implied from the device: I cry every time youtube gives me only super-LQ videos when I browse it with a Nokia.

Divya Manian

Jeremy, I would be happy if this article was used to explore techniques that are being resolved right now by various developers around this. As you know very well, this is not an area where there is a simple, defined answer yet. But the thrust of the article suggests there is an easy one, especially one that will not work most of the time outside of a desktop browser.

Drew McLellan

Divya – perhaps you should write an article like that yourself.

You’ve posted some links to other’s work on this subject, which is helpful. Thanks.

As with all web techniques, there’s things that can be improved and more to learn as our understanding grows. The entire scope of that work could not effectively be summed up in one article without leaving the reader bamboozled. The purpose of this article was to introduce the technique, and it does so very helpfully.

David Goss


I think that there is an underlying assumption about user intention as screen sizes change.

The problematic assumption for me is the one that assumes phone users are always “on the go”. You mentioned the train in your comment, which is the most common and cliched example I hear. I browse the web an awful lot on my phone, but more than half the time I am sitting still and want the same things I’d want if I were at my computer. Moreover, even when I’m “on the go”, I still want those same things. Businesses that think their desktop and mobile users have totally separate needs should go away and think about what the purpose of their website actually is.

Great article Jeremy. Only thing I’d add would be to hijax the link to trigger searchNews when clicked rather than taking you off-page. But like you said, it’s more the idea than the code.

Jeremy Keith

David Goss wrote: “Only thing I’d add would be to hijax the link to trigger searchNews when clicked rather than taking you off-page.”

Excellent idea! You’d still only need to write the Ajax code once, but you’d simply change the event that triggers it based on viewport size:

On a large viewport, trigger the Ajax request once the page has loaded.

On a smaller viewport, trigger the Ajax request when the link is clicked.

I like it!

Jeremy Keith

Divya and the Jameses Pearce and Wragg have already provided some useful links to research and techniques for measuring layout. Thank you muchly. Here’s another handy related resource:

Scott Jehl has written some conditional-loading code for a similar situation, which he calls the anchor-include pattern. It progressively enhances links to fragment identifiers in other documents so that the contents of that fragment is requested once the page has loaded and inserted into the DOM (either before the link, after the link, or replacing the link).

You could take that code and wrap it in a test for screen width—be it using the humble but flawed clientWidth, the more powerful matchMedia, or by testing for a specific CSS property. In fact, Scott has updated the code so that you can supply an optional threshold property to specify a pixel value that the screen needs to be above in order to trigger the Ajax request.

It’s written in jQuery but I don’t think it would take too much rewriting to make it work without that dependency (although jQuery does make the Ajax part a lot easier).

Jeremy Keith

Elliot, I don’t see JS a requirement. All of the content is always available: sometimes it requires an extra click (small screen or non-JS) and sometimes it is provided after page load (large screen with JS enabled) but crucially, the content is always accessible.

Also, the content of the page does not require JavaScript; it is delivered in HTML. The extra stuff (delivered in the sidebar) is not the main content of the page. In fact, the real question shouldn’t be “can I deliver this content to users of any device?” but rather “should I be delivering this content to anyone?”

A good way of thinking about what constitutes the content of a page (as opposed to nice-to-have additional stuff) is to consider what information would be delivered in an alternate representation. For example, if this were a JSON or XML file, what content would be represented?

Amber Weinberg

I’ve been doing a lot of responsive development lately, but I’m still doing the “desktop down” approach versus the mobile first. I’ve had problems trying to wrap my brain around that approach as it requires a lot of additional thinking. Not sure if mobile first is the future or not of front-end development, but I need to experiment more :)

Jeremy Keith

Clayton: Yikes! I’m not quite sure what happened there. I somehow managed to over-write an entire blog post. It may be down to the fact that I’m a complete idiot.

Well, I’ve managed to recreate it from memory so it’s back online.

Thanks for the heads-up. Sorry about the confusion.


I would like to make a comment to Matt’s comment: I think it’s totally wrong that the needs of the user changes when on a mobile device. Especially the need for specific content. I’m so sick and tired (and I know I’m not alone) of having to use a laptop to view the full content. I actually rather like people to keep their desktop design if the alternative is to make something that’s missing some of the content.

With that said I do understand that the users need for speed might have changed and that I think needs to be taken into account.

On Jeremys article. I like the solution and what I liked most was that the content was still accessible and not just stripped out.


Hi Jeremy – The link to your post about testing for a specific CSS property is pointing to the original article on your site. Building suspense…?

Impress us

Be friendly / use Textile