RESS (Responsive Web Design + Server Side) explained

By Simon Wissink | 27/03/2014

When building a new website and considering the rising trend of mobile users the basic approach has been to go either with Adaptive Web Design (AWD) or Responsive Web Design (RWD). But there's another emerging option, RESS (Responsive web design + Server Side), and in this blog post I'll explain what it is and how it can help you.

Just to recapture what Responsive Web Design (RWD) and Adaptive Web Design (AWD) are; RWD is when you use a single code base to serve all devices but it adapts the graphical experience and predefined width breakpoints, so it is optimised for a specific device. The AWD approach has a predefined template and media for desktop and another set for mobile.

What is RESS?

RESS is a combination of RWD and AWD (or dynamically serving content). It aims to combine the advantages of both adaptive and responsive at the same time by using server side logic to serve different content dynamically based on the user agent and client side technologies.

Responsive websites maintain a single URL structure; however, adaptive sites usually change the url http://m.something.com or http://something.mobi (meaning 2 sites with 2 x SEO effort). RESS means 1 site for all devices.

Table -02-RESS

Table -03-Mobile Image Fetch

What are the advantages with RESS?

An average webpage is now about 1703 KB (source http://httparchive.org/ March 2014) so over mobile connections a responsive solution might still be quite slow. Large images that are intended for desktop and set to ‘not visible’ on a mobile are still being served because the small screen is still fetching all the content in most browsers (see table below). A responsive site just inspects the width of the viewport not the actual resolution to determine if it’s a phone. It doesn't check the capabilities of the device to see if features like touch or audio are present. Just because you have a width of 640 px doesn’t mean that the interface should be touch-oriented. RESS can help you overcome these difficulties compared to responsive.

 

 

How does RESS work?

A little like this...

 

Table -04-Mobile Detect

A word of warning

If you have a global site that is highly dependent on CDN like Akamai, the use of http-vary will lead to Akamai not caching all the combinations of your content for you. The variation of all combinations of content with browser versions might take too much space. Here is a great explanation: http://www.youtube.com/watch?v=va6qtaiZRHg

But there are other solutions to improve things like dynamic DNS based on location or cloud services. But that’s another story, so let’s take that in a future blog post instead!      

Conclusions

In most cases the responsive approach will continue to be the most common implementation over the next few years, mostly because of budgets. But when load time and the desire for a truly great mobile experience is considered to be equally important we will see more RESS solutions. We will also see a lot more experimenting with RESS in libraries and in CMS in the next couple of years. I think it will be a more incremental transformation when CMS platforms like WordPress, EPiServer and Umbraco start adapting to the RESS idea. A good example of a nice component is the Mobile detect library that is available for many of the popular CMS platforms like WordPress, Magento and Joomla.

Interested in more RESS information: