About that ‘mobile’ in Accelerated Mobile Pages
There’s nothing inherently ‘mobile’ about AMP. AMP is designed to be mobile friendly, and with slow hardware and high latency connections, the boost you get with AMP on smartphones is going to be felt a lot stronger than on desktops. But AMP isn’t mobile only — it’s mobile first.
In fact, if you can, I discourage you from going mobile-only with AMP. AMP has strong support for media queries, and extends the native browser capabilities with advanced responsive layout functionality. It’s never been easier to build a truly responsive page, and going “mobile first” means you focus on a single site for all, optimized for mobile but expanded for other device types.
Paired vs. Standalone
In the past, we’ve been telling publishers to generate separate version of their page in AMP format and link the original page to the AMP page. This was mostly because AMP was a young framework, and it would have been way too early to go all-in on AMP. It’s what we call “paired”, and if you’re already generating different outputs via your CMS, for instance to support RSS and Instant Articles, this is a no-brainer.
But the paired mode — creating a separate path for your AMP pages that will only ever be seen on mobile (e.g. through a redirect to a /amp/ directory) — comes with a set of issues attached: Sharing links between AMP and Desktop sites can fail in many ways, like showing a mobile variant on a way-too-large Desktop browser. Content that’s available on the Desktop pages might be accidentally missing or outdated on the functionally reduced mobile AMP pages. You’re now repeating many mistakes of the m.dot world (m.dot describes having an entirely seperate version of your site for mobile).
Instead, you can, and probably should, go “standalone”. This means you’ll use AMP like any other web component library out there. Instead of branching out your pages, you continue to have a single, AMP-enabled page. Read on to learn about the challenges and wins with this approach.
With AMP, you can build a responsive site that works well across mobile, tablet and desktop. In fact, I’ve put my money where my mouth is, and made the ampproject.org site an AMP site, all the way:
There’s no ‘original’ canonical URL to another site (it’s still required for an AMP doc to have the tag, but it’s ok to point to itself).
It’s using the new element to show a sidebar, the (AMP-specific) layout=”responsive” attribute on images and simply CSS media queries for everything else.
It’s using media queries to show, hide and change the layout based on resolution, like any other site would (Check out how I created the AMP roadmap for an advanced example)
Tools, not rules
This isn’t a “never do this” kind of advice. As mentioned earlier, there are valid reasons for generating a separate AMP page for every ‘full’ canonical page. But if you go that route, be extra careful to not repeat the same mistakes we’ve all seen from m.dot sites.
And if you go all the way in and decide to go AMP-only, get in touch and let me know what worked and what didn’t. Remember, AMP is an open source project, and we always welcome your feedback and pull requests to make AMP more useful to everyone.