After a short hiatus to focus on the Provincial election in British Columbia (shameless self-promo!), it’s time to get back to work unpacking the technology stacks of the world’s leading news organizations.
Last time, the investigation focused on the speed of some of the world’s top news sites, and proposed ways that sites can improve their performance. This time, we’re going to continue to focus on performance, while looking at two different approaches to serving mobile traffic: responsive web design and adaptive web design. If you need a primer on what difference between the two is, I’ve written one for you here.
Let’s kick things off with a little friendly competition. And to avoid putting any American noses out of joint, we’ll turn our attention to the Great White North today, and look at two publishers using different approaches to mobile web traffic: The Globe & Mail, with an adaptive site launched in 2010; and Global News, with a responsive site launched in 2012. Before getting into the analysis, let’s look at the results:
(Mobile performance testing, on an actual mobile phone!, courtesy of GTMetrix)
You can see the full test results here and here.
At first glance, it appears that The Globe & Mail’s dedicated mobile experience, m.theglobeandmail.com, what some would call an “adaptive website,” takes the performance prize. The feature article tested weighs in at under 300kb of data and just forty requests for resources, delivering a lightening-fast mobile page load of 3.81 seconds. The Global News site, by comparison, required almost 20 seconds to load on a mobile phone.
How can this be? The Global News site was re-developed last year by some of the leading minds in the responsive web design community, whereas The Globe & Mail’s mobile site was launched eons ago by Internet standards.
Promise of a responsive Web
Responsive web design advocates promote the philosophy of a single web experience that responds to the various screen sizes of the devices that the site is viewed on, which they claim leads to less maintenance and a better overall experience. So, I asked the GlobalNews.ca team for their perspective on why they chose to go the responsive route, and why other news organizations might consider it.
“GlobalNews.ca launched its first website in 2009, it was a relative late-comer for a major news network, and it was never really the website we wanted it to be,” said David Skok, director of digital, GlobalNews.ca, “So this was a great opportunity for us to leap-frog forward.” Most of the traffic to GlobalNews.ca comes from search and social, not people typing in the URL directly, so it has not yet been a “destination site” per se, so the GlobalNews.ca team saw this as an opportunity to play to their strength — traffic from search and social — and look at the relaunch through the lens of a mobile-first experience.
The Online News Association’s annual conference also played into the decision, says Keith Robinson, Manager, Digital Products, GlobalNews.ca. He and his colleagues went to the conference in 2011 and had the opportunity to meet with the people involved with the Boston Globe’s successful relaunch as a responsive website. Boston.com, part of the Boston Globe, reported it as “Globe starts far-ranging paid website for all devices,” and “a site designed for customers who want premium content they can read on multiple devices, from computers to tablets to smartphones.”
“The Boston Globe’s relaunch was the talk of the town,” remembers Robinson, “It was a big part of the conference and the discussions about the future of news websites.” There was also a lot of discussion about “app strategy” and “adaptive websites” but having the success of the Boston Globe’s relaunch helped to crystallize the promise of responsive web design for a lot of news organizations at that conference.
Adaptive experiences still deliver
The Globe and Mail is regarded as Canada’s newspaper of record, with the largest national circulation and second-largest daily circulation, and its online front page, www.theglobeandmail.com, is a destination for many Canadians each morning.
When asked about their adaptive strategy, which includes a dedicated mobile site (m.theglobeandmail.com), and more than eight different native applications for a range of devices, Matt Frehner, Mobile Editor at The Globe and Mail, explained: “We have a big corporate and government audience, a lot of people are on older workplace devices, so we had to ensure that we were serving them, our audience, and not just the latest iPhones.”
At the same time, the Globe wanted to take advantage of the features on higher end devices, so they devised a “bucket approach.” Their “bucket theory,” as described by Frehner, used device detection on the server to group mobile visitors into three different buckets: a fallback bucket (old Blackberry devices, for example), a middle bucket (higher-end phones without touch screens), and a high-end bucket for touch screen smartphones like the iPhone and Android. From there, the Globe could deliver a streamlined experience to each device group.
Technically, the Globe is delivering different stylesheets to different devices, and excluding certain content types and templates from certain devices. For example, not delivering a Flash video player to a device that can’t playback Flash video and so on. This is all being accomplished on top of infrastructure that they built in June 2009, Frehner said, while pointing out that responsive design wasn’t at the level then that it is today.
Asked if the Globe would choose to go with a responsive approach today, Frehner says, “We’d absolutely look at it. Whether we’d choose to go under a single URL or not is something we’d look at very closely.”
Speed matters, and adaptive delivers
When I revealed the mobile performance tests — tests that are actually run on a mobile device vs. a simulator — to Frehner, pointing out that a feature article on the m.theglobeandmail.com site is roughly 80 percent faster than a similar feature article on the redesigned GlobalNews.ca site, he was not entirely surprised.
“One of the number one things that we focus on when developing for mobile, because we think that the most important thing for user experience is the user getting to the content as quickly as possible,” Frehner explained.
A large part of the Globe and Mail’s product portfolio is their native applications, and that same thinking extends across those platforms, Frehner said, “we’re not just talking about mobile web at the Globe, we’re also talking about native app development.”
To that end, when the Globe developed an API for their redesigned apps, they did it with a conscious eye to making sure that people could get to content as quickly as possible. For example, instead of an app that loads all of the content first and then send you to the home screen, the Globe’s API helps their apps loading content progressively, as the user needs it.
It’s still an app-based world
One of the many challenges that still lies ahead for the relatively young responsive web design movement is native apps: specifically, that a lot of news readers rely on them, and reports keep coming out that the traction in “app marketplaces” is growing not shrinking.
There are other challenges also for responsive design — how to deliver images, video, interactive stories, not to mention advertising. And undertakings such as GlobalNews.ca’s redesign help to provide practical opportunity, and incentives, for the responsive design thought-leaders to take on these challenges. For example, GlobalNews.ca’s Skok said, “When we approached Upstatement, one of the design organizations involved in the Boston Globe’s redesign, trying to convince them to pick ‘this Canadian news organization’ for their next client, part of the pitch was the opportunity to ‘get our heads around video and ads.'”
But, for many, responsive design still has a long way to go before it can compete against native applications. “The advantage of native code is clear to us,” said Frehner, “There is a certain ‘je ne sais quoi’ feel of a native app that is hard to describe, but the ‘snappiness’ of native code is just better that what’s available to us today with HTML5.”
Push notifications, for example, which were only recently added to the Globe’s native iOS application, has led to significant traffic growth. Frehner said that traffic is “exploding” because of the new notifications and that the increase of mobile traffic as a percentage of overall traffic is “staggering,” more than he expected. He says it’s not uncommon for his team at the Globe is seeing exponential increases in mobile traffic from their app portfolio.
A future of intelligent web design & typography-driven sites
So where does this leave us? For news organizations, it probably comes as no surprise, that it is not a clear-cut decision between responsive or adaptive strategies. Objectives and audience need to be considered; where your technology stack is today, where you’ve already made investments, and where you’d like to it to be tomorrow are all important factors. And like so many major technology decision, it would be beneficial to experiment if time and resources make that a possibility.
If I we look to the future for a moment, and consider the signifiant changes underway in the technologies of the Internet, it’s not that hard to envision a near future of “intelligent web design,” where news websites are both responsive and adaptive at the same time. Where the Globe’s “bucket theory” becomes a little more precise, where back-end server technology delivers device-specific payloads of information, and smart front-end libraries work to adjust the layout to the device’s screen size and orientation, as well as providing device-specific functionality.
The other approach, as captured in the article “The responsive web will be 99.9% typography,” is that the web will, by necessity, move to a period of design that is largely typography-based, in an attempt to sidestep some of the layout challenges entirely. As the author points out, many recent relaunches are heavily typography-based, and The Boston Globe’s responsive relaunch is no exception.
Almost two years ago, web design luminary Oliver Reichenstein, CEO of Information Architects Inc., spoke to a class of journalists and programmers that I was facilitating about the future of news website design. He’s been an advocate for a typography-based web since at least 2006, and his firm lead the responsive redevelopment of German news magazine, Zeit Oline, in 2009. His words ring as true today as they did two years ago, and six years before that, and I’ll leave off this column with a gentle nudge to give them a listen.
This is a great article, thanks Phillip! The results of the performance testing is particularly telling: it seems like the responsive design approach (despite the enormous SEO benefits and user experience) is still lagging behind in delivering a high-performing experience on smartphones and tablets.
Many thanks for the comment.
I wouldn’t be quick to say “responsive design approach is lagging behind,” because article pages on sites like NPR (http://www.npr.org/blogs/parallels/2013/06/23/194957079/why-would-ecuador-want-edward-snowden) and USA Today show that they *can* be really, really fast.
However, GlobalNews.ca is also at disadvantage being a *broadcast* news outlet, meaning that pages are heavy with video previews and so on. That said, there’s certainly trade offs that need to be made if one is primarily focusing on speed …
But, at least for now — as as the Boston Globe has done — it appears to make sense to still seriously consider the role “apps” in the context of delivering news to end-users.
Great article, thanks Phillip!
It’s really interesting to see how media are responding to the shift in consumer technologies, web technologies and how users now access content.
Although ultimately, whether you go for a responsive or an adaptive approach, it seems that performance is still paramount – attention spans are getting shorter, and users are becoming less and less likely to hang around waiting for a page to load.
I strongly believe in the ‘one web’ benefits of a client-side adaptive or responsive approach (rather than the proxy / m-dot approach, which creates problems for SEO, marketing etc.) but, as your testing discovered, the performance of responsive sites is still quite poor. Media companies are kind of shooting themselves in the foot by creating these beautifully designed responsive sites, but not optimizing them well enough to load quickly on a smartphone or tablet!
I think over the next year or so we’re going to see a huge interest in making responsive sites much faster, and the responsive approach will keep on going from strength to strength!
It’s interesting to see how much the GlobalNews.ca and other responsive sites could improve their performance with a few, quick optimizations. Check out the results using Mobify’s responsive performance tool:
Many thanks for your comment, and for the Mobify link. Interesting to see the difference.
Per my comments above, there are sites — NPR and USA Today are two great examples — that can deliver lightening-fast responsive layouts. It’s all a matter of testing and tradeoff: what information is critical to deliver to mobile users first, load later, and so on.
As mentioned above, GlobalNews.ca is a broadcast news network, and delivering video is going to be a challenge for any mobile-first site, i.e., it’s big and there are really no great ways around that yet.
Thanks for this. Question: setting performance aside, couldn’t we say adaptive is better in the sense that users get to choose? Some users like to load a desktop version on their mobile, for instance.
Hey there @sherwinarnott:disqus,
Could have sworn I answered this already, but I don’t see the response here… so here we go again (fingers crossed):
I think it’s hard to say “adaptive is better because users get to choose,” because a choice is made for them before they arrive at the final page, e.g., they are automatically directed to the m-dot experience. I think that approach has some challenges too.
Many on the responsive side of the debate say that the adaptive experience trades-off too much and that users are left confused as to where the tools and navigation that they remember from their desktop experience have gone.
That said, my own testing seems to show that responsive sites, in the majority, are delivering very large data payloads to mobile users, which is confusing given the intentions behind the “mobile first” responsive design movement.
I think that new “apps” play the adaptive role quite well, and — with the idea of “App Badges” (notifications that there is a dedicated app for mobile users) — that could give the users a choice quite similar to the m-dot style sites.
It’s a tough question, but I would say that the answer is to know your audience well enough to make a call on their behalf.
Thanks Phillip, you did answer me. Actually, your first answer was better. :) I tried to respond, but your reply had not been “moderated” yet.
I would love to see a mobile first, adaptive strategy, which gives users a choice, but that does not use a different url. I hate different urls. Ideally this would be done through scripts (not css). You could think of it as “theme switching” but with more emphasis on content delivery. But then, I would like to be able to opt-in to ads too. ;)
My hunch about the data-payloads for responsive designs is that a lot of CMSs are letting designers (like me) mimic mobile-first designs but that have missed the point in the underlying structure.
Phew! Thought I needed to eat more blueberries or something when I couldn’t find that response. Sheesh!
Yes, adaptive + responsive under one URL is what I was trying to get at in the article when I was yarning on about “intelligent Web design” (not to be confused with the _other_ “intelligent design” movement!).
You might be right re: CMSs. That’s why we need the post-post CMS CMS, http://www.phillipadsmith.com/2011/07/the-post-post-cms-cms-loosely-coupled-monoliths-read-only-apis.html ;)
Hey Philip , Nice post. you have rightly hit the nail on its head with the loading time issues of RWD. One method is to have RESS. In my quest to learn more about the RWD, I have registered for a webinar on Best practices in Responsive Web Design, it looks a promising one http://j.mp/125MSXv
Many thanks, @sushantsaraswat:disqus. Let us know how the webinar goes. :)
Thanks for bringing up this hot topic with so many variances and
options to take into consideration.
Is it really a discussion about responsive web sites vs. native apps
or rather web apps vs. native apps. I feel it’s more about generally
web apps on mobile vs. native mobile apps while repsonsive design is
being a very specific way of doing web sites/apps. Also remember,
creating performant responsive design websites is still a challenge.
Guy Podjarny from Akamai did some great research finding that 82% of
the responsive websites don’t optimize for mobile hence impacting
performance and load time which is so crucial for mobile. If you don’t
create responsive websites while focusing also on performance, there
is almost no chance you can create a smooth mobile (web) app
I also want to ask what the rationale was to test it on Android Chrome
Nexus? Have you tested this on iOS browsers as well? Did you get other
numbers? Was the synthetic test done with cache or without?
Looking at the posted url test results, they don’t match the numbers
you mentioned. Would you be able to shed some light into this. E.g.
http://gtmetrix.com/reports/www.theglobeandmail.com/FbvtvhT0 shows the
test results for the full site. (Btw, I use webpagetest.org for
synthetic testing and it gives you lots of performance options)
Would you be able to share the results for the other top sites as
well. What CBC site did you test? Mobile touch or desktop? I am
curious, because I am part of the mobile/performance team at the CBC
and would like to get more insights on how and what you tested the CBC
While synthetic testing is really important, it would be also valuable
to do more RUM testing on those top sites for comparison. RUM helps
you to take into consideration the real user with their real network
connectivity and real latency. By using RUM tools, CBC gathered page
load times of 2-4s for more than 60% of our users.
Synthetic page load test results e.g. with 3g simulation for CBC’s
mobile touch site are normally below 12secs you found ;))
I’d be interested hearing more about your test results and how you’ve
set them up.
Thanks for the great research and thoughts.
It’s a fantastic story, Phillip, and a great series to boot. I apologize as the site’s executive editor for the issue with comments and moderation. We recently switched to WordPress and had some permissions issues with our moderators. They’ve been cleared up so we shouldn’t have problems in the future, hopefully. I appreciate your patience with this.
Many thanks, Mark!
No worries. Totally understand. Glad to be able part of the “lab.” :)
I’m a little late to the comments here, but I think your point about NPR and USA Today is a great one. There’s a big difference between good responsive implementation and poor implementation, and most people lump all responsive together when discussing it as a technique.
Barbara Bermes My sincere apologies for the tardy reply! Pesky deadlines!
Many thanks for your comments. I really appreciate them. Quick responses are:
+ The Google Nexus is the device that is used by GTMetrix and that’s the sole reason that the tests are specific to that device.
+ The reason I use GTMetrix over webpagetest.org (other than the obvious reason that the later is terribly ugly!) is because GTMetrix has an API (http://gtmetrix.com/api/) that I use to automate the tests. If I had to test all of the sites one at a time and then carry that data over to a spreadsheet, I wouldn’t have any time to write the column! ;)
+ The tests are done with the native device caching (as far as I’m aware). For that reason, I run the tests multiple times for each feature article to get a relatively consistent speed for the test. You can read more about the GTMetrix configuration for mobile here: http://gtmetrix.com/faq.html#faq-mobile-ruleset
+ You can see all of the test data in the public Google Doc here: https://docs.google.com/spreadsheet/ccc?key=0AgZzmiG9MvT4dFVIWjI0Z0R3eHhKdkxDYVctME5lVnc&usp=sharing
Hopefully that helps a bit. Admittedly, having unlimited time to run these tests across several different testing suites and services, I tend to stick with one or two tools that I feel provide good representative data and an API that can I use to automate the tests and process the resulting data.
Hope that helps a bit. Really grateful for the questions. :)