Is Responsive Design Bad for SEO?: Part 2

posted by Development

During the past couple days, an article has been circling around the thunder::tech office. This article, When Responsive Web Design is Bad for SEO by Bryson Meunier, has also caused a lot of discussion in the Web community. Here is the second installment of our response to the author’s final three points as to why people should favor optimization practices over responsive design. Read the first installment here.

3.) "When Responsive Layout Increases Load Time Significantly," stop everything and re-examine the entire site.

You'll find that the wrong stakeholders are making the wrong decisions for the wrong reasons. The amount of code to add responsive capabilities to a site is nominal at worst, but more often miniscule. A well-made responsive site can be a tiny fraction of the size of a somewhat-well-made mobile-only or desktop-only site with the same features.

The real culprits in load time bloat are:

  • The "need" to have aesthetic consistency across browsers. Drop the images of your aesthetics and use CSS's built-in commands. The users who won't see your visual details don't actually care about them - they'd much rather the site load quickly.
  • The "need" to include content that nobody cares about and features that nobody will use. This entertaining XKCD panel makes our point quite elegantly.
  • Tying the site to slow third-party services, which have their own implementation problems. Connecting to many advertising networks, many tracking services and pulling in many different feeds from outside sources to have a plethora of peripheral content does way more load-time damage than even a poorly-implemented responsive design.
  • A poor development process, inadequate planning or failure to determine the site's purpose are often the worst reasons. Are other parties editing the code? If a site uses prototype, and the new developers are only comfortable in jQuery, are they including jQuery (or vise versa) just to add one feature? If a site uses ASP.NET, and the new developer is only comfortable in PHP (or, again, vise versa), are they fragmenting the serving platform needlessly just to make it developable for themselves?
To prove our point, consider that the code making a site responsive goes in its stylesheet. A popular website known for its fast load times and visual simplicity has a stylesheet just more than 100 kilobytes. A fully-functional responsive site we're working on has fewer than 35 and is complex and full of aesthetic features.

After the article, Meunier replied to a commenter on this post:
    "I agree that responsive sites don't have to be slow, but agree with Akamai evangelist Guy Podjarny that most of them are."
The old attitudes about websites that cause them to become slow, CPU-cycle-heavy implementation disasters hit responsive sites even harder than non-responsive sites because they slow down every process and every detail. This is why a progressive enhancement approach is so critical.

4.) "When Target Audience Primarily Use Feature Phones" for Web access, you should have a separate version of your site that caters to them.

But should you make a desktop site and a mobile site, or a responsive site and a feature-phone-specific site? At first, one might think "Two sites that are optimized for mobile? That's outrageous!" However, consider that:
  • Smartphones are closer to feature phones to peoples' perceptions, but in terms of capabilities, smartphones are closer to desktop computers. Building a site for smartphones and feature phones seriously reduces what you can do for the smartphone.
  • Tablets are even closer to desktop computers. In fact, there are now hybrids between notebooks and tablets. They're mobile, but they're essentially desktop computers.
  • A separate "feature phone" site is about catering to a lack of capabilities in the device, nothing more. It would be most effective if it was as unambitious as possible, such that it could target as many devices as possible, minimizing load times and maximizing the number of feature phones capable of receiving it.
At that point, we still wouldn't make assumptions about the user's goals based on their device. We'd simplify the navigation process as much as possible.

Responsive design isn't actually about targeting specific devices, it's about making a site that's device-agnostic; it makes sense to include as many sites. In a few years, responsive sites may be catering to Google Glass, watches, televisions and video walls.
    "So, if you’re developing for an audience that uses feature phones (i.e., non-white, non-US-based, not affluent, and/or older), responsive Web design is not the best option for SEO."
Many non-affluent people have begun to purchase phones instead of computers. For them, the ability to access all content in a way that's optimized for their platform is more critical than an affluent person with multiple devices and the same goals.

5.) "When It Prevents Product Innovation That Improves The User Experience", one of two cases can be almost always be found: either the medium is wrong or progressive enhancement should be used.

How to tell which one is simple: Would the project's functionality be completely useless without the device capability?
  • If so, the correct medium is an application.
  • If not, proceed with progressive enhancement, and hide the functionality where not available.

  • "Take banking, for example. JP Morgan Chase could have reformatted their desktop website for mobile visitors and called it a day. Instead they thought about the specific properties of mobile devices that they could use to make their customers’ lives easier. And for them it meant creating a separate mobile website, allowing for SMS banking, and creating a mobile app.

    The mobile app has a feature called Quick Deposit which uses the device’s camera to allow users to take pictures of checks for deposit. It’s mobile-specific content, as it’s only available on tablet and smartphone, and it has been a huge success for Chase."
There's no reason that the same information couldn't be presented on the desktop site, in the same way, minus the buttons to activate them. Many people own more than one device and learning about these services on a computer could cause users to seek them out via their phones. Even better, a notice on desktop site that "Your computer does not support this feature - visit this page on a mobile phone to begin!" will let users know immediately how they can proceed.
    "Or, take Google, for example. Their stated preference in responsive Web design hasn’t stopped them from making mobile-only content. One of these features is called Google Now."
Google Now is an application, not a website. Application is the correct medium for that service.
    "If creating a responsive site with mobile landing pages it not an option..."
The entire revised decision tree is based on this premise. We can think of no practical reason that the best, clearest, most practical approach to the concern - which when employed is really not even a concern - would not be an option.

Responsive design is not the issue, but rather misguided priorities, resistance to best practices and thoughtless implementations.

About the t::t UX team
thunder::tech's User Experience team ensures that projects are devised with careful consideration to the end users' goals, ensuring usability and advocating for courtesy towards the user above project goals that may make projects less usable. Among its responsibilities are making recommendations on mediums, planning, organizing both informationally and spatially, and front-end development for Web and other interactive projects.

