AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives

The Chrome Dev Summit concluded earlier this week. Announcements and discussions on hot topics impacting the greater web community at the event included Google’s Privacy Sandbox initiative, improvements to Core Web Vitals and performance tools, and new APIs for Progressive Web Apps (PWAs).  

Paul Kinlan, Lead for Chrome Developer Relations, highlighted the latest product updates on the Chromium blog, what he identified as Google’s “vision for the web’s future and examples of best-in-class web experiences.”

During an (AMA) live Q&A session with Chrome Leadership, ex-AMP Advisory Board member Jeremy Keith asked a question that echoes the sentiments of developers and publishers all over the world who are viewing Google’s leadership and initiatives with more skepticism:

Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?

The question drew a tepid response from Chrome leadership who avoided giving a straight answer. Ben Galbraith fielded the question, saying he could not comment on the AMP-related legal proceedings but focused on the Privacy Sandbox:

I think it’s important to note that we’re not asking for blind trust with the Sandbox effort. Instead, we’re working in the open, which means that we’re sharing our ideas while they are in an early phase. We’re sharing specific API proposals, and then we’re sharing our code out in the open and running experiments in the open. In this process we’re also working really closely with industry regulators. You may have seen the agreement that we announced earlier this year jointly with the UK’s CMA, and we have a bunch of industry collaborators with us. We’ll continue to be very transparent moving forward, both in terms of how the Sandbox works and its resulting privacy properties. We expect the effort will be judged on that basis.

FLoC continues to be a controversial initiative, opposed by many major tech organizations. A group of like-minded WordPress contributors proposed blocking Google’s initiative earlier this year. Privacy advocates do not believe FLoC to be a compelling alternative to the surveillance business model currently used by the advertising industry. Instead, they see it as an invitation to cede more control of ad tech to Google.

Galbraith’s statement conflicts with the company’s actions earlier this year when Google said the team does not intend to disclose any of the private feedback received during FLoC’s origin trial, which was criticized as a lack of transparency.

Despite the developer community’s waning trust in the company, Google continues to aggressively advocate for a number of controversial initiatives, even after some of them have landed the company in legal trouble. Google employees are not permitted to talk about the antitrust lawsuit and seem eager to distance themselves from the proceedings.

Jeremy Keith’s question referencing the AMP allegations in the recently unredacted antitrust complaint against Google was extremely unlikely to receive an adequate response from the Chrome Leadership team, but the mere act of asking is a public reminder of the trust Google has willfully eroded in pushing AMP on publishers.

When Google received a demand for a trove of documents from the Department of Justice as part of the pre-trial process, the company was reluctant to hand them over. These documents reveal how Google identified header bidding as an “existential threat” and detail how AMP was used as a tool to impede header bidding.

The complaint alleges that “Google ad server employees met with AMP employees to strategize about using AMP to impede header bidding, addressing in particular how much pressure publishers and advertisers would tolerate.”

In summary, it claims that Google falsely told publishers that adopting AMP would enhance load times, even though the company’s employees knew that it only improved the “median of performance” and actually loaded slower than some speed optimization techniques publishers had been using. It alleges that AMP pages brought 40% less revenue to publishers. The complaint states that AMP’s speed benefits “were also at least partly a result of Google’s throttling. Google throttles the load time of non-AMP ads by giving them artificial one-second delays in order to give Google AMP a ‘nice comparative boost.‘”

Although the internal documents were not published alongside the unredacted complaint, these are heavy claims for the Department of Justice to float against Google if the documents didn’t fully substantiate them.

The AMP-related allegations are egregious and demand a truly transparent answer. We all watched as Google used its weight to force publishers both small and large to adopt its framework or forego mobile traffic and placement in the Top Stories carousel. This came at an enormous cost to publishers who were unwilling to adopt AMP.

Barry Adams, one of the most vocal critics of the AMP project, demonstrated this cost to publishers in a graph that shows the percentage of articles in Google’s mobile Top Stories carousel in the US that are not AMP articles. When Google stopped requiring AMP for the mobile Top Stories in July 2021, there was a sharp spike in non-AMP URLs being included.

