I’m guessing that most developers have not worked closely with ad servers and many may not be familiar with the technology behind web advertising at all. So before I get into it I’ll say a few brief things about the advertising ecosystem and how ad servers generally work.

Ads are hard

The thing about web advertising is that it’s not a simple two-party handshake. The process is full of intermediary parties and technologies, a summary of which is shown in the adjacent graphic. (Here’s a more detailed illustration of the ad ecosystem… but be warned, it may hurt your eyes a bit.)

See, the challenge with responsive ad models isn’t with media queries or JavaScript, it’s introducing a solution that works for all these parties. There’s a timing element too that makes it more challenging. Responsive advertising is not something a publisher can wade into—the only way it works is for the publisher to have a complete set of “responsive compatible” campaigns. No sane publisher is going to sacrifice ad revenue for responsiveness, so whatever solution appears has to, in a sense, work all at once.

It’s not an insurmountable problem—ad vendors and start-ups will soon figure it out—but it requires a higher level of cooperation than the average innovation, meaning its introduction into the ecosystem will need to follow a different path.

How ad servers work

Publishers that sell display advertising manage ad campaigns through an ad server, which is basically a CMS for ads. Positions or zones for each ad unit are defined on the page and then campaigns are set up in the ad server and configured to flow into the positions based on a number of variables. The rest goes like this:

Usually the publisher (e.g., CNN.com) does not receive the ad directly from the advertiser (e.g., IBM) but from an agency (e.g., Blahblah Interactive Inc.) representing the advertiser. In addition, the ad itself (called a “creative”) is usually not given directly to the publisher but is instead uploaded to a third-party ad server (e.g., DoubleClick). The third-party ad server provides JavaScipt/Iframe “tags” that the publisher then loads into its ad server. Finally, the publisher’s ad server has its own set of tags that get implemented into the site templates, at last delivering the well-journeyed advertisement to its audience.

There’s another piece to the pie that involves ad networks and realtime-bidding demand-side platforms, but let’s leave that to the side for now.

The major players in the first-party ad server world include products like Google’s DART for Publishers, OpenX, Zedo, and 24/7 Real Media’s Open AdStream. The last is the one I’ve worked with the most and one I’m going to use for this article’s example.

So here’s an example of how ads make it onto the page using Open AdStream. We define the site, page, and list of ad units. There’s an optional query variable that we’ll use later. This is an optimized implementation of the ad server’s initial set-up code:

<script>
//Ad set-up for RealMedia OAS ad server
(function() {
var url = 'http://ads.yoursite.com/RealMedia/ads/adstream_mjx.ads/',
  pagetag = 'www.yoursite.com/' + '',
  listpos = 'Top, Bottom, Right1, Right2',
  query = '',
  rns = (Math.random() + "").substring(2, 11);
 document.write('<script src="' + url + pagetag + '/1' + rns + '@' + listpos + '?' + query + '"><\/script>');
})();
</script>

Later in the page, the individual ad units are called in their places with this:

<script>OAS_RICH('Top');</script>
<script>OAS_RICH('Bottom');</script>
...

Responsive-ize it

First let’s mention a few techniques that are not valid solutions. One is always loading the same number of units but hiding certain units for smaller screens. For reporting accuracy and to ensure that advertisers are not being charged for invisible impressions, it’s important that the page only requests ad units that are actually displayed.

Another is user agent sniffing to detect mobile/tablet devices as a way of requesting different ads or modifying layout. On its own, UA-based device detection isn’t necessarily a bad thing but I think most would agree it’s not a natural part of a responsive strategy. Responsive design is the alternative to UA-based device-specific sites. (Although, Luke Wroblewski does make an interesting case for combining the two here.)

Oh, and I should mention that the problem we’re trying to solve concerns ad-based sites running multiple standard IAB ad units: 728×90 leaderboards, 300×250 medium rectangles, etc. That is, a site like Smashing Magazine that combines advertising and a responsive layout is not an example solution to our problem.

Stop resizing your window

I’ll break the bad news to you up front: you have to stop worrying about what happens when people resize their browser. First of all, no one does this. Yes, YOU like to resize your browser and watch DOM elements bend to your will—and so do I—but real-life regular people users don’t. And of course it’s not even possible on mobile and tablet devices.

This whole responsive thing isn’t about passing a CSS fluidity test. So let’s let it go.

