Written by Oscar Perez, Condé Nast
What is the Google led AMP Project?
Why do we publish on AMP?
Condé Nast is one of the world’s most prestigious publishers. You may recognize some of our brands which include Ars Technica, Bon Appétit, Golf Digest, GQ, Pitchfork, The New Yorker, Vanity Fair, Vogue, Wired, and others. As a publisher, implementing AMP was a no-brainer. AMP delivers many benefits in terms of performance, consistency, and experience for our mobile users. Users arriving from Google undergo an uninterrupted flow from search into our content. AMP content loads quickly thanks to Google’s CDN and AMP HTML enforced performance guidelines. The AMP Layout System ensures a great reading experience by preventing pages from jumping around as third-party content loads. Our regular sites are not by any means slow, we constantly beat our competitors’ load and render times, but there are certain performance guarantees that Google can deliver to their users (e.g. prefetching) when content is on their CDN.
Let’s take a step back and think about what incentivizes us as a publisher. To generate revenue, we need our content to be impactful and discoverable by the largest possible audience. Keeping this audience engaged with quality content across our brands helps us maximize our revenue. AMP helps us satisfy these needs. AMP increases the visibility and discoverability of our content by allowing it to be included in Google’s Top News Carousel, as well as improving the experience of regular Google search results. AMP ensures our content consistently loads quickly anywhere in the world with a seamless experience from Google search through their integrated AMP viewer. This seamless experience leads to increased engagement and decreased bounce. Monetization benefits are less decisive and pending further analysis of our current implementation. Our initial AMP launch only served ads with contextual targeting which have a lower CPM (cost-per-mille, the amount a publisher makes for a thousand impressions of an ad) than the ads we serve on our regular mobile sites which support both contextual and audience targeting. As we’ve improved targeting and added support for other revenue partners, we see that CPM for AMP has either stayed the same or increased depending on the brand.
We went live with AMP on Vanity Fair a little over a year ago. Post-launch, the traffic and search rank results were very positive: click through rate from Google search went from 5.9% (Regular) to 10.3% (AMP), and average search position went from 5.9 (Regular) to 1.7 (AMP). Since then, we have deployed AMP across fifteen of our brands and we have been very pleased with the results. Today, AMP accounts for 79% of our mobile search traffic and 36% of our total mobile visits. We were able to scale our AMP implementation at Condé Nast from one to fifteen brands with minimal disruption and engineering effort from our brands.
How have we implemented AMP?
Our brand’s AMP content gets discovered by having the regular page include a
link rel="amphtml" tag in their head section pointing to the URL for the AMP version of the page. In our architecture, we proxy traffic for AMP URLs to our internal AMP service which is in charge of generating the AMP version of the requested content. The following diagram is an overview of our content creation and AMP distribution architecture:
All of our brands use Copilot, our internal Content Management System (CMS). Our CMS stores content in a customized version of markdown called Copilot Markdown. Copilot Markdown is simply a set of extensions on the CommonMark specification which adds special syntax for embeds, callouts, sections, and other features used by our editors.
When a Google user opens an AMP result for one of our brands, the Google AMP CDN quickly delivers its latest cached copy. Behind the scenes, the Google AMP CDN triggers a request to the URL of the AMP document on our brand’s domain. All of our brands are fronted by the Fastly CDN which provides another layer of caching. When the request hits Fastly, logic in the brand’s varnish control language ([VCL) configuration determines if the request is for AMP content. If so, Fastly sets the backend for the request to be the AMP Service which then takes over and generates AMP HTML for the requested content.
In order for our AMP service to render a piece of content, we have to fetch the content from our CMS, then parse and transform it into React components which get rendered into valid AMP HTML. The following diagram shows this rendering pipeline which is internal to the AMP service:
At Condé Nast, our tech stack uses Node.js and React for most of our brands’ regular websites. Using React with server side rendering to generate AMP content makes perfect sense for us. This choice allows our brand engineers to easily contribute to our AMP codebase. The use of Node.js and React also allows us to reuse components and helper code across our regular sites and AMP service.
Ensuring that brands maintain their look and feel when served over AMP was an important priority when creating the AMP service. The AMP service enables this by allowing brands to provide their own configuration and their own Sass files that override our sane defaults. If provided, the configuration and SCSS files control the output AMP HTML markup and CSS respectively. Through this approach, brands are able to toggle features and customize their design. In the future, we will take further advantage of React components extensibility to allow much deeper customization of brands’ AMP HTML markup output. Having a service that’s able to do this for all of our brands has proven very valuable and drastically reduced duplication of effort. To start serving AMP traffic, a brand just needs to add a single configuration file and modify their Fastly VCL configuration. As we’ve grown the feature set of our AMP implementation and onboarded more brands, this architecture has proven to be a very scalable solution.
What did we learn?
Our centralized content management system and service-oriented architecture makes it nearly effortless to onboard new brands onto AMP. This wasn’t always the case. When we onboarded our first brand we were not using a service architecture, instead we had a plugin architecture where each brand had to depend on the AMP plugin. This plugin architecture resulted in duplication of code as we onboarded other brands, it also made it challenging to roll out new plugin versions across all brands. These problems went away when we switched to the shared AMP service. The power and scalability of a service-oriented architecture have been clear. The AMP service validates the use of cross-brand shared services throughout Condé Nast. Furthermore, the benefits of having our data stored in a common format (Copilot Markdown) for all our brands, with shared tooling, APIs, and effort have never been more evident.
Overall, AMP has had a positive impact to the business in terms of traffic and to our Google users in terms of experience. Today, AMP accounts for 36% of our total mobile traffic and we are continuously adding features that create monetization opportunities for the business and improve the experience for our AMP users. We are very excited to see what the future holds as other platforms outside of Google decide to deliver AMP content and more organizations start contributing to the AMP Open Source Project.