Dynamic Serving vs. Responsive Web Design
When it comes to adapting Web sites to go mobile for smart phones or tablets, there are two radically different technical solutions. Neither one is inherently superior to the other; they both have advantages and disadvantages. The nature of your Web project should guide your choice. The buzz over the last years has been all about responsive design, leaving dynamic serving far behind; but this solution is a significant asset in some situations.
Responsive Web Design
In this solution, the Web server sends the same HTML and CSS files to all clients, regardless of whether the client is a desktop, tablet, or smartphone. Visual presentation is tailored to smaller screens by a special module, Media Queries, released with CSS3. The general principle is to override CSS declarations dedicated to the display on a large screen when the width of the screen is less than a certain number of pixels (threshold called “breakpoint”). Under the breakpoint, visual elements can be resized, modified or even hided if they are deemed unnecessary on smaller screens.
Dynamic Serving
In this situation, the server looks for the User Agent value in the HTTP header to determine whether it is dealing with a desktop, tablet, or smartphone. The server then sends out different HTML, CSS and JS code and media files (images, video, etc.) depending on the User Agent value. This means that mobile and desktop users receive different content from the same URL, unlike in the Responsive Web Design solution.
Advantages of Dynamic Serving
Superior Performance
Under Dynamic Serving, the mobile version of a Web site isn’t merely an adaptation of the full-fledged site, since the dynamic serving solution only sends out the necessary code and optimized media files. This way, the handheld device doesn’t receive megabytes of useless HTML-CSS code. Performance optimisation (as in weight and speed) becomes extremely easy and efficient. This is the biggest advantage of this solution, and it can be a sizeable one in some contexts, such as e-commerce, where reactivity is crucial to conversion.
Not Robbing Peter to Pay Paul
Responsive Web Design is an either-or solution: either you program for mobile devices then tailor to desktops, or you do the opposite. Whichever way you go, the second-place display type will be a compromise solution. When you look at a Web site designed for mobiles on a 5K screen, you immediately notice a step down in graphics and ergonomics. Conversely, so many Web sites are so poorly tailored for mobile devices that the desktop version would probably perform better! Dynamic Serving is a solution that does away with the need to compromise between versions.
Optimized Interaction
If your Web site is heavy on transactions and complex interactions, such as forms, you can design radically different user experiences depending on the platform. While this optimization isn’t relevant for content-based sites such as blogs or magazines, for on-line sales, it is a major draw. With Dynamic Serving, you can create a unique experience that will feel more like an application for your mobile users.
The Best of Both Worlds
Dynamic Serving and Responsive Web Design are not mutually exclusive. In fact, using media queries is recommended under Dynamic Serving in order to tailor visuals to the various sizes and orientations of mobile screens (phones, tablets).
Downsides
Cost
The more different the two versions are, the higher the maintenance costs will be. And if you’ve maxed out your optimization, you’ll basically have two different sites to maintain. Furthermore, the technical prerequisites are more cumbersome than in Responsive Web Design, which of course carries a cost of its own.
Failed Detection
User Agent detection is dependent on maintaining a dictionary of potential User Agents on the server. This list must always be up-to-date, under pain of non-detection of new agents. And since detection errors are always a possibility in any case, it’s a good idea to allow the user to switch to a different version than the one detected.
What About Google?
Google, the ultimate arbiter of taste, prefers Responsive Web Design. And looking down on us mortals from Mountain View, it has not felt the need to justify its preference, as is its wont. We are supposed to bow down and accept the pronouncement without question. But we dare hypothesize that Google fears cloaking techniques based on agent detection, and frauds are so much easier to detect on Responsive Web Design sites.
That said, will Google somehow penalize you for choosing this solution? The answer is no, as long as you observe one simple rule: use a valid “Vary” HTTP header to signal that you’re tailoring the content to the User Agent (Vary: User-Agent).
You don’t want Google on your back… so don’t forget:
GET /page-1 HTTP/1.1
Host: www.example.com
(...etc...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 6785
(...etc...)
To reassure you, John Mueller vouched a few years ago for Google’s search-engine neutrality (at 13:05):
“So, if you use responsive or dynamic serving or separate mobile URLs, it is essentially up to you. It is something that you can also mix, where you say: ‘well, part of my website is fully responsive, and part of it just sniffing user agent to make sure that we can like serve them properly.’ From my point of view, I just really make sure that everything works on mobile as well.”
John Mueller then added that it’s really a question of usability rather than SEO.
The “Vary” HTTP header has another advantage: is stops the cache system of some ISPs from sending mobile users a pre-cached desktop version.
A Word on Separate URLs
One solution akin to Dynamic Serving is to perform detection but to serve the various platforms from separate URLs, for example “www.example.com” and “m.example.com”. This solution has little or no advantages, in my view, while presenting its share of challenges if it isn’t perfectly implemented. Say, for example, that your desktop has been sent a link from a mobile and you find yourself prisoner to the m.example.com version on your large screen. No problem, you’ll just manually correct the URL – until you discover, to your absolute frustration, that www.example.com keeps redirecting you to m.example.com due to a stupid cookie. I bet this has already happened to you.
If you do choose to use separate URLs, don’t forget to indicate the bidirectional relationship between the two with a “link” tag and the rel="canonical" and rel="alternate" annotations. This can be done in the header or in the sitemap. Don’t forget to issue a HTTP 302 code for redirecting. As long as you observe these rules, you should get along fine with Googlebot.
In any case, you should avoid client-side detection, since it involves some measure of latency, while the JavaScript code requires some time to load and execute.
What to Choose?
It all depends on your budget and your site. If you’re on a tight budget and your site is simple and light, requiring little interaction, then Responsive Web Design is the way to go. For anything else, you should consider Dynamic Serving.
But you should also think of the type of clients who use your site: if they are mostly mobile, you may want to go for Dynamic Serving, no matter what kind of site you have.
