On the eighteenth day of last year’s 24 ways, Paul Hammond wrote a great article called Speed Up Your Site with Delayed Content. He outlined a technique for loading some content — like profile avatars — after the initial page load. This gives you a nice performance boost.
There’s another situation where this kind of delayed loading could be really handy: mobile-first responsive design.
Responsive design combines three techniques:
- a fluid grid
- flexible images
- media queries
At first, responsive design was applied to existing desktop-centric websites to allow the layout to adapt to smaller screen sizes. But more recently it has been combined with another innovative approach called mobile first.
Rather then starting with the big, bloated desktop site and then scaling down for smaller devices, it makes more sense to start with the constraints of the small screen and then scale up for larger viewports. Using this approach, your layout grid, your large images and your media queries are applied on top of the pre-existing small-screen design. It’s taking progressive enhancement to the next level.
One of the great advantages of the mobile-first approach is that it forces you to really focus on the core content of your page. It might be more accurate to think of this as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essential.
But what happens when you apply your media queries for larger viewports and you do have sidebars and multiple columns? Well, you can load in that nice-to-have content using the same kind of Ajax functionality that Paul described in his article last year. The difference is that you first run a quick test to see if the viewport is wide enough to accommodate the subsidiary content. This is conditional delayed loading.
Consider this situation: I’ve published an article about cats and I’d like to include relevant cat-related news items in the sidebar …but only if there’s enough room on the screen for a sidebar.
I’m going to use Google’s News API to return the search results. This is the ideal time to use delayed loading: I don’t want a third-party service slowing down the rendering of my page so I’m going to fire off the request after my document has loaded.
Here’s an example of the kind of Ajax function that I would write:
I’ve provided a callback function called displayNews that takes the JSON result of that Ajax request and adds it an element on the page with the ID newsresults:
Now, I can call that function at the bottom of my document:
<script>
searchNews('cats');
</script>
If I only want to run that search when there’s room for a sidebar, I can wrap it in an if statement:
<script>
if (document.documentElement.clientWidth > 640) {
searchNews('cats');
}
</script>
If the browser is wider than 640 pixels, that will fire off a search for news stories about cats and put the results into the newsresults element in my markup:
<div id="newsresults">
<!-- search results go here -->
</div>
This works pretty well but I’m making an assumption that people with small-screen devices wouldn’t be interested in seeing that nice-to-have content. You know what they say about assumptions: they make an ass out of you and umptions. I should really try to give everyone at least the option to get to that extra content:
<div id="newsresults">
<a href="http://www.google.com/search?q=cats&tbm=nws">Search Google News</a>
</div>
Visitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.
I’ve been concentrating on HTML and JavaScript, but this technique has consequences for content strategy and information architecture. Instead of thinking about possible page content in a binary way as either ‘on the page’ or ‘not on the page’, conditional loading introduces a third ‘it’s complicated’ option.
This was just a simple example but I hope it illustrates that conditional loading could become an important part of the content-first responsive design approach.
Comments
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.
02/12/2011
It seems incredibly antiquated to mention this technique, when there are better researched ones available.
- There is matchmedia that has been mentioned by James Wragg.
- clientWidth is not always accurate as James Pearce has found out
- Jon Neal has done some exhaustive research with several others to find out what mobile devices actually use
Vote Helpful or Unhelpful
02/12/2011
Great example of how this can be used, and a good mindset to get in to focussing on the content first.
Glad I read this before I tackle the next responsive site.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
03/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
This definitely seems like the simplest approach to managing assets/elements for various viewports.
Thanks for writing this, Jeremy!
Vote Helpful or Unhelpful
02/12/2011
I am doing this will backbone.js and the new layout manager:
layout manager
This has many advantages. You can store multiple layouts (even remotely) and lazy load them.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
Thought you might want to see a similar strategy that Wikipedia uses:
video
slides: http://wikitech.wikimedia.org/view/File:OSCON_2011_-_ResourceLoader_-_Trevor_and_Roan_(with_notes).pdf (sorry, Textile doesn’t work because of the parentheses in the URI)
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
This is a really simple but great solution for designing responsive sites in the UK where mobile web speeds aren’t great.
Vote Helpful or Unhelpful
02/12/2011
I think this is great, I did something recently when loading in twitter follower avatars. Paul Hayes recently wrote an article (http://www.paulrhayes.com/2011-11/use-css-transitions-to-link-media-queries-and-javascript/) 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.
Vote Helpful or Unhelpful
02/12/2011
“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?)
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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
Vote Helpful or Unhelpful
02/12/2011
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.
Vote Helpful or Unhelpful
02/12/2011
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?
Vote Helpful or Unhelpful
02/12/2011
I really think this is a simple and effective solution to manage side content for various screen sizes. Thank you.
Vote Helpful or Unhelpful
03/12/2011
@Paul Boag
Sure, it starts with the cat news. God knows where it could end up.
Vote Helpful or Unhelpful
03/12/2011
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.
Vote Helpful or Unhelpful
03/12/2011
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.
Vote Helpful or Unhelpful
03/12/2011
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.
Vote Helpful or Unhelpful
04/12/2011
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.
Vote Helpful or Unhelpful
04/12/2011
@Matt
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.
Vote Helpful or Unhelpful
04/12/2011
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!
Vote Helpful or Unhelpful
04/12/2011
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).
Vote Helpful or Unhelpful
04/12/2011
Tried to improve your JS by making it more modular, cleaner and inline with current best practices: https://gist.github.com/1430996
Vote Helpful or Unhelpful
06/12/2011
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.
Vote Helpful or Unhelpful
06/12/2011
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?
Vote Helpful or Unhelpful
06/12/2011
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…?
Vote Helpful or Unhelpful
06/12/2011
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 :)
Vote Helpful or Unhelpful
06/12/2011
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.
Vote Helpful or Unhelpful
06/12/2011
Thanks! This was amazing, and a great starting point for someone interested in learning responsive design. <3 you.
Vote Helpful or Unhelpful
15/12/2011
Already applying this for my projects, nice to know that more people will manage the content this way.
Thanks for writing this anyway !
Vote Helpful or Unhelpful
19/12/2011
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?
Vote Helpful or Unhelpful
23/12/2011
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: http://stackoverflow.com/questions/8610574/inserting-and-executing-conditional-javascript
Any advice would be greatly appreciated.
Vote Helpful or Unhelpful
Impress us