How Metro built a swipeable responsive WordPress site
Metro is a newspaper read by 3.5 million urban commuters daily. Like other papers, it’s engaged with the revolution mobile devices have caused in people’s reading habits. Metro’s response to the challenge is to accelerate its evolution from a printed publication into a news brand. Its iPhone and iPad apps are read on 416,000 devices a month, but last year it decided it was also time to rework its website.
The Metro dev team inherited a site built on the noSQL CRX content repository with XSLT templates and a custom CMS written in Ext JS. It was a complex, problematic, hard-to-maintain, multi-tentacled monster. The developers who had built it had all moved on to other jobs. The CMS was only compatible with a particular version of Firefox. And when the back end eventually developed a persistent, untraceable memory leak it was clearly time for a change.
WordPress was chosen as the new CMS. It had a flexible plugin and theme architecture, an active community and a big knowledge base. It was fairly mature, having grown from modest beginnings in 2003 to become a full-blown CMS used in more than 60 million sites. It was delivering high-traffic publications like TechCrunch and BoingBoing. And it had an enterprise-level cloud hosting and support service in WordPress.com VIP.
Our overriding aim was a consistent experience across devices. A responsive design was one of the earliest givens.
Because speed of response is so important to success on mobile, we thought mere CSS responsiveness wasn’t going to be good enough: we had to adapt our content before it got to the client.
We also decided to make our site swipeable. Our earlier experiments with a gesture-sensitive jQuery Mobile front end had suggested that a site that responded to swipes was a better experience on phones and tablets. It would support one of the most engaging features of those devices - and it might encourage readers to view more of our pages.
Achieving responsive content demanded an Ajax single-page application. Inspired by the example of pjax, a nifty jQuery plugin that uses pushState to provide a fast Ajax browsing experience with a working back button, our JS ninja Stephan Fowler created a plugin that intercepted all internal click events to populate a central zone with the content the user wanted to see.
Responsive content, not just responsive CSS
In an ideal world websites would tailor their content to the available bandwidth. But measuring the device’s screen width seemed a more practical way to go. It would enable us to make a reasonable guess at a device’s capabilities. It made sense to tailor our content to the same breakpoints we used in our media queries. Stephan set them at 480, 768 and 1024, corresponding to the notional widths of a landscape iPhone, portrait iPad and desktop screen.
When someone first hits the site we serve up a minimal page and measure their screen width. If the measurement suggests a better-connected device we do an Ajax request for more weighty content. We pass a parameter called
frag_width parameter tells the server-side code that we only want an HTML fragment. On the server side, the WordPress theme returns a fragment suitable for the
frag_width breakpoint. A factory class in our PHP defines different image sizes and other options for each of our layouts. We cache up to 50 fragments on the browser side - we’ve found it makes a big difference in the speed of backward swiping.
This approach delivers the greatest data savings in images, but we also reduce bandwidth requirements on smaller devices by leaving out our sidebar content.
To achieve the swipe functionality Stephan forked Matteo Spinelli’s swipeable image carousel SwipeView and mated it with our responsive content functions. The offspring of this union was a properly responsive site that swiped like a mobile app.
How it works
Just like SwipeView, Responsive Swipe expects this HTML markup on the page:
<div id="swipeview-slider"> <div id="swipeview-masterpage-0"> <!-- First left-hand content will load here --> </div> <div id="swipeview-masterpage-1"> <!-- Main content is here --> </div> <div id="swipeview-masterpage-2"> <!-- First right-hand content will load here --> </div> </div>
These divs provide the framework into which the plugin loads HTML fragments. When the visitor first lands on the site the page loads normally, with the content in the central div, #swipeview-masterpage-1; then the plugin works out what the next and previous pages will be and does an Ajax request to preload their content into the off-canvas panes on either side. This sets the site up for a smooth response to a left or right swipe gesture.
Living without document ready
Ad serving headaches
Probably the most taxing part of the project was coaxing the site to play nicely with the Google DFP ad serving system. Firstly we needed to tackle the complexities of providing a different version of each ad slot for each of our different layouts - so a 970 x 90 super leaderboard on desktops became a 768 x 90 leaderboard on tablets and a 320 x 50 mobile leaderboard on phones.
What the experience taught us
- But it’s nice. A swipeable site is a satisfying mobile and tablet experience. Our readers certainly seem to like it. Monthly unique visitors have gone up 30% since we launched in December 2012. In September 2012 we had 7.5 million; in June 2013 it’s 9.7 million. Swipeability may also have encouraged our mobile readers to stick around - page views per visit grew nearly 9% on desktops and 29% on tablets and phones, with return visits up 45%.
- A mobile-friendly site gets more mobile readers. Obvious, but true. The mobile share in our audience is up from 33% to 46%.
- WordPress is splendid. WordPress gave us exactly the kind of mature, flexible platform we had hoped for. We’re now the UK’s biggest WordPress site. And the content team are free to use any browser they like - nowadays they’re even posting from iPads.
There are still many things we want to improve. Further optimisation is high on our list - we’re currently thinking about better image compression and whether we can load our assets in more intelligent ways. The development process goes on, but we’re happy with what we’ve done so far, and we hope some of what we’ve learned in building this new style of site will prove useful to other developers.