Once AMP was no longer required and publishers could use any technology to rank in Top Stories, the percentage of non-AMP pages increased significantly to double digits, where it remains today. Adams’ article calls on the web community to recognize the damage Google did in giving AMP pages preferential treatment:

“But I’m angry. Because it means that for more than five long years, when AMP was a mobile Top Stories requirement, Google penalised these publishers for not using AMP.

There was no other reason for Google to stop ranking these publishers in their mobile Top Stories carousel. As is evident from the surge of non-AMP articles, there are likely hundreds – if not thousands – of publishers who ticked every single ranking box that Google demanded; quality news content, easily crawlable and indexable technology stack, good editorial authority signals, and so on.

But they didn’t use AMP. So Google didn’t rank them. Think for a moment about the cost of that.”

Even the publishers who adopted AMP struggled to get ad views. In 2017, Digiday reported on how many publishers have experienced decreased revenues associated with ads loading much slower than the actual content. I don’t think anyone at the time imagined that Google was throttling the non-AMP ads.

“The aim of AMP is to load content first and ads second,” a Google spokesperson told Digiday. “But we are working on making ads faster. It takes quite a bit of the ecosystem to get on board with the notion that speed is important for ads, just as it is for content.”

This is why Google is rapidly losing publishers’ trust. For years the company encumbered already struggling news organizations with the requirement of AMP. The DOJ’s detailed description of how AMP was used as a vehicle for anticompetitive practices simply rubs salt in the wound after what publishers have been through in expending resources to support AMP versions of their websites.

Automattic Denies Prior Knowledge of Google Throttling Non-Amp Ads

In 2016, Automattic, one of the most influential companies in the WordPress ecosystem, partnered with Google to promote AMP as an early adopter. WordPress.com added AMP support and Automattic built the first versions of the AMP plugin for self-hosted WordPress sites. The company has played a significant role in driving AMP adoption forward, giving it an entrance into the WordPress ecosystem.

How much did Automattic know when it partnered with Google in the initial AMP rollout? I asked the company what the precise nature of its relationship with Google is regarding AMP at this time.

As part of our mission to make the web a better place, we are always testing new technologies including AMP,” an official spokesperson for Automattic said.

This may be true but Automattic has done more than simply test the new technology. In partnering with Google, it has been instrumental in making AMP easier for WordPress users to adopt.

We received no funds from Google for the project,” a spokesperson for Automattic said when asked if the company was compensated as a partner in this effort.

What did Google promise Automattic to convince the company to become an early partner in the AMP rollout? I asked if the company has an official response to the allegations that Google was throttling the load time of non-AMP ads by giving them artificial one-second delays in order to give Google AMP “a nice comparative boost.” The spokesperson would not respond to the specific claims but indicated the company did not have prior knowledge of any actions that might not be above board:

We chose to partner with Google because we believed that we had a shared vision of advancing the open web. Additionally, we wanted to offer the benefit of the latest technology to WordPress users and publishers including AMP.

While we aren’t able to comment on legal matters in progress, we can say that over the course of our partnership, we were not aware of any actions that did not align with our company’s mission to support the open web and make it a better place.


The antitrust complaint also details a Project NERA, which was designed to “successfully mimic a walled garden across the open web.” When asked about this, Automattic reiterated its commitment to supporting the open web and gave the same response: “We were not aware of any actions that did not align with our company’s mission.”

In examining the weight of the DOJ’s allegations, it’s important to consider how this impacts WordPress as a CMS that is used by 42% of the web. A new performance team for WordPress core is being spearheaded by Yoast and Google-sponsored employees. The initial proposal is to improve core performance as measured by Google’s Core Web Vitals metrics. These metrics are a set of specific factors that Google deems important for user experience.

Without questioning the personal integrity of the contributors on that team, I think it’s important that Google leadership acknowledge how AMP has damaged publishers’ trust in light of recent events. Many of these contributors are heavily involved in building AMP-related resources for the WordPress ecosystem. Are their contributions purely aimed at making WordPress core more performant or is there a long game that serves Google’s interests being woven into this initiative? Would these employees even be aware of it if there were?