The reason this matters is that page views and ad impressions (per unit) are expected to share a 1-to-1 relationship. An advertiser expects to be charged for an impression on a page view event, not a browser resize event. This synchronicity will eventually fade as we move to more AJAX-based content delivery, but for now it’s still firmly in place.

So this technique assumes that ads will be requested once per page load and will be determined by the size of the viewport at the time the page is loaded.

Code: The Set-up

The idea behind this is that we’re going to define a few contexts—mobile, tablet, desktop—and then conditionally serve a set of ads for each context. We start by assigning a list of ad positions and breakpoints based on common device screen sizes:

// Define config
var pageConfig = {
  mobile: {
    positions: ['Top'],
    breakpoint: 480
  },
  tablet: {
    positions: ['Top', 'Right1'],
    breakpoint: 728
  },
  desktop: {
    positions: ['Top', 'Bottom', 'Right1', 'Right2'],
    breakpoint: false
  }
};

We’ll use JavaScript to determine the width of the screen. In the previous responsive ad demos I used matchMedia() but this time I’m going to use document.documentElement.clientWidth.

We’ll pass the width to a function that will evaluate it against our breakpoints and determine a context.

// Function to determine screen context
function setContext(screenWidth) {
  var mobile = pageConfig.mobile.breakpoint,
    tablet = pageConfig.tablet.breakpoint,
    type;
 
  if (screenWidth <= mobile) {
    type = 'mobile';
  } else if (screenWidth > mobile && screenWidth <= tablet) {
    type = 'tablet';
  } else {
    type = 'desktop';
  }
 
  return type;
}
 
// Get screen width
var screenWidth = document.documentElement.clientWidth;
 
// Set screen context
var screenContext = setContext(screenWidth);

Now we can pass what we know to the ad server set-up code. First we turn the list of positions into a string and give that value to the listpos variable. We also set the query value to the context type. This allows us to repurpose the same ad position names for each context.

// Set list of positions
var adPositions = pageConfig[screenContext]['positions'].join(',');
 
// OAS set-up code
(function() {
var url = 'http://ads.yoursite.com/RealMedia/ads/adstream_mjx.ads/',
  pagetag = 'www.yoursite.com/' + '',
  listpos = adPositions,
  query = screenContext,
  rns = (Math.random() + "").substring(2, 11);
 document.write('<script src="' + url + pagetag + '/1' + rns + '@' + listpos + '?' + query + '"><\/script>');
})();

That’s all the code we need to conditionally request ads based on screen size. Note that this code must go in the head and should be executed as soon as possible.

Ad positioning

Now that we’ve requested the right batch of ads we have to position them appropriately on the page. In almost every case I think this can be handled with CSS alone. Unused ad units can be hidden safely with display:none because the unused ad units were never returned from the ad server. And units can be floated or absolutely positioned to accommodate different layouts.

But what if CSS isn’t enough? For example, what if a mobile layout requires an ad unit to be placed somewhere else in the DOM structure? Well we can use JavaScript to move an ad from one location to another. But it comes with an important caveat: JavaScript containing document.write cannot be moved around the DOM. The JavaScript will re-execute when inserted into the DOM and the document.write call will flush the page.

You can only reposition the HTML contents generated by the JavaScript. This requires some cooperation with the code coming from the ad server. If you’re hosting the ad creative (i.e., not using third-party tags) this shouldn’t be a problem. Within the ad server you can wrap the creative in a div and your JavaScript will just grab that div. But if the creative is served via a third-party server you’ll need the same cooperation on the client’s end… which can be difficult. And there may be cases where the ad contents cannot be isolated from its deployment code.

The good news is that mobile creatives are much simpler than Desktop creatives (no Flash) and so if we’re doing this for the mobile context it may not be a problem. Assuming we’ve cleared those hurdles we can proceed as follows.

First, give each ad unit a class and then within your mobile media query block set that class to display:none. This will hide all ads in the mobile context by default.

Second, insert a placeholder div into your HTML wherever you want the mobile unit to appear. Set this to display:none for all contexts.

Next we’ll use JavaScript to move the ad from its original desktop/tablet placement to the mobile-only placeholder div. The previous code was done with plain ‘ole JavaScript but for this I’m going to use jQuery to keep the example from getting too verbose.

$(function() {
 
  // Reference to the new location
  var $newPosition = $('#mobile-ad-placeholder'),
 
    // Reference to the CONTENTS of the original ad placement
    $originalAd = $('#ad-top .ad-contents');
 
  // Move the ad to the placeholder
  $newPosition.append($originalAd).show();
 
  // Remove the original ad from the DOM
  $originalAd.remove();
 
})();

Pretty simple, right?

Wrap-up

Clearly this isn’t a blanket solution for all responsive advertising scenarios; it’s only a possible solution for a particular ad server. And it’s only solving the problem of execution on the front end. But I think it lays the groundwork for approaching the general problem of getting responsive design and advertising to play nicely together.

To review:

• Define a set of contexts and associate each context with a breakpoint and a list of advertising units.
• Using JavaScript, use window.matchMedia or one of the many available properties to detect client screen width and determine the context.
• Modify the request(s) to the ad server to only include the ads needed for the current context.
• The context is determined by the size of the screen at the time of page load. Forget about what happens when the browser is resized. It doesn’t matter.
• If you’re smart about your mark-up structure, repositioning and hiding ads can be handled with CSS. If you must relocate an ad in the DOM it can be done with JavaScript—with the stipulation that you can access the contents of the creative independent of any implementation code that uses document.write.

Thoughts? Ping me on Twitter at @robflaherty, discuss on Hacker News, or leave a comment below.

There are many ways to combine files to reduce HTTP requests–you can use a build tool to prepare static assets as part of a build process or you can combine files on-the-fly using Apache mods, Server Side Includes (SSI), or other server side solutions, including CMS plugins. The right solution of course depends on your project, team, and environment. If a build step is not the right fit for your project and you want to implement something lightweight without having to fiddle with Apache too much, you may find this useful.

I’ll mention that this is a very simple technique and something that developers have been doing for years. I’m simply documenting it so that it has a place in our collective performance toolkit.

all.js.php

To get started we create a PHP file called all.js.php and then:

1. Set the Content-type header to specify either JS or CSS
2. List our scripts/stylesheets in the order we want them included
3. Loop through the array and include each file

The code looks like this:

<?php
header('Content-type: application/javascript');
 
$files = array(
  //Plugins
  dirname(__FILE__) . '/plugins/jquery.hoverIntent.min.js',
  dirname(__FILE__) . '/plugins/jquery.placeholder.min.js',
  dirname(__FILE__) . '/plugins/jquery.tweet.min.js',
 
  //Core scripts
  dirname(__FILE__) . '/core.js',
 
  //Other scripts
  dirname(__FILE__) . '/main.js'
);
 
foreach ($files as $file) {
  include($file);
}
?>

Then you just reference the all.js.php file in your document and it returns all of your JS as a single script.

The obvious advantage of concatenating on-the-fly is that you don’t have to add a build step to your workflow. The benefits of using PHP over server side includes are that (a) it’s likely to be more accessible to developers on your team and (b) you can make use of application variables in your asset list. This is very handy for pulling in shared files (e.g., libraries and plugins) from a centralized location.

Is performance a concern? It depends. If you have an under-provisioned server and you’re trying to concatenate dozens of big files under heavy traffic load, it’s possible you’ll experience some performance degradation. But in most cases I don’t see it being an issue. PHP is fast. Regarding response time, ApacheBench tests I’ve done in the past revealed no significant difference between a pre-concatenated file and one concatenated on-the-fly with PHP.

But here’s the main reason I don’t think performance is an issue: if performance and load are concerns for your site, you’ll already have some layer of caching in place. Maybe it’s memcache, maybe it’s Varnish, maybe it’s a CDN. There’s no reason your concatenated file would be generated with each request — it’s going to end up sitting in a cache anyway.

Cache headers and versioning

When you dynamically combine files you can run into problems with behavior based on the file’s last modified date. For instance if you’re using Server Side Includes, by default Apache does not send the last modified header.

To get around this we can use expires headers to give the combined file an explicit expiration date. Even better, we can use far future expiration dates so that browsers continue to use a cached copy of the file until we make changes. All we have to do is implement some form of file versioning to let clients know when to request a new copy of the file.

There are two parts to it: the PHP in your templates that adds a version number to each CSS and JS file reference, and an Apache rewrite rule that rewrites the versioned the filename to the canonical filename. It’s really simple.

(I’m not going to cover how to set cache control expires headers since it’s well documented elsewhere. If you need a reference, I recommend looking at HTML5Boilerplate’s .htaccess file.)

Adding version numbers to CSS/JS references

Either in your main layout file or wherever in your app you store global config, declare a variable that represents the current version number for your static assets:

