Improving Responsive Web Design With RESS

This post was sponsored by Netbiscuits. Thank you for supporting the sponsors who make SitePoint possible! On average, more than one in three visitors to your website is using a mobile device. In the past year alone, mobile usage has increased by more than 20%. So how do we cater for this market?

Separate Mobile Websites

If your time, budget and sanity aren’t important, you can build separate sites for mobile and desktop users. Content can be repackaged and streamlined for the device. Unfortunately…

1. The days of either desktop or mobile are long gone. There is a huge variety of devices with differing screen sizes, pixel densities, processing speeds, network capabilities and HTML5 features. And few of us have even considered wearables yet! Brands would need to create numerous sites to cater for every eventuality?
2. Identifying the user’s device is difficult. User-agent strings are notoriously tricky to parse and won’t tell you anything about the screen dimensions, network speed or other features.
3. You normally require separate URLs for each site, e.g. www.site.com and m.site.com. Users can end up on the wrong site for their device and, if you’re not careful, search engines will penalize you for duplicate content.
4. Managing one website is tough. You now need to build and deploy several sites and ensure they’re updated concurrently. Perhaps your developers will survive the ordeal but will content editors cope with multiple assets which target different views?

That said, separate sites remains an attractive option for companies such as Amazon and eBay since it offers a targeted experience.

Responsive Web Design

Alternatively, designers and developers can use designs which respond to the browser’s viewport dimensions (typically, the whole screen on smaller devices). Using a mobile-first approach, the site implements a default linear layout perhaps with smaller text and menus accessed from hamburger icons. As the dimensions increase, the design can be re-flowed to show additional columns, larger fonts, more spacing, always-visible menus etc. RWD solves many issues encountered with separate views. We have a single site with one set of content which can respond to an infinite variety of screen sizes. Unfortunately…

1. Screen size is a crude indication of the device’s capabilities and tells us nothing about the processor speed, network bandwidth or level of HTML5 support. A user with a large monitor could still be using a twenty year-old PC on a dial-up connection.
2. The same page and assets are (mostly) delivered to all devices. It’s possible to limit image loading using CSS background images within media queries, the <picture> element and srcset attribute but support remains patchy and it doesn’t solve every problem. Client-side adaption techniques can slow down page rendering too, and this needs to be addressed. For example, a large image could be delivered to a high-density Retina screen even though the user is on a slow connection.
3. Some options are not easy to implement on the client alone. It’s difficult to re-factor content, e.g. split a long article over several pages. All devices receive the same page even if it’s impractical to read on a small screen.
4. The average web page exceeds 2MB. Many use a Responsive Web Design but it doesn’t follow that the site is responsive on a low-powered device. Creating a fast, responsive website has become more imperative now Google rate sites based on performance.

So separate websites is difficult and responsive designs cannot solve all the problems. Is there are third way we could consider?

RESS: Responsive Web Design + Server-Side Components

RESS was proposed by Luke Wroblewski in 2011. The concept uses Responsive Web Design but supplements it with feature detection to serve modified content when required. For example, you could:

• Serve smaller images on smaller screens or when bandwidth is limited.
• Only serve a video element when the device has HTML5 support on a fast connection.
• Avoid serving Flash games or adverts on iOS and increasingly Android devices.
• Switch to grayscale images on eBook readers.
• Reduce the frequency of Ajax poll requests on slower connections.
• Remove unnecessary CSS3 effects when the device does not support animations.
• Fall-back to PNG images when SVG is not available.
• Provide additional information when the user is in a specific location or country.

RESS never became a widely-used technique because feature detection is difficult — especially on the server. Your detection code must be verified, updated and maintained every time a new browser or feature is released. Fortunately, there are third-party services such as Netbiscuits which do the hard work for you and are constantly updated with the latest device information. The first step: sign-up for a Netbiscuits account — there is a 30-day free trial to assess the service. Paste the Netbiscuits tracking code into your website template, wait a few seconds, and view the attractive device and visitor flow analytics charts:

Client-Side Device Detection API

The tracking code also defines a global JavaScript object named dcs which exposes more than 650 hardware, browser, operating system and network detection parameters. Examples: Assess the bandwidth score — a rank from zero (very slow) to 20 (typically EDGE/HSPA) to 60 (3G) to 120+ (4G/wifi):

var bandwidthScore = dcs.get('bandwidth.score'); // integer

Identify whether the device has a touch screen:

var touchScreen = dcs.get('browser.cantouch'); // boolean

with a high-density pixel ratio:

var pixelRatio = dcs.get('internal.browserpixelratio'); // real

Does the device have telephone calling facilities?

var canCall = dcs.get('browser.cantelmakecall'); // boolean

Is SVG supported? Are SMIL animations available?

var svg = dcs.get('browser.css.cansvg'); // boolean
var svgSmil = dcs.get('browser.css.cansvgsmil'); // boolean

Find out where the user is located:

var county = dcs.get('internal.countrycode'); // 2-character string, e.g. "US"

Suggest a compatible HTML5 video format:

var videoFormat = dcs.get('video.suggestvideoformat'); // object

Detect which browser is being used:

var browser = dcs.get('browser.model'); // string, e.g. "Firefox 38"

and whether it’s the latest release:

var latest = dcs.get('browser.islatestrelease'); // boolean

Server-Side Device Detection API

Device detection is most useful on the server where you can modify the response before it’s sent. Code is provided for PHP, Java and .NET. PHP examples… Does the device support H264 HTML5 video and has a reasonable connection?

<?php
if ($dcs->video->canhh264 && $dcs->internal->bandwidthscore > 150) {
	echo '<video src="video.mp4" controls></video>';
}
?>

Does the device support Ajax and have JavaScript performance better than the iPhone 5 (a reference device with a score of 100)?

<?php
if ($dcs->browser->canajax && $dcs->hardware->performance->js > 100) {
	echo '<script src="moderndevice.js"></script>';
}
?>

We may never have a solution which is easy to develop and works perfectly on all devices but RESS offers a good compromise which solves many of the performance problems encountered with Responsive Web Design. A good device detection service is all you need.

Frequently Asked Questions on Improving Responsive Web Design with RESS