These are important considerations if Google defines the performance metrics WordPress is measuring against. The company’s alleged misdeeds seem to be buried high up in the command chain. Those tasked with peddling AMP may have had no knowledge of the alleged anticompetitive practices identified by the DOJ in Google’s internal documents. The WordPress community should continue to be vigilant on behalf of publishers who depend on WordPress to remain an unadulterated advocate for the open web.

30

30 responses to “AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives”

  1. The evidence indicates Automattic are not being straight forward in characterising their relationship with google with respect to AMP.

    I’ve been a long term critic of AMP. Pre dating by far Jeremy Keith etc

    About two years ago I gave a negative review the official AMP plugin. Both criticising its poor performance and the negative impact of AMP on the web.

    The review was deleted twice, and I was warned and put on probation. Despite breaking no policy and being a former user of the plugin.

    • If you don’t like Overall AMP technology and posted review for it, it will be removed, it has to be specific to the AMP WordPress plugin.

      Also, the AMP plugin doesn’t put ads on your site you can’t blame the AMP plugin for features that the AMP plugin doesn’t offer.

      Since you abused the plugin review system to express your frustration about AMP you are put on probation.

      • My first review criticised the plugin on both a performance and technology point of view. It was deleted, with an explanation to limit the review to the functionality not technology. No policy cited and I would have thought a bad technology could be reviewed if the plugin enabled the technology.

        I added a second review (with the same poor rating) limiting it to performance and database issues (I had used the plugin previously). It was deleted again with an “explanation” that I was acting in bad faith, a refusal to elaborate and I was put on probation.

        Neither review mentioned ads.

        Happy to share the emails etc that document this. I wonder how many other reviews criticising Automattic and the AMP plugin have been deleted.

        • Please share the documents, We would love to know the performance and database issues you faced.

          Also if the plugin has issues you open a support topic, don’t directly go for reviews, let devs give a chance to address the issue.

          • So you are “not a forum moderator” but you know exactly what happened around those unwanted reviews and now suggest that you are involved in development of this plugin and then demand to do this and that. As explained, this kind of damage control causes even more damage, please stop posting and ask for communication instructions at your managers desk.

          • To clarify

            I used the plugins years ago, it had performance and database issues. I uninstalled it.

            I later came to the conclusion the whole technology was harmful, and then left the reviews which were deleted. IMO unfairly and suspiciously

            I have no intention of using the plugin again and advocate others uninstall it so I won’t be posting on the support forums. However I checked the forums then and it appears the issue with the plugin filling up the database with rubbish is still around.

  2. This does stink. It demonstrates some of the rock’n’roll BS that you often see in the tech world. Google seem to have constructed an amalgam with AMP and core web vitals. While on its own, core web vitals does function well to impel improved speeds and better UX, it also drives a lowest common denominator in terms of design and impedes unique creativity. I would be sceptical when I eyeball a site loading promptly on a slow 3.8Mb connection and then being handed a so-so score from Page Speed Insights.

  3. I really like this article. I was and am vocal against AMP as it is at its best an intermediate solution for performance (given the web and devices are getting so much faster). Like the long gone WAP was once on the advent of Nokia phones accessing the first mobile Internet.

    Apart from that, it is mainly used by its proponents to exert dominance over the web. We shouldn’t yield the open web to a standard like AMP in the long term, and therefor should look to abandon it asap.

    Even the latest page speed campaign by Google, even if good on the surface, is showing us how much dominance Google already wields as it becomes such a big selling point for Plugins, Themes and tech. development.

    I am not saying that bloat or slow pages are a good thing, but all these initiatives come at the cost of diminishes creativity and unified design. Let’s make the web fast, but most important fun, again.

  4. Stop using Chrome. Allowing Google to be present at all points of the stack, combined with the facts of human nature, is a recipe for various bad things at different levels. These kind of stories that we’re seeing with AMP are not shocks, they’re just what you expect when too much power is in one set of hands.

    • You are completely on point about avoiding Chrome. I have begun avoiding all Google products. I have no intention of using ad networks on my sites so I dont even use analytics. If you arent paying for a product you are the product.

  5. All the arguments against AMP seem to ignore all the good parts.
    Speed was only one part of it
    Benefits:
    An abstracted analytics tag. Let’s face it. Most news sites suffered from hundreds of Javascript tags. We needed a way to have one protocol to broadcast that info out to all the providers we want to have that data.

    In a world that’s quickly becoming distributed, we need a safe and uniform way too cache on the edge. AMP is the only open solution I know of that enables this.

    These are huge and all within an open project that Google has handed off now that we have uptake.

    Thank you Google.

    This doesn’t mean I don’t see the negative points others make. But they never include the positive parts.

    • Google handing it off was a ruse to try and stem bad publicity. They did so when there was already speculation that AMP was a trojan horse designed to benefit Google itself.

      Now that we know that was indeed the case all along, and actually even worse than originally speculated, there is nothing positive to be gained from continuing to support the AMP project.

      The performance benefits have already been debunked given we know they were throttling non-AMP pages to make them appear slower.

      As a project it needs to die. If there are any beneficial aspects to the technology the community can fork it and allow it to be developed without any ties or involvement by Google or Alphabet.

  6. We chose to partner with Google because we believed that we had a shared vision of advancing the open web.

    Research surveys suggest a rule of thumb: the more ethically dubious the business, the more grandiose and sanctimonious its mission statement.

  7. Who thought AMP was anything but anti-competitive BS from the getgo? Any trust placed in it was misplaced. Hence I wouldn’t frame it as “losing trust,” I’d call it “belatedly finding out the truth.”

  8. So many good points here, Sarah. I think what bothers me most is that, without the willing cooperation of web designers, Google wouldn’t have grown to this point.

    We happily added their APIs. Many of us trusted them, even if we had no concrete reason for doing so. And they essentially took advantage of that trusting nature.

    Look at some of their business practices and maybe they’re not so different from any other enormous company. They simply package it in a more user-friendly way. Otherwise, they’re no better than an oil company.

  9. The one second delay for non-amp compliant ads is to ensure a quality reading experience. AMP ads are server side fetched and validated to not require subsequent client side loading. Non-amp ads have no such restrictions and can cause jank as they load, which the AMP experience is trying to avoid by delaying them a bit.

    More here: https://wptavern.com/amp-has-irreparably-damaged-publishers-trust-in-google-led-initiatives

  10. This is like asking “when did you stop beating your wife?” The question assumes as fact something that is false. I’m certain WP had no prior knowledge of Google intentionally throttling AMP ads because that didn’t happen!

    I know because I was there!

    This whole theme seems to be based on a false narrative and I’m beginning to assume there must be a reason for the false narrative. Please let your readers know why you are so willing to push a false narrative with regards to AMP.

    It’s harmful.

    Many local news publishers are relying on AMP to power syndication and new streams of desperately needed revenue. AMP as a syndication format is incredibly beneficial to quality news media publishers in general and the severely challenged local news media publishers in particular.

    Of course there are ways to make AMP better. But to say AMP was born out of some malicious or nefarious intent is a FALSE narrative. Again, I know because I was there.

    • Hey David,

      I understand your stance, but the opposition is more based around the origin of beneficiaries you are clearly pointing out yourself. It solves problems for companies like Google and maybe some publishers, although in Germany, many publishers don’t like the fact that their content is syndicated away from their sites, but have to play along as there is no way around google these days. Adding the fight over the point of contact with content. Maybe let’s leave that topic aside.

      What I wanted to get to is the notion around AMP being in any way Web Designer centric. It is not, really. It rather forces everything through a sieve to be easily digested, cache and delivered etc.
      Not only that, but it is an unwanted optimization/variation pushed onto the Web Designer or Developer to fulfill extrinsic demands.

      I actually don’t believe in some malicious intent, but there is a force weighing on the community if Google decrease something like AMP to benefit in ranking. Like the YouTube ad money, the rules around page ranking or prioritization are a real and powerful sword to wield.

      Hence, there are grounds to assert an agenda at work, even if it might just have grown and evolved over time.

    • Hey David,

      I understand your stance, but the opposition is more based around the origin of beneficiaries you are clearly pointing out yourself. It solves problems for companies like Google and maybe some publishers, although in Germany, many publishers don’t like the fact that their content is syndicated away from their sites, but have to play along as there is no way around Google these days. Adding the fight over the point of contact with content. Maybe let’s leave that topic aside.

      What I wanted to get to is the notion around AMP being in any way Web Designer centric. It is not, really. It rather forces everything through a sieve to be easily digested, cache and delivered. Not only that, but it is an unwanted optimization/variation pushed onto the Web Designer (/Developer) to fulfill extrinsic demands.

      I actually don’t believe in some malicious intent, but there is a force weighing on the community if Google decrees something like AMP to beneficiary in ranking. Like the YouTube ad money, controlling the rules around page ranking or prioritization are a real and powerful sword to wield.

      Hence, there are grounds to assert an agenda at work, even if it might just have grown and evolved over time.

  11. I used to be a “fan” of Google and keep up with their latest initiatives.
    But AMP never made sense to me.
    The work required could as well be used to just make your site faster in general.
    It didn’t take long for the bugs and workarounds to appear, making it an ever bigger mess.
    Publishers used great time and energy just to push their content out to Google, mostly to Google’s benefit, as the clicks rarely went to the publisher.
    The experience wasn’t even that good. Basic, bare bones. Publishers struggled getting their ads shown and tracking the results. Almost no branding and if not clicked to the publisher, people would hardly know where the article even came from.

    I don’t use Chrome and neither Google as a search engine. I use DuckDuckGo which is quite good. Hell, even Bing has gotten a lot better the last few years.

  12. Fantastic coverage, and the question about the performance push regarding core web vitals is very timely. I’m excited about possible performance improvements, but I would love to see more conversation about how we can avoid simply catering to the whims of a powerful company.

  13. Despite all the bad that AMP did, we should not forget that it also did some good… I don’t know what happened internally at Google, Automattic, or between the 2 of them. What I do know however, is that AMP made me think.
    One of the “restrictions” of AMP was the amount of CSS used, and a lack of support for JS in its initial versions. It made me think about the CSS and JS I was writing.
    I always disliked AMP… If on a non-AMP site I applied the same restrictions that AMP had, the result was a far faster site. But the truth is that I became a better developer because of it.
    Things like conditionally printing styles on-render for Gutenberg blocks were not ideas that came out of thin air… These things came to be because AMP was applying some tree-shaking, removing all styles for elements that were not on the page, and then inlining the resulting CSS, limiting it to a few kb.
    AMP was not a good thing. But it did use some techniques that were brilliant. It pushed people to try and do more with CSS instead of JS. It pushed us all to write better frontend code.

    A new performance team for WordPress core is being spearheaded by Yoast and Google-sponsored employees. The initial proposal is to improve core performance as measured by Google’s Core Web Vitals metrics.

    As one of those developers, I can say that I don’t really care about the “Core Web Vitals”. What I care about, is reducing the carbon footprint of the web. Since WordPress accounts for 40%+ of the web, every single byte I can save on a page visit counts immeasurably. Improving performance is good because building a website that requires downloading 4MB of data on each page load is insane. Not everyone is as fortunate to have unlimited, fast internet… And we seem to have forgotten that.

    is there a long game that serves Google’s interests being woven into this initiative? Would these employees even be aware of it if there were?

    I can’t speak for Google employees… But as a Yoast employee, I am not aware of any plans or long-games. I was given the freedom to try and improve the performance of WP because my personal beliefs of improving access to the web and its sustainability aligned with my employer’s principles.
    So far WP has democratized publishing… it’s about time we democratize content delivery as well.

  14. I for one love AMP, it seems that those who are critical of it are very vocal, and a large majority of us who like AMP and can appreciate the benefits that it brings to the web are really not so keen on being so vocal and outspoken, because we have things to do, and AMP works perfectly. And so in the zeitgeist of the domain, all that we hear are the critical voices.

    No, there are no database issues, it simplifies the site build and yes makes it load fast. I mean people on the critical side are looking for all sorts of issues and I don’t think there’s any solution that those on the critical side would ever agree to.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.