POSTED IN: Web


Related Posts

2013 Department Recap: Account ServicesWe dare you not to smile at our April wallpaperMobile Commerce: The New Shopping Majority2013 Department Recap: Creative
2013 Department Recap: Account ServicesWe dare you not to smile at our April wallpaperMobile Commerce: The New Shopping Majority2013 Department Recap: Creative

3 Comment(s)


Bryson Meunier said: 

Thanks again for your feedback. Happy to respond as I did to part 1, and I thank you for keeping the feedback constructive, as this has been rare in the larger discussion so far. 3) This actually sounds like you agree with me that responsive web sites can be slow, so I’m not sure what you’re objecting to here. All of these are solutions to the problem, but so is building out a mobile site on a dedicated URL. I also noted in the article that responsive sites can be fast if done correctly, so I’m not sure why so many people are objecting to this point. In cases where responsive sites are slow, they can be bad for SEO. Same applies to dedicated URLs, but as the Akamai evangelist said, responsive sites are harder to make fast. 4) This is a novel approach, but I’m still not sure that it would solve the problem. As I outlined in my comments to the first part of your rebuttal, there are still issues with adaptive content that make for a poor user experience. Plus, I’m not sure responsive design advocates would respond well to this, as one of the key selling points is not having to maintain more than one site. So essentially you’re suggesting that they double their work by making their current site responsive and building and maintaining a separate feature phone site. I agree it would be better for the users (though not really best), but it’s going to be a hard sell to those for whom responsive design is the best option because of efficiency. I’m not philosophically opposed to Oneweb, and I think it’s good that content that should be device-agnostic is device-agnostic. But as I said in the comments of part one of this rebuttal, there are instances when mobile-specific content provides a better user experience than adaptive content. We can’t just pretend those instances don’t exist because we would rather not do the work. There are solutions like Moovweb now that allow you to build your site starting with the desktop content and functionality, and revising it as appropriate to provide the best user experience for the platform. This is a better solution than making all content device agnostic and hoping the user experience isn’t affected. Very often, for certain businesses, it will be. Also, as I said in the comments of my original post, I actually got the demographic wrong on that. It’s actually older Caucasians in the US who you would have a difficult time reaching if you only made your site responsive. It doesn’t negate the fact that certain demographics will have no use for responsive web design today. And I completely agree that those non-affluent users who use phones as their primary internet access point should have a good user experience, including those in emerging markets like India who primarily use feature phones to access the web. Not sure why this was included in the rebuttal, as I’ve stated as much in the piece. It seems it was more about Oneweb, which as I said I’m not objecting to. 5) And this is the difference between user experience and SEO. You want businesses to develop a native application where very few people will see it or get to experience it. I want to make it available on the Web where it has 100% reach. And why not? Though it’s not perfect, HTML5 can do a lot of the things that previously only native apps could do—like access the camera, accelerometer, GPS, audio, etc. Why should these experiences that go beyond Oneweb be limited to native apps, where they will automatically have limited reach? Better for the majority of users to make the functionality available on a web site or in a web app. Plus it would solve the fragmentation issue that so many developers complain about. Of course Google Now is an app. That’s not to say that it couldn’t exist on the Web, or shouldn’t exist on the Web. Clearly developers have reserved these types of experiences for apps, but this is misguided, as very often these experiences could be built on the Web where they would generate traffic and links to the site
March 08, 2013 aP 8:01 PM

Bryson Meunier said: 

My old friend the character limit. :) Here's the rest: 5) And this is the difference between user experience and SEO. You want businesses to develop a native application where very few people will see it or get to experience it. I want to make it available on the Web where it has 100% reach. And why not? Though it’s not perfect, HTML5 can do a lot of the things that previously only native apps could do—like access the camera, accelerometer, GPS, audio, etc. Why should these experiences that go beyond Oneweb be limited to native apps, where they will automatically have limited reach? Better for the majority of users to make the functionality available on a web site or in a web app. Plus it would solve the fragmentation issue that so many developers complain about. Of course Google Now is an app. That’s not to say that it couldn’t exist on the Web, or shouldn’t exist on the Web. Clearly developers have reserved these types of experiences for apps, but this is misguided, as very often these experiences could be built on the Web where they would generate traffic and links to the site beyond what it would normally get. This is why I said it’s better for SEO, and it can provide a good user experience as well. Thanks again for the feedback, Thunder Tech! Love when people who disagree let it be about ideas instead of ad hominem attacks. Cleveland (still) rocks!
March 08, 2013 aP 8:13 PM

The thunder::tech User Experience Team said: 

Bryson:: Ultimately, what powers our approach - which you call a "Oneweb" approach - is a solid way of organizing a site's data. With intelligent separation of content from presentation, thoughtful organization of structured content and an incredible amount of up-front planning work, adaptive content can become as powerful as customized content, and a lot less work to maintain. The up-front cost to planning may seem unnecessary or even seem terrifying, but the power of intelligent content publishing vastly surpasses the power of that which is tediously managed and manually curated. The feature phone site, for example, need not even be a site: merely an alternate presentation layer applied to the content management, using the same content in a different way. The only real reason for this is that feature phones don't understand responsive markup, and that they tend not to be as friendly toward HTML and CSS that they don't understand as, say, a smartphone or computer; delivering to them the lowest common denominator of code makes sense. With the right data approach, a healthy dose of progressive enhancement theory, a great degree of the customization you're seeking can be done in a "Oneweb"-style, "COPE" (Create Once Publish Everywhere) way. Thanks again for you comments!
March 11, 2013 aP 3:34 PM

Name
Email
Comment

Leave me blank please:

Contact us! call 888.321.8422 or fill out the following fields::