Much has been written recently about Adaptive Web Design (AWD) vs. Responsive Web Design (RWD), with pros and cons of both being highlighted.
For those new to these methodologies, here is a short summary of both approaches:
|Adaptive Web Design||Responsive Web Design|
|Server or Client-side to detect the device||CSS ‘media queries’ to detect the device|
|Serves separate HTML, using CSS to modify the page based on screen size||‘Fluid CSS Grids’ are resized to fit the device screen|
|Site content is pre-selected and mobile optimized assets are downloaded||All assets are downloaded whether they are required or not|
|Multiple templates for each device||Single template|
|Images are optimized for device resolutions||Images are resized to fit the device|
With all of the above in mind, we decided to undertake a little experiment to see how well both performed when monitored from a mobile device profile. The sites were monitored from four backbone locations in New York and another four in San Francisco.
Testing, testing, one, two…
In order to give both approaches a level playing field, we built two identical sites using the popular CMS, WordPress. Both sites had the same dummy content loaded, including images and text. At this initial point of the experiment, no additional optimization was done to either site and all the default settings were used.
WordPress comes with a RWD based template called ‘TwentyFourteen’ as standard. This template gives a magazine-style layout to your site and is highly configurable. An online demonstration of this template can be found here.
When visiting this demonstration site, resize your browser window and see how the site adapts to the resolution changes using the CSS ‘media queries.’
If you are using Chrome or Safari you can switch to mobile device emulation. In Chrome, go to Tools -> Developer Tools -> Emulation and select a device.
In Safari, enable the Develop menu in Preferences and then go to Develop -> User Agent and select a device.
In order to implement the AWD approach, we used a WordPress Plugin called WiziApp. The plugin serves up a mobile theme to users that access the site from mobile devices, and also offers advanced configuration options to further streamline the mobile experience.
By using the AWD approach, you can assign more control over how the page is loaded. With the WiziApp Plugin, it will not load all the posts on the homepage we are monitoring. Instead, it implements a ‘Show more’ option at the bottom of the device screen. This prevents the loading of all the homepage content upfront. Implementing a ‘load on scroll’ would also have worked nicely.
Round One: Default, Unoptimized Sites
It will come as no surprise that both sites performed identically from a desktop perspective, as both used the default WordPress template. But as soon as you switch to a mobile device or tablet, the difference is crystal clear. Again, please note that at this stage no additional optimization has been done and defaults are being used.
|Response||568 ms||1,202 ms|
|Document Complete||1,536 ms||4,086 ms|
|Webpage Response||2,889 ms||4,860 ms|
|Bytes Downloaded||2,474,326 kb||4,229,362 kb|
The clear winner here on all accounts is AWD. The AWD template is quicker, downloading less data bytes and fewer objects, while the RWD template is downloading everything that a desktop user would receive. If you were out and about using a 3G/4G connection, that is a lot of megabytes and would lead to a very painful and slow online experience.
Put Your Images on a Diet
The initial dummy data that was used to populate the site was very image heavy and the images had not been optimized for either desktop or mobile use. A quick install of the WP Smush.it Plugin allowed for a Bulk Smush.it of the images used. Also, the Imsanity Plugin was used to bulk resize the images from their original imported sizes. These steps were replicated across both of the sites. So what is the experience for our mobile users now?
|Metric (Image Optimization)||Adaptive||Responsive|
|Response||554 ms (-2.46%)||1,151 ms (-4.24%)|
|Document Complete||1,462 ms (-4.82%)||2,853 ms (-30.18%)|
|Webpage Response||1,801 ms (-37.66%)||4,251 ms (-12.53%)|
|Bytes Downloaded||514,144 kb (-79.22%)||1,504,168 kb (-64.44%)|
|Objects Downloaded||20 (0%)||61 (0%)|
The optimized images clearly had a significant effect on both formats, particularly in the amount of data that was downloaded. But once again, AWD comes out as the clear winner, with a document complete that is nearly twice as fast and an even greater disparity in the amount of bytes downloaded than we saw with the un-optimized images.
Squeezing the Juice
|Response||463 ms (-18.49%)||1,136 ms (-5.49%)|
|Document Complete||1,041 ms (-32.23%)||2,004 ms (-50.95%)|
|Webpage Response||1,098 ms (-61.99%)||3,562 ms (-26.71%)|
|Bytes Downloaded||460,950 kb (-81.37%)||1,498,634 kb (-64.57%)|
|Objects Downloaded||15 (-25%)||52 (-14.75%)|
Once again, the Adaptive template remains significantly faster and more efficient than its Responsive counterpart. It’s still nearly twice as fast with regard to the document complete, and the gaps in the amount of data and number of objects being downloaded are even greater with the additional optimization.
Sure, there are many more optimization techniques we could have employed, but even optimizing both sites identically, the experiment shows that Responsive never even came close to catching up with Adaptive, although it saw massive gains itself in document complete and page weight.
At the end of the day, it’s all about customer satisfaction, and by giving your customers the site that they need for their respective devices, the happier they will be. If you go to a restaurant and you are a vegetarian you don’t want to be offered filet mignon. It’s the same with your mobile users; give them what they asked for – an optimized mobile experience.
While Adaptive will be more difficult to implement, it will be better for your end users. You will retain their stickiness and loyalty, and help them to not walk into lamp posts while they look at their device screen waiting for your content to load.