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.