Debunked: 10 Misconceptions about AMP
Disclosure (updated on 10/15): For those that have come here for the first time or don’t like to read About pages, I work at Google and am a web developer advocate, currently focussed on AMP.
#1: “AMP is a new render engine / programming language”
AMP is a open source web components format and library. Compared to other libraries and frameworks, AMP’s biggest difference is that it takes a whitelist approach in what you’re allowed to do.
Why take away things? Because it’s too easy to degrade a site’s performance with a seemingly innocent little piece of code, and too frickin’ hard to debug what caused it many months later. Imagine you’re a tourist in Germany driving on the right lane of the Autobahn, not knowing the very left lane is a much faster option. AMP is the thing that forces you to stay on the very left lane of the Autobahn, and keeps your path ahead clear of obstacles.
AMP doesn’t just take away things: It offers lots of custom tags with advanced built-in functionality. When using these custom tags and adhering to a few other rules, AMP ensures the site stays on a fast path. It does so by forcing static layouting and efficient loading, among other optimizations.
AMP comes with a spec that documents what kind of tags are compatible and which aren’t. It ships with a built-in validator that gives you insights into the validity of the current page. To be sure, allowed is a strong word: Technically, AMP itself might run perfectly fine with all of the forbidden tags — it just means your pages won’t get validated (at which point all bets are off when it comes to performance, plus your content might not show up in platforms integrating with AMP). Practically of course, this defeats the point of AMP.
But wait, isn’t there more to it?
Actually, no. AMP is really just that — a web components ecosystem. But because it’s so easy to confirm programmatically that a page is valid AMP, it enables all sorts of cool things. Among those cool things:
- Fast, free caching for all valid AMP pages (e.g., through the Google AMP Cache)
- A pretty good bet that a validated AMP page is fast and user friendly
- AMP pages are self-contained (and can thus be embedded into 3p platforms)
This allows all sorts of third-party platforms to do cool things with it, such as:
- The Top Stories carousel on Google Search
- Linking to AMP pages on Pinterest
- Consuming AMP pages within a PWA
#2: “AMP is a Google project”
Update (10/17): There’s been some questions and critique about this misconception. The two original paragraphs are still valid, but here’s a TL;DR: All current core contributors to AMP work for Google, AMP is effectively a Google-led project. It’s however designed as a standalone open source project, and we’re inviting developers and the community to step up and contribute to become core committers and make AMP fully independent.
AMP was originally conceived in discussions between publishers and Google in 2015 (Of course, the experiences driving AMP, like slow-loading pages on the mobile web, were observed industry-wide). From those early beginnings it was developed hand in hand with publishers, ad vendors, technology providers and platforms besides Google such as Twitter, Linkedin and Pinterest. AMP was also conceived from day one as an open source project of the “GitHub generation” with very open collaboration. As of today, AMP received pull requests from over 200 contributors, the vast majority of whom do not work for Google.
Google does employ a team working full time on AMP and so a large number of substantial contributions come from that team, but they are going through the same public “Intent to implement” process as everyone else. The Google team also publishes its weekly meeting notes and otherwise tries to make the project as accessible to outside contributors as possible.
#3: “AMP needs Chrome to run”
Absolutely not! AMP is a cross-platform and cross-browser library that supports the last two versions of all popular mobile and desktop browsers:
#4: “AMP restricts my layout and design abilities”
You’ll be surprised how much you can do on AMP pages. AMP does restrict the usage of a few tags and very performance-hurting CSS properties, but all things considered, there are very few limitations on how you can style your site. Want to go crazy with a 5x nested flex box layout? Go for it. Crazy pseudo elements based UI? Sure.
Here’s a quick example I’ve built for the AMP roadmap page:
#5: “AMP is for “light” experiences”
Sort of true, but misleading. Depends on how you define “light”. AMP is, strictly speaking, targeted at static content. But said static content can have crazy cool art-directed animations, sidebars, lightboxes, accordions, carousels and more. Checkout some of the advanced examples over at AMPByExample.
#6: “AMP is mobile-only”
Alright, the “Mobile” in “Accelerated Mobile Pages” definitely doesn’t help to debunk this, but this is in fact far from the truth.
AMP is an extraordinary powerful solution across all surfaces and was designed with the objective of allowing publishers and developers to shift engineering resources from the grind of supporting multiple platforms to instead focus on creating great new features that can be easily available for all users on any device type.
AMP itself is built from the ground up with responsive design in mind. Most platform integrations are currently focussed on mobile, but you’ll still get many of AMP’s benefits on Desktop.
To learn how to use AMP across all resolutions and device types, head over to my blog post about that ‘mobile’ in Accelerated Mobile Pages.
#7: “I can’t use AMP with my current website”
Now that we debunked #4, there’s no reason why you couldn’t use AMP with your current website — as you now know after reading the first paragraphs, AMP is really just a web components library. In fact, the AMP homepage itself uses AMP exclusively:
Of course, like with any library out there, AMP isn’t for everyone. Think about whether you can live with AMP’s imposed restrictions (and benefit from them), and only if the answer is yes, make the switch. For a rule of thumb, if you don’t have any static content, and your pages aren’t leaf pages (pages that are entry points, e.g. that people click on in search engines), AMP might not be for you.
#8: “AMP isn’t useful if I can do it all by myself”
While AMP’s performance optimizations are a no-brainer if you don’t have a bunch of web gurus working for you, a lot of us take great pride in our abilities to optimize our sites to the max. In fact, since AMP is a generic library, it might miss out on some specific optimization strategies for your own site, which means that your manual work might always produce an even faster site.
Unfortunately though, browsers and big platforms like Google Search today have no mechanism to prove that your site is indeed fast and user friendly. So by choosing to do it all on your own, you might create a super fast site, but there’s no way to know for sure. This validation aspect of AMP is what makes it so attractive for 3p platforms.
#9: “AMP is only good for broader reach/distribution”
Sure, if you AMPlify your news site, there’s a chance you’ll appear in the Top Stories carousel, and Google accelerates your AMP page with an inline viewer throughout mobile search results. But companies like eBay now create AMP pages (example) even though they’re not reporting the news.
So what did eBay get out of AMP? In their own words:
“One of the good things about AMP is that at the end of the day it is a bunch of best practices for building mobile web pages. We were already following some of them, but adoption was scattered across various teams, each having its own preference. This initiative helped us consolidate the list and incorporate these best practices as a part of our regular development life cycle itself.”
#10: “I have to choose between AMP and PWA”
AMP and PWA are complementary technologies, with completely different use cases. Used together, they help you create what I think is currently one of the best user journeys for content sites:
- A user discovers a link to your content and clicks it
- The content loads almost instantly, and is a pleasure to consume
- After reading, the user is invited to consume more or upgrade to a even better experience with faster navigation, push notifications and offline support
- When the user takes you up on your offer, they are instantly redirected to that magical, app-like experience that they can install onto their homescreen.
Sounds too good to be true? All you need to do to get there is the following (or a variation thereof):
- All content “leaf” pages (those that have specific content, not overview pages) are published in AMP for that near-instant load experience
- These AMP pages use <amp-install-serviceworker> to warm up a cache and a PWA app shell while the user is enjoying your content
- When the user clicks on another link on your site (e.g. the call to action at the bottom for a more app like experience), the Service Worker intercepts the request, takes over the page and loads the PWA app shell instead
- And finally: The now-loaded PWA app shell can then embed AMPs as data source, allowing you to create just one content-serving backend (for both standalone AMP browsing and your PWA).
There’s much more to talk about when it comes to AMP and PWA, so stay tuned and watch this space for a more in-depth article on the topic.
So there you have it. 10 misconceptions, with 10 debunked answers that hopefully give you a bigger, clearer picture of AMP, and whether it’s a good fit for you. Have any more questions? Get in touch!