$static_version = '1';

Also in your main layout file or wherever you store global functions, add this function that accepts a file path and injects a version number before the file extension:

function version_stamp($url) {
  $name = explode('.', $url);
  $lastext = array_pop($name);
  array_push($name, $static_version, $lastext);
  return implode('.', $name);
}

This will turn all.js.php references into all.js.1.php. The reason the version number is built into the filename as opposed to being append as a query parameter is that some proxies will not cache files containing query strings.

Then we modify our JS and CSS references to include the version stamp function like this:

<script src="<?php echo version_stamp('/_assets/js/all.js.php') ?>"></script>

Adding Apache rewrite

Adding the following rewrite rule to .htaccess or httpd.conf will route requests for all.js.1.php to all.js.php.

# File versioning
RewriteRule ^(.+)\.(js|css).([0-9]+)\.(php)$ $1.$2.$4

Then whenever you make JS or CSS updates you just increment the version number in the $static_version variable and browsers will know to request the fresh copy.

Is this the right solution?

If a build process makes sense for your workflow and if you can integrate a build process without incurring the overhead of something like Ant, I think a build tool is often the better solution. If a build step is inconvenient for your workflow, the various on-the-fly options are probably equal. (I’m sure someone will comment that concatenating with Apache is faster than PHP, and while that may be technically true, practically speaking it may be an over optimization. And as I mentioned above, a proper caching layer renders the argument moot.)

The advantages to this method are that it’s simple, easy to implement, and all done in PHP (aside from the apache rewrite rule).

Lastly, if you’re interested in this stuff make sure to read Robert Nyman’s Tools For Concatenating And Minifying CSS And JavaScript Files In Different Development Environments. It’s a great round-up of tools in a variety of languages and frameworks.

Install watchr, which is a Ruby tool for monitoring directories and files. With watchr and LESS installed you can watch-compile directories and sub-directories with a single command:

watchr -e 'watch(".*\.less$") { |f| system("lessc #{f[0]} > #{f[0]}.css") }'

To make this a little more useful we can call it with a bash script. We’ll also print a status update on each compile. Successful compiles will print the compiled file name and any compile errors will be displayed in the console.

#!/bin/bash
# Requires watchr: https://github.com/mynyml/watchr
watchr -e 'watch(".*\.less$") { |f| system("lessc #{f[0]} > #{f[0]}.css && echo \"#{f[0]} > #{f[0]}.css\" ") }'

Name it something like watch_less.sh, put it in /usr/local/bin/ (or wherever you keep your executables), set permissions with chmod u+x watch_less.sh, and then just run watch_less.sh from your workspace.

Bonus

Here’s another option that uses inotify-tools (note: Linux-only) instead of watchr. This was suggested by @yoavweiss when I asked on Twitter if anyone had a recommended solution for watch-and-compiling LESS from the command line:

LESS watch&compile: while true;do N=`find -name “*.less” `;inotifywait -qe modify $N ;for f in $N;do lessc $f ${f%.*}.css;done;done

— Yoav Weiss (@yoavweiss) January 31, 2012

While I still think the business challenges are the greater obstacle, the technical challenges are interesting and beg for experimentation.  I couldn’t help from spending a few hours toying with possible solutions. Here are two demos.

Responsive HTML ad

My first idea was to build an HTML ad that could shift itself into 3 different standard IAB sizes: 728×90, 300×250, and 300×50. So I designed a mock Foursquare ad with HTML and CSS, using media queries to define break points at 500px and 728px. The two images in the ad are served as data URIs which means the ad has no external resources outside the HTML document. The file size is 36K, comfortably within standard max file sizes for ads.

This works in latest versions of Chrome, Safari, Firefox, and Opera. Maybe/Probably works in IE9. Drag your window around to see it go. You can view the standalone ad here.

Responsive/Adaptive HTML ad using a JavaScript interface

This one is based on the same idea but does two things differently. One, instead of the ads being built with HTML, each ad is simply a static image. And two, instead of embedding the responsive logic in media queries I’ve added a JavaScript interface, the configuration portion of which looks like this:

// Ad config
var ads = {
  leaderboard: {
    width: 728,
    height: 90,
    breakpoint: false,
    url: '728x90.png'
  },
  rectangle: {
    width: 300,
    height: 250,
    breakpoint: 728,
    url: '300x250.png'
  },
  mobile: {
    width: 300,
    height: 50,
    breakpoint: 500 ,
    url: '300x50.png'
  }       
};

This lets you define your responsive campaign with some settings and then the JavaScript does the rest. Note, this uses the window.matchMedia method, which currently is only available in Chrome, Firefox, and Safari (but Paul Irish has a polyfill that can extend support to other browsers).

This works in latest versions of Chrome, Safari, and Firefox. Drag your window around to see it go. You can view the standalone ad here.

Coda

Granted these demos are only static ads and they don’t address some of the bigger problems, like rich media and ad server implementation. But still I think the general technique around building responsive campaigns at the design/HTML/CSS/JavaScript level is not that difficult to execute. The real challenge is defining a common implementation that works for everyone involved — for advertisers, agencies, publishers, and ad servers.

Mark followed up with a great blog post that detailed many of the obstacles and offered ideas about how to move forward. I wanted to respond with a few thoughts.

Quick background on why you might care at all about my opinion on this: I’ve spent the last 5 years working daily and closely on advertising-supported sites, working in a range of areas from product design, to front-end coding, to ad ops, to content strategy, to sales strategy. I’ve debugged tangled 3rd party ad server scripts and I’ve sat on calls with advertisers to try and explain why the “fold” does not exist. Many times.

TV on the Web

Mark talks about the problem that ads are sold as fixed “slots” on a page. For example, an advertiser buys the top leaderboard slot, which has a fixed size of 728×90 and a static placement indicated clearly in the media kit (above the fold, win!). This of course poses a problem for responsive design — what happens to the leaderboard when the screen shrinks below 728px?

What he didn’t mention is that this sales model is mostly inherited from sales models for other media, and, more importantly, that most people buying and selling web have strong backgrounds in buying/selling those other media types.

Whether you’re buying a print, television, or radio ad, you’re buying something of a fixed size or duration with a specific guarantee about placement. It’s a simple, familiar model. Parties on both sides of the sale are comfortable with it. Simplicity is key.

What this means is that sales teams often end up selling other media types (print, especially) on the web instead of selling the web. The mental model is reused, some of the vocabulary overlaps (the “fold”). My point is that it’s tough to move beyond this when so much of the process is still grounded in the past.

Responsive design has a business problem (maybe)

The business case for responsive design is usually centered on a variation of the old “Write Once Publish Everywhere” pitch: instead of building and maintaining multiple sites for multiple devices, we build one site that can adapt to multiple devices. It’s a great solution to a technical problem.

The cost-saving implications are obviously attractive from a business standpoint, but the concept is actually at odds with a higher-level business goal, which is to leverage and extend brands and products into other products.

Desktop, tablet, and mobile experiences have the potential to be marketed as distinct products aimed at different media budgets. But only if the products are somewhat differentiated. Homogenizing into a single unified, adaptable experience — for all its technical and usability benefits — may be undesirable from an inventory perspective. If you’re a salesperson for a print product would you rather be able to offer a client two products or four?

That’s not to say that a responsive design couldn’t be used to produce distinct mobile and tablet offerings. Or that revenue from a combined multi-device package couldn’t offset potential revenue from separate products.

Where things stand today

Mark proposed some great ideas about responsive ad units and multi-unit packages. I’m sure we’ll see these ideas materialize in the marketplace soon but I think Mark (and @kerns) are right that it won’t happen until there’s demand.

So until the market responds to responsive design, what are our options? If your site’s revenue is dependent on advertising you most likely have few if any. Think about it. Your constraint is the width of the widest ad unit. Even if your site only has a 300×250 unit (uncommon), how do you know that you won’t need to support other units in the future?

Say your site has a 728×90 leaderboard and a 300×250 rectangle. Well, you could make a site that’s responsive from 728px (iPad portrait width) up to a 1200px+ widescreen display. Cool. But what if Sales wants to add a 970px-wide Pushdown unit to the site? Now the bottom end of your responsive spectrum is 970px. At that point, is the extra work associated with a responsive layout even worth it?

I’m not aware of any other realistic options. You can’t just hide ads when the screen gets smaller. And ad delivery logic is heavily tied to the server (i.e., it would be difficult, sometimes impossible, to request ads based on client-side properties like screen size).

…but maybe you have some other ideas?

Update 11/17/11: Mark’s article has kicked off a lot of great discussion around this topic. If you’re interested in this topic don’t miss:

• Google+ discussion thread
• André Luís’s blog post
• Nathan Ford’s blog post