• http://www.barryadams.co.uk/ Barry Adams

    You haven’t explained why RESS is better for SEO than RWD. I grant you there may be some UI/UX advantages when you can serve device-specific content with RESS that you can’t with RWD, but that does not indicate a SEO advantage.

  • http://www.brysonmeunier.com/ Bryson Meunier

    RESS is RWD, but with server side components, so the advantages for SEO are small. Nonetheless, I don’t agree that device-specific content doesn’t indicate an SEO advantage when done correctly. If marketers can engage more people with their content, links and shares and organic traffic can’t be far behind. It’s a principle so basic that Google has mentioned it in its SEO Starter Guide: “Creating compelling and useful content will likely influence your website more than any of the other factors discussed here.” RESS by itself has no inherent advantage for SEO, but it gives you more options for contextually aware, compelling and useful content that does.

    Thanks for the comment, Barry. Good to see you outside of State of Digital.

  • http://www.mrryanconnors.com/ Ryan Connors

    Interesting to read the differences between RESS and RWD. I’m glad that these discussions are coming to the front as businesses understand the value of an optimized website experience across mediums and even get into customization based on user personas. Thanks for sharing Bryson.

  • http://www.mobilemartin.com/ Michael Martin

    Barry,

    As I like to say, RWD is just changing the deck chairs of the ship while Dynamic Serving allows you to actually steer your site through icebergs of intent, since you can actually adjust the HTML. RWD is the same HTML that just adjusts its visual presentation via CSS while Dynamic Serving provides different HTML under the same URL based on the device, which means for SEO…different Title Tag & Metas plus content specific to the device intent.

  • Markus

    You say “Adaptive Web design: When a user requests content from a server, it detects the device that they’re on and serves them separate HTML that is designed specifically for that platform or device.” And as an example for this you mention http://www.screamingfrog.co.uk/. But there is no server side detection of the device. http://www.screamingfrog.co.uk/ always sends the same HTML and CSS to the device. Media Queries then manage the appearance of the webpage.

  • http://www.referralcandy.com/ Zach @ ReferralCandy

    The only term I was familiar with (prior to reading this article) was responsive web design, and I took it to mean any design that suited the website’s contents to the device viewing it. So I found the notion of adaptive web design and RESS and how those two are different from RWD very interesting. Thanks for the insight.

    Here’s what I understand now:

    RWD = Send the same HTML/CSS for all devices, CSS alters look based on media queries
    RESS = Send slightly different (only alterations, not a full redesign) HTML/CSS depending on the device, CSS alters look based on media queries as well.
    AWD = Send totally different HTML/CSS to suit device (typically fully designed for the specific user agent)

    Correct me if I’m wrong, but it seems to me that RWD is the cheapest to implement (from a technical perspective – only one codebase to maintain) and also the best for SEO (from Google’s perspective). So I’d go with that if the mobile experience for the website does not need an entirely customised experience.

    So I’m curious to find out whether other websites find it worthwhile to do RESS or AWD and why? What kind of websites do they tend to be?

  • http://www.brysonmeunier.com/ Bryson Meunier

    Good point, Markus. Device detection is frequently used for adaptive web design but the key distinction is fixed break points vs fluid grids. Screaming Frog’s site is considered adaptive because it uses fixed break points instead of fluid grids. So server side detection isn’t an essential component of adaptive web design, but it is frequently used. Thanks for pointing that out.

  • http://www.brysonmeunier.com/ Bryson Meunier

    Glad you liked the article. As for cost, RWD is typically much more expensive upfront than the alternatives. This is part of the reason so many web designers love it. If there’s cost savings because of efficiency you won’t see a return for a while. Also, RWD is only preferred by Google for SEO if it’s best for the user. If it’s not user-friendly they don’t recommend it. That said, from an SEO perspective it does make sense to go with responsive web design over these alternatives if you can make it work well for your users and your business.

  • Andreas Mitschke

    That’s plain wrong.

    First of all, web designers are not web developers and from a professional pov, they shouldn’t be neither. However, most designers also qualify for some front-end development, but they stiLl shouldn’t do that. Same for UX architects, don’t throw all these prowess in a single profession, namely web designers.

    Then, a responsive framework is way more cost-effective than serving multiple ressources based upon true adaptive intentions.

    Not just for the creation part, but also when it comes to serving and maintaining different versions of the same content. Imagine, you’ve to provide different types of the same image file, different back-end files e.g. wordpress you’ll need to maintain multiple php files, css files, probably different js files… a responsive framework won’t end up in a huge pile of files instead it’s just about css hide-methods and queries.

    …and Screaming Frog is NOT an adaptive page. It’s using cluttered media queries without a grid, but they do not exchange any data.

    A last word, which should be read by everyone reading this article:

    The actual best method to simoultaneously boost mobile speed, but without a bulk of coding, is to use a responsive grid including an adaptive image solution.

    The biggest problem with responsive designs is that each agent gets served the same data, reconstructed and in case of images just resized, which implies a certain bandwidth load. Mobile devices are meant to used on the go, thus Google wants us to make the mobile experience as fast as possible, which is not working-out when you serve a 600x600px picture just resized to X, where X is different depending on the browser-window-width.

    A server-side pre-render solution like http://adaptive-images.com/ solves this problem.

    Pros for responsiveness+adaptive images:

    - easy to implement
    ( simple CSS queries, almost entirely cross-browser proof )
    - easy to change
    ( one or few files,which entirely let you control the whole appearance )
    - easy on bandwidth, thus faster page speed
    (each 1s of load time = +10% bounce rate)

    Cons:

    - needs maintainance of additional image files
    ( for some solutions (not mentioned php solution )
    - clutters the HTML with additional Tags depending on Agent
    - Media Queries will never perfectly serve “every” mobile and tablet out there, as you need to generalize all those fragmented devices by screen width.

    The best solution, regarding UX PoV, is still the native mobile App.

    Regarding SEO, it’s clear that serving different kind of architecture is not the way to go. I even bet 90% of SEO guys will fail in telling google to crawl the different file sets.

    Either you make it really complicated and go with the App path, which means no SEO impact at all

    or

    take the best-practice and easiest way and go with responsive design and added adaptive images… which might qualify for that stupid RESS term.

  • http://www.brysonmeunier.com/ Bryson Meunier

    Thanks for the comments Andreas. A lot to address here, but not much that mentions SEO. SEO first: You say “it’s clear that serving different kind of architecture is not the way to go” but I don’t know many SEOs at this point who agree with you. Far from clear, at the very least it’s a point of contention with many SEOs like myself and Michael Martin recommending to serve different content based on smartphone and desktop user agents when it makes sense for the search engine user.

    If making a distinction between front end developers, web designers and UX architects was necessary for this discussion I would have done it. However, it’s not. When I mention web design as a profession when it comes to selling RWD it’s only because many web designers are eager to sell the new service. Part of the motivation is to make the web more usable on different kinds of devices, but part of it is financial.

    Screaming Frog was mentioned as an example of adaptive web design by the number one result in Google for [adaptive web design], Techrepublic: http://www.techrepublic.com/blog/web-designer/what-is-the-difference-between-responsive-vs-adaptive-web-design/ If I’m confused, web designers (and I suppose sometimes UX architects and front end developers) are not helping by sharing bad information on authoritative sites.

    Clearly I didn’t invent the term RESS since I linked to Luke W.’s blog where he lists examples of it. If you have a problem with the terminology please take it up with him.

    Adaptive images is only part of the problem with speed and RWD, but that wasn’t part of my article so I’m not sure why you brought it up. You do need to keep in mind, though, that once you alter Google’s definition of responsive web design by adding something like adaptive images you can no longer claim that Google recommends it.

    When you mention cost effectiveness are you taking into account loss of traffic resulting from not being visible for mobile specific keywords or user frustration at an information architecture that’s not designed for them? Most people don’t, unfortunately.

    An ideal UX solution as you mention might be the native app, but this is an article about SEO and as you say the SEO benefits of native apps are nil.

    Clearly we’re not on the same page here, but I appreciate your comments.

  • Peter Hatherley

    I agree compelling thematic content is where you should be spending your energy. Yet many sites do not cover the smartphone field well. Sure, Google does take ease of visibility into account and more specifically well designed information modelling. But Rich Thematic Content (RTC) that utilises a responsive template has a far, far better chance of succeeding than with one that hasn’t .. as for the splitting of hairs on either or, I’m not so sure if it would make much difference!

  • http://instalogic.com/ Instalogic Web Design

    That was well explained and really added a lot to the discussion of adaptive web design.

    Calgary Web Developers

  • http://www.incion.com/ web design company los angeles

    Interesting to read the differences between RESS and RWD. I’m glad that
    these discussions are coming to the front as businesses understand the
    value of an optimized website experience across mediums and even get
    into customization based on user personas.

  • http://instalogic.com/ Instalogic Web Design

    Thank you so much for posting this.

  • Julian Cassin

    It seems some people are narrowing their definitions of RWD or AWD too narrow.

    Google’s own website for example is both RWD and AWD – it is responsive to device rotations in its most basic form, keeping the content centered but also adapts to the device’s browser capabilities ie: turns on voice recognition where supported.

    RWD is usually controlled via media tags if you do choose to use fluid style grids, but doesn’t really have to be. Just because your web-based CLI (Command Line Interface) has a single cell and responds to device rotation dynamically doesn’t make it not responsive – it might want to change the number of horizontally and vertically available characters or re-arrange the menu system.

    Nor are RWD and AWD mutually exclusive. In addition to being able to mix them, they don’t have to be entirely client or server driven. An example is here http://www.youtube.com/webrenovators which shows an AWD entirely client-side (same HTML/CSS sent to devices whether a mobile device or a desktop). There is a server, but it has no impact on the client what-so-ever. The client adapts in multiple ways, multiple monitor support, direct to printer support, multi-tasking ability, screen resolution, voice recognition to name a few. Having researched the topic thoroughly in order to come up with the optimal performing solution for our requirements, ensuring maximum cache hits are achieved (as an example), or minimal server-communication is required – it was found that client-side was the way to go. To load the entire website having previously visited gets 100% cache hits with the exception of the bootstrapper – typically less than 23kb which includes it’s first package of server-side data.

    AWD is definely more powerful, RESS is interesting but why limit it to server-side components? That limitation makes no sense. For SEO, you can always have a dedicated SEO behaviour that is completely separate to the clients – afterall, a search engine is also just a client.

    It will be interesting to see in 5 years time whether web developers generally still opt for one or the other.