Going all-in with AMP at Trinity Mirror

Rob Hammond
Reach Product Development
4 min readMar 17, 2016

Google’s Accelerated Mobile Pages project is a bold attempt to reshape the way publishers serve their visitors on the mobile web.

Much has been written about the AMP project, its potential, challenges and limitations. In a difficult industry landscape, arguably the last thing web publishers need right now is yet another platform to spend time and money developing.

At Trinity Mirror we have embraced the AMP platform. We were able to launch with around 90% of our articles across 29 websites within the four-month window from the announcement in October to the public launch on Google’s search results on February 23rd.

Challenges

Launching what is in effect a parallel website for a news site with tens of millions of articles is not an easy task. Doing it for 29 is somewhat harder.

As with many other publishers our resources are limited. We achieved this with a small team — and a change of development team halfway through the project, due to a wider internal restructure.

The team has also been working concurrently on other distributed platforms including Facebook Instant Articles and Apple News. Using the same development team for all three has been difficult in terms of time constraints, but the consistent team has meant everyone understands the core concepts behind each platform.

The AMP Project’s (laudable) push for HTTPS has been a challenge for advertising support in particular. Specifically for Trinity Mirror sites, we have yet to roll out HTTPS across our news assets and content, so this has presented a number of difficulties.

The last challenge is one that has been faced by every publisher looking at the AMP platform — it has been built and released so quickly that often new features would pop up for higher priority areas than those we were currently working on. Weekly sprints, daily releases, and a very active Slack channel have been staples of our AMP development team.

Architecture

We looked at two choices when we first started working on AMP:

  1. Use an internal API directly from our CMS to populate the content of AMPs. A logical choice, but it was undergoing development at the start of the project, and introducing a big dependency seemed a bad idea
  2. Hack together AMP support by repurposing (aka scraping) our public web pages

After some debate we decided to go for option 2. We wanted to build something very quickly, and adding a layer on top of something that already existed seemed better than building a whole new feature into an enterprise CMS. This also gave us AMP coverage of all historical articles rather than only new ones.

Minimum MVP

We worked initially towards an minimum MVP — a fully stripped back article with header, text, images and captions. The MMVP was ready less than a month after Google’s announcement of the AMP project.

In fact, thanks to the scraping/repurposing approach we took, within a month we essentially had an engine that could create a basic AMP format page from any website, provided it had the right structured data.

As with our approach on Apple News and other distributed platforms, we built the article functionality from the bottom up — first focusing on essentials such as text, images, video. Anything else was optional while we figured out how (and if) we could support it.

Obviously the downside is the user experience isn’t always perfect — for example in Apple News and AMP, our charts, polls and quizzes are replaced by placeholder links. These allow the user to click through to the full site if they’re interested.

As none of the major distributed platforms are quite complete themselves, offering a cut-down experience that gives users the advantages of the new platforms while highlighting the ‘full fat’ version makes sense for the short term, and gives our users the best of both worlds.

Results

Doing a straight comparison of speed between our standard mobile articles and the AMP pages shows the kind of speed improvements we have seen.

Standard Mirror mobile site (left) vs AMP version (right) on gtmetrix.com

It’s worth noting that the comparison is simply of the pages served directly on our site; further improvements would be seen if it was possible to show Google’s CDN version of our AMP pages.

Future developments

We’re continuing to iterate and improve our support of the AMP platform. Further experimentation with live blogs, interactive content such as polls and quizzes, and additional advertising formats are the next challenges we hope to overcome within the platform.

--

--

Rob Hammond
Reach Product Development

PS Director, EMEA at BrightEdge. Technologist, SEO, renewable energy enthusiast