A report from the AMP Advisory Committee Meeting

I don't like AMP. I think that Google's Accelerated Mobile Pages are a bad idea, poorly executed, and almost-certainly anti-competitive.

So, I decided to join the AC (Advisory Committee) for AMP. I don't want them surrounded with sycophants and yes-men. A few weeks ago, a bunch of the AC met in London for our first physical meeting after several exploratory video calls.

These are my impressions and highlights of the meeting. You should also read the official minutes to get a more rounded view of the issues.

I am not representing my employer while working on the AC. I do not get paid for being a member - although our host (Akamai) provided refreshments, and another member paid for lunch. These views are mine and mine alone. I will be respecting the Chatham House Rule.

AMP isn't loved by publishers

We heard, several times, that publishers don't like AMP. They feel forced to use it because otherwise they don't get into Google's news carousel - right at the top of the search results.

Some people felt aggrieved that all the hard work they'd done to speed up their sites was for nothing. They felt that they had a competitive advantage against slower publishers. That was destroyed by AMP.

My recommendation is that Google stop requiring that organisations use Google's proprietary mark-up in order to benefit from Google's promotion.

AMP is not accessible

There has not been a thorough accessibility review of AMP. Many of the components are not accessible.

This is legally and morally troubling. AMP need to do much better at testing accessibility. I also think that their validator should refuse to pass a page if it doesn't meet a threshold of automatic accessibility testing.

No user research

AMP claims to be doing the best for the user. But they have published no user research about what users want, how they interact with components, or what they have difficulty with.
The launch of AMP Email highlights this. It is impossible for a publisher to use without understanding the user needs it attempts to solve.

I don't want AMP to publish videos of users, or other identifiable information. We need to see the same sort of publication as you'd deliver to your CEO.

Without user research support, there's no acceptable route to creating new AMP components.

AMP spreads fake news

When you visit an AMP page, your URL bar shows google.com/amp/.... - that has led to lots of extremely dubious content being shared by people who think they're looking at an "authoritative" Google Page.

Removing the URL bar is not the answer. Users need to be able to see who is actually responsible for publishing the content they are reading. Obfuscating it damages the web ecosystem.

Perhaps Signed Exchanges are the answer?

Signed Exchanges are not the answer

Yet another Google product to solve the mess created by a different Google product!
Signed Exchanges are complicated. Basically, a website packages up a page and cryptographically signs it. An entirely different site can then serve the bundle but the browser shows the URL of the original site!

That is, I download a page from Google, but my browser says "example.com".

It looks like Firefox and Safari won't support this. Content Delivery Networks are worried about how much traffic it will take from them. Security experts worry about the holes in the scheme. And publishers fear losing analytics.

It's a clever idea - and possibly really useful for a fully distributed network. But the current implementation looks like Google trying to keep users within its walled garden with no hope of escape.

Browser compatibility

When a user uses Chrome for Android to search Google, they get AMP results. When a user tries the same search in Firefox, they only get regular results. We found the same thing occurring with several other mobile browsers.

Google has effectively said "You have to use our browser on our search engine to get the fastest content written in our langauge."

That strikes me as possibly being anti-competitive and certainly antithetical to the idea of an open and neutral web.

My top recommendations

  • Publish all user research
    • Don't allow new components to be created without a clear user story and research to support them.
  • Accessibly audit
    • Don't validate pages which can't pass an automated a11y test
  • Stop the forced bundling
    • Let users opt-out of seeing AMP pages
    • Don't require AMP for prominent placement
    • Stop discriminating against non-Google browsers
  • Reconsider AMP4Email
    • Lots of concerns from smaller email providers
    • Security and archiving concerns
  • Work with the ecosystem rather than imposing


The meeting was good natured. While there were some robust discussions, the AC seemed fairly unified that Google had to seriously rework parts of the AMP project.

As I said in the meeting - if it were up to me, I'd go "Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process."

I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!

My personal view as advisory committee member - if AMP is to continue then it needs to become a much better citizen of the open web.

Share this post on…

15 thoughts on “A report from the AMP Advisory Committee Meeting”

  1. Tomasz Darmetko says:

    I also want to say big thank you, dear stranger, for the work you are doing!

    Google is being evil and there needs to be a counterbalance.

  2. says:

    Glad to see I am not the only one finding AMP troubling. But I wonder how much advice Google is ready to take – and implement – from the committee…

  3. Eric Mischel says:

    As 5G networks roll out and become more widely adopted why would anyone with access like that care about AMP. I get it if you live somewhere with a slow wireless connection, but IMHO this feels like a solution looking for a problem to solve.

    1. Paul says:

      Even with google scholar over 1% of searches are on mobile using 3G or lower networks (its higher for google direct)

  4. Paul says:

    One other aspect about AMP, particularly as it refers to Google Scholar. Publishers get paid based on COUNTER reports and if you’re driving all the abstract traffic to AMP pages then their page views registered by COUNTER (an industry standard) are not counted, and hence makes the publication very attractive to librarians to cancel (as the vast majority of views are to abstract pages). Google has been working on linking that traffic to the publishers web site but it again is decreasing the publishers brand to highlight google’s, and that’s why it won’t work. (Views are my own and not of my employer).

  5. James Higgott says:

    Thanks for this, Terence, and for attending the AC to represent these views.
    One additional issue I have with AMP is that publishers do not have access to the same analytics they would if users were viewing their own websites rather than AMP pages. This makes it harder for them to understand how their users are behaving and to design better products based on that information.

  6. Jeroen says:

    Thanks for doing this! AMP should be killed off quickly and I sincerely hope this is the first step in doing so.


Trackbacks and Pingbacks

  1. […] Publishers who already have fast web pages—like The Guardian—are still compelled to make AMP versions of their stories because of the search benefits reserved for AMP. As Terence Eden reported from a meeting of the AMP advisory committee: […]

  2. Inspired by Terence Eden’s example, I applied for membership of the AMP advisory committee last year. To my surprise, my application was successful.

    I’ve spent the time since then participating in good faith, but I can’t do that any longer. Here’s what I wrote in my resignation email:

    Hi all,

    As mentioned at the end of the last call, I’m stepping down from the AMP advisory committee.

    I can’t in good faith continue to advise on the AMP project for the OpenJS Foundation when it has become clear to me that AMP remains a Google product, with only a subset of pieces that could even be considered open source.

    If I were to remain on the advisory committee, my feelings of resentment about this situation would inevitably affect my behaviour. So it’s best for everyone if I step away now instead of descending into outright sabotage. It’s not you, it’s me.

    I’d like to thank the OpenJS Foundation for allowing me to participate. It’s been an honour to watch Tobie and Jory in action.

    I wish everyone well and I hope that the advisory committee can successfully guide the AMP project towards a happy place where it can live out its final days in peace.

    I don’t have a replacement candidate to nominate but I’ll ask around amongst other independent sceptical folks to see if there’s any interest.

    All the best,


    I wrote about the fundamental problem with Google AMP when I joined the advisory committee:

    This is an interesting time for AMP …whatever AMP is.

    See, that’s been a problem with Google AMP from the start. There are multiple defintions of what AMP is.

    There’s the collection of web components. If that were all AMP is, it would be a very straightforward project, similar to other collections of web components (like Polymer). But then there’s the concept of validation. The validation comes from a set of rules, defined by Google. And there’s the AMP cache, or more accurately, Google hosting.

    Only one piece of that trinity—the collection of web components—is eligible for the label of being open source, and even that’s a stretch considering that most of the contributions come from full-time Google employees. The other two parts are firmly under Google’s control.

    I was hoping it was a marketing problem. We spent a lot of time on the advisory committee trying to figure out ways of making it clearer what AMP actually is. But it was a losing battle. The phrase “the AMP project” is used to cover up the deeply interwingled nature of its constituent parts. Bits of it are open source, but most of it is proprietary. The OpenJS Foundation doesn’t seem like a good home for a mostly-proprietary project.

    Whenever a representative from Google showed up at an advisory committee meeting, it was clear that they viewed AMP as a Google product. I never got the impression that they planned to hand over control of the project to the OpenJS Foundation. Instead, they wanted to hear what people thought of their project. I’m not comfortable doing that kind of unpaid labour for a large profitable organisation.

    Even worse, Google representatives reminded us that AMP was being used as a foundational technology for other Google products: stories, email, ads, and even some weird payment thing in native Android apps. That’s extremely worrying.

    While I was serving on the AMP advisory committee, a coalition of attorneys general filed a suit against Google for anti-competitive conduct:

    Google designed AMP so that users loading AMP pages would make direct communication with Google servers, rather than publishers’ servers. This enabled Google’s access to publishers’ inside and non-public user data.

    We were immediately told that we could not discuss an ongoing court case in the AMP advisory committee. That’s fair enough. But will it go both ways? Or will lawyers acting on Google’s behalf be allowed to point to the AMP advisory committee and say, “But AMP is an open source project! Look, it even resides under the banner of the OpenJS Foundation.”

    If there’s even a chance of the AMP advisory committee being used as a Potempkin village, I want no part of it.

    But even as I’m noping out of any involvement with Google AMP, my parting words have to be about how impressed I am with the OpenJS Foundation. Jory and Tobie have been nothing less than magnificent in their diplomacy, cat-herding, schedule-wrangling, timekeeping, and other organisational superpowers that I’m crap at.

    I sincerely hope that Google isn’t taking advantage of the OpenJS Foundation’s kind-hearted trust.

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">