Breaking Development: The Server Side of Responsive Web Design

by October 21, 2013

In his presentation at Breaking Development in Nashville TN, Dave Olsen talked through how RESS can provide the benefits of both responsive Web design and server-side optimization. Here's my notes from his talk on The Server Side of Responsive Web Design.

  • Why be responsive? It boils down to one: URL, set of content, mark-up, and deployment. It helps us build in a future friendly way.
  • But there is a lot beneath the surface of responsive Web design: CMS, workflow, content, complexity, etc. including server-side optimization techniques.
  • Server-side techniques are often dismissed as just user-agent detection, which has been problematic in the past. So often a clear line between responsive design and server-side optimization is drawn.
  • But it's not as simple as picking between server-side and responsive solutions. There are benefits and drawbacks to both techniques.
  • We can get the benefits of both, as long as we approach server-side development in a future friendly. How do we do that? With RESS.
  • RESS (responsive Web design plus server-side components) combines adaptive layouts with optimized components not full page optimizations and thereby redirects.
  • RESS is a really simple concept with lots of possibilities. You still build in a mobile-first responsive design way as a baseline and use server-side techniques as an enhancement.
  • RESS makes the most sense on teams with a mix of skills (you need some back-end savy), when front-end optimization gets too complex, or when design elements need to be swapped based on known functionality o clear for performance optimizations. RESS can be a bridge for teams comfortable with back-end solutions as the make their way to responsive solutions.
  • The average Web page is 1.5MB and 77% of that comes from images. RESS can help optimize images and many other kinds of assets to not encurr full downloads on mobile and less capable devices.
  • There are robust device detection solutions out there -pay for them. Don't get into free, cheap solutions for user agent detection. That's where things go wrong and your detection systems make mistakes. If you are going down the route of browser detection, pay for a premium service.
  • There's an arms race to keep up with devices and front-end technologies. As new browsers and devices come out, both server-side and client-side detection techniques have to keep up. It's an issue on the client and the server.


  • Server-side techniques include user agent detection, server-side breakpoints, and robust server-side feature detection.
  • Server-side breakpoints: set a file path based on window.innerWidth, then use that variable on the server to render appropriate components and even layouts of pages.
  • Modernizer-style feature detection can be used on the server to create a list of feature variables. These can then be used to render the appropriate mark-up/CSS on the server before sending pages to a client.
  • Server-side feature detection can be used together with client-side detection.
  • You can fetch different content based on breakpoints in the client. The An Event Apart site uses Javascript to fetch mark-up from the server based on screen size in the client.
  • RESS isn't a silver bullet anymore than Responsive Web Design is. Server-side feature detection can be spoofed, but that tends not to happen often. Data needs to be separated strongly from your layout -this has CMS implications but is generally a good thing.
  • Properly set cache headers: make sure CDNs don't cache the wrong assets.
  • Are client-hints the future of RESS? The browser can give a server data that it can act on like window width, bandwidth, and potentially more. This looks like a way to bring more reliable server-side optimization techniques to Web developers in the future.