
Google’s AMP is a gilded cage - robin_reala
https://shkspr.mobi/blog/2016/11/removing-your-site-from-amp/
======
robertelder
I did a technical review of what I felt were the major pros/cons of
implementing AMP pages:

[http://blog.robertelder.org/adding-support-for-amp-
pages/](http://blog.robertelder.org/adding-support-for-amp-pages/)

Edit: To save you a click, here are some of the key points:

\- You can't use Javascript on AMP pages, but you can put Javascript in
iframes or substitute the javascript feature for an existing amp-component.

\- AMP pages require that Javascript is enabled.

\- In order for pages to pass AMP validation you must include the
"[https://cdn.ampproject.org/v0.js"](https://cdn.ampproject.org/v0.js") script
on AMP pages. Furthermore, I believe you are required to hotlink to the
ampproject version as I have been unable to pass validation with a locally
served copy of these scripts.

\- You can't use inline 'style="..."' tags

\- AMP uses inline 'style="..."' tags on rendered markup

\- External stylesheets are not allowed

\- You will likely want to maintain a separate AMP view and a non-amp version
of your pages.

\- The DOM structure of AMP pages will be slightly different than for desktop
pages.

I wouldn't say that I like AMP, but since the world is going mobile I figured
I should try to become and early adopter for AMP. In a way, I kind of hope
that the AMP projects gets abandoned, but if that happens then I'll have
wasted a bunch of time adopting it.

~~~
madeofpalk
Have you looked at and 'reviewed' alternatives, such as Facebook Instant
Articles or Apple News Format?

Why is passing validation an important thing for AMP? The main complaint I
hear about it is the AMP CDN, where Google caches and hosts your page for you.
If you're failing validation then they wouldn't do this, right? So you get the
advantages of a fast page without the disadvantage of Google reposting your
content.

~~~
lucideer
The main advantage of validation is prioritisation in Google's search results,
the AMP logo next to your search result on Google (which for most Google users
has come to mean "fast"), and the extra speed-up of Google's CDN.

~~~
madeofpalk
Herein lies the 'confusion' with AMP - its actually two completely different
things:

\- news distribution platform

\- framework and guidelines for making fast webpages

If you want Google to distribute and prioritise your content, you'll have to
play by their rules, just in the same way if you want Apple's help as well.

------
hannob
AMP is the result of webmasters being unable to provide any kind of reasonable
site performance. Which isn't hard. Don't include content from dozens or
hundreds of thirdparty hosts. Don't do crazy amounts of super slow javascript.

If people would do that there would be no need for AMP. The whole concept is
mostly "Google tells people their webpages suck and puts them into a cage
where they can guarantee that they don't suck".

~~~
untog
It's worth pointing out, though, that the source of a lot of this performance
drain is ads. And Google are the main provider of ads across the internet.

To me, AMP feels like a method for Google to sidestep the real issue at hand.

~~~
tedunangst
Are google ads that slow? When I look at the dozens of requests issued by slow
sites, I don't see google domains. I see every other fucking tracker,
suggester, sharer, and optimizer, but not google.

~~~
adwww
Ah, but just because you see Google ads, it doesn't mean that was all the
website tried to serve.

They probably ran a waterfall, asking AppNexus, Pubmatic, TradeDesk and 40
other ad providers for an ad at $5, $2, $1, etc. before giving up and serving
a Google ad...

------
sintaxi
I can't help but feel AMP is a step in the wrong direction and was quite
possibly a disingenuous play from Google from the get-go.

URL highjacking is harmful for the web and I can't for the life of me
understand how this project could get past the initial stages without that
drawback being understood.

~~~
hehheh
In a world where CloudFlare MITM is so openly embraced, I'm not surprised at
all that AMP is at least somewhat popular.

------
throwbsidbdk
I think everyone is missing the point of AMP. Google could have just as easily
SEO punished slow sites and had the same effect as amp. If a site was slow you
wouldn't see it in search results anyway. Nothing inherent in AMP makes the
web any faster than an optimized site.

The whole point of AMP is so that nobody ever really leaves Google. Anyone who
thinks otherwise is naïve, and it's pretty fucking obvious with how the AMP UI
is setup. People are saying "oh it's okay they'll change the UI when they
improve AMP, V2". I doubt it, the UI was built the way it is intentionally to
see if they can get away with it. "making the web faster" is just their
marketing to get everyone to buy in.

Look, Google made my phone and my web browser. They are my main source of
email, news, videos, and content. I spend most of my day using google devices
and Google software on Google sites. Now google wants to host every site in
the search results for "speed". Seem like a disturbing pattern? The internet
needs to push back or be owned by Google. AMP has gone too far.

~~~
shostack
I am concerned with how they have "nudged" sites to use AMP with the
consequence being worse mobile rankings combined with them essentially getting
final say around who gets to be an ad partner that is white listed.

As an example of where this is concerning...look at the importance of the GDN
and other exchange inventory to Google. Now look at FB trying to grow its
offsite presence with Facebook Audience Network. Hmmm...doesn't seem to be
supported by AMP tags. Interesting.

It also looks like it severely hinders analytics efforts for everyone but
Google due to the JS limitations.

As a business move it is fascinating to wTch this play out. However I really
do worry about how much control Google is trying to exert here...it is rather
unprecedented.

------
cybernytrix
As a user, I can't stand amp -- issues are 1.) no link to original site. 2.)
top banner plague 3.) weird smooth scrolling that messes with my muscle
memory.

There are two workarounds to avoid amp all together: 1.) use DDG and prefix
all queries with "!g" or 2.) visit encrypted.google.com that does not use amp.

Given that I tend to stay on a page for 2-10 minutes, shaving off 1sec is less
than 0.8% improvement. This is not worth it given the horrible drawbacks and
UX.

~~~
snappy173
>2.) top banner plague

the top banner is something that Google adds, and isn't, strictly speaking,
part of AMP.

~~~
acdha
Is there any use of AMP which isn't driven by Google? I've never seen it
referenced except in Google search results.

~~~
snappy173
Well, you can access the AMP version of the page from anywhere, not just
Google search results. I could see apps that use an in-app browser serving the
AMP version of a page, instead of the full version, for instance. I guess
we'll see?

~~~
acdha
I'm aware that it's technically possible but was realizing that, as a fairly
active mobile web user, I had never noticed AMP in use except for Google
search results.

~~~
snappy173
i could see other apps that use a native browser preferring the AMP version.
something like yelp, that lets you click through to the source page, for
instance.

------
cocktailpeanuts
Wow this is crazy. I remember PayPal used to freeze your account when they
detect a pattern they're not familiar with, and make you send a fax of your
identity and all the documents and you wouldn't be able to touch your own
money for a while.

This feels like a website version of that same bullshit process.

More and more I don't like how these "open" projects are coming from some of
the largest companies. It's a huge conflict of interest, and people should
know more about this.

It's important to realize that: The primary goal of Google AMP and the friends
is NOT to make the web better and faster.

It's to become the AT&T/Verizon/Comcast of the content distribution. Facebook
(Facebook Instant) and Google (AMP) and Apple (Apple News) want to own the low
stack distribution channels as well as the application level (facebook.com,
google.com, iOS devices) If one of these companies manage to control that
level of the stack, they can use that as their huge advantage in competing
with others.

------
velcro
AMP is of course mostly meant for articles - but we wanted to see how it did
for complex(er) layouts. Had a weekend hackathon to recode our main one-pager
for performance and SEO recently + we also did an AMP version of the page at
[http://pag.es](http://pag.es)

The AMP version of the site is (as expected) not as performant as our custom
optimised one. AMP version will load 1.2MB+ of data with 28+ requests, while
ours makes due with half of that and 0.6MB with 17 requests. Some of that is
due to AMP components that could be a bit more optimised (like we have a
hidden youtube video that launches on click - and the youtube AMP component
will load all of it dependencies on first start which is not ideal - our
custom version does this when the user clicks/launches the video).

However - the new site release did wonders for SEO. Its probably not all due
to just having an AMP version, but also just having a good mobile/optimised
site - we still landed on 1./2./3\. google search page results for some fairly
generic terms. Really surprised us - kind of shocking actually, especially
since we did little with the page before and didn't have that many inbound
links, etc...

~~~
icebraining
Comparing cold loading doesn't seem appropriate - one of the points of AMP is
requiring you to hotlink to their specific resources, so as to benefit fully
from cache, as more website get AMP'ed.

~~~
velcro
Sure it does - even if you totally ignore the fact that the same AMP page is
loading quite a bit of JS, that its almost double the size and double the
number of requests - you're assuming that all requests are cached and thats
not correct.

For the Youtube AMP component alone some of those requests are "no-cache"
cookie/ads/other types + if nothing else, its also loading the video cover
image i.e. effectively starting the video iframe in the background.

Which is as mentioned not ideal since the video is in a hidden inline popup
thats used only by 40% of the visitors. Our main page loads and executes all
of this on click/user-interaction first so ideally I'd like to be able to set
how this behaves in an AMP component too. If that loads from cache afterwards
- even better. But it shouldn't upfront and I can't influence it easily.

BTW fun fact - all popups/galleries/sliders/menus/animations on the page are
done without JavaScript - none whatsoever (excluding pre-loading large
images). They use clever new CSS techniques instead. Just for fun - we tried
to go completely JS-free, but Youtube/iframe was the only problem because it
was preloading everything on start (and we tried various hacks from various
nested display:none; stuff to switching iframes for objects, etc.). Plus/minus
Google Analytics of course.

So its quite a contrast - on one hand going JS-free, but then on another
loading an insane amount of JS for the AMPed version :)

------
ClassyJacket
AMP is yet another good idea that Google didn't test properly or think
through. As far as I can see, you can't click through to the actual page from
an AMP page, which sucks if you want to share the link or something.

~~~
oneeyedpigeon
> AMP is yet another good idea

Can you explain why AMP is a good idea? I still don't really understand it,
I'm afraid.

~~~
PaulHoule
Serving everything from one hostname means (i) you don't get 20 DNS lookups to
serve a page, one of which might hang up for 5 seconds; (ii) you can use a
protocol like http/2 to avoid TCP and SSL renegotiations; (iii) you can stop
people from loading up pages with 20MB of Javascript.

There is no doubt that AMP is fast.

The other angle is how it reinforces Google's position for advertising,
analytics, search, video and such. On one hand you could say it is "evil"
because they are a monopolist, but the status quo is so bad when ad networks
are weighing you down with multiple tracking pixels, malware service, etc.

~~~
oneeyedpigeon
I guess my question then becomes "why does this require AMP?". I mean, I can
build a site using standard technologies that doesn't perform 20 DNS lookups
or require 20MB of javascript to display. I can do it with 0B Javascript if
you _really_ want. Is AMP really about encouraging best practises rather than
introducing some new revolutionary technology?

~~~
ec109685
AMP allows google to prefetch and pre-render AMP content before a user clicks
given it can ensure the content does not do malicious things because the AMP
format is tightly controlled. The end result is that when clicking on an AMP
result, it loads instantly.

~~~
acdha
Prefetching is possible using standard web technologies and that improves the
security footing since it follows the normal browser origin policies.

The actual reason for AMP is that it gives Google control: the good side of
that is that companies have an outside check on performance — think about how
many companies exist where internal politics means that “this will hurt SEO”
will be listened to but “this page is too heavy” coming from inside will be
ignored — and the bad side is that anyone who adopts it is binding their
technical capabilities closely to Google's decisions.

~~~
ec109685
Pre rendering is not possible on iOS Safari and pre fetching is dangerous
given you don't know if the origin can support it or not.

AMP is faster than the alternative.

~~~
acdha
> pre fetching is dangerous given you don't know if the origin can support it
> or not.

That's not true unless your site already has a huge exposed vulnerability.
It's also irrelevant to the discussion of how a search engine could provide an
opt-in feature which you could choose to enable.

> AMP is faster than the alternative.

Do you have any data to support that assertion? Remember, you're replying to a
thread about possible standards-based alternatives but Google has never
implemented that, so we all we can say is that AMP is faster than not doing
anything at all. We don't have any data saying that the solution to web
performance problems is a bunch of proprietary markup and JavaScript. I've
certainly found AMP to be slower as often as it is faster, because the
proprietary markup means you have a bunch of resource requests which will be
delayed until ~125KB of JavaScript loads and executes whereas a standard <img>
tag would have started the same transfer without that delay (see e.g.
[https://www.webpagetest.org/video/compare.php?tests=161129_X...](https://www.webpagetest.org/video/compare.php?tests=161129_XR_YEQ,161129_GZ_YEC)
where the non-AMP version starts rendering over a second faster on an iPhone 6
over LTE).

As an example of how this could be different, imagine if Google simply started
aggressively using measured page-load times and transfer size with the same
weight they currently give to AMP, giving all publishers the same incentive to
reduce things like the massive amount of ad-related JavaScript they
traditionally serve, and started serving rel=dns-prefetch/preconnect/preload
hints for the top-n search results (or on mouse hover states, etc.). That
might not be quite as fast as the best-case for AMP but I suspect it would
rapidly get into the territory where the user benefit is diminishing compared
to the benefits of not dictating a restricted tech stack.

That last part is pretty important because AMP is not without cost: it breaks
the sharing UX on mobile devices, desktop users get a mobile-optimized page
which isn't as good for their devices, and most importantly it limits you to
the subset of functionality which they choose to implement. It seems risky to
push everyone towards a single company's view of how the web should work
rather than allowing independent experimentation and optimization for
different types of content and users.

------
tlrobinson
AMP should be an optimization for browsers that support it, that way:

1\. They don't have to hijack the URL. I understand the technical reasons for
this, but it's unforgivable.

2\. Browsers can provide an easy way to view the original/full content.

3\. Users can easily disable AMP in their browser if they want.

~~~
revelation
It's not like Google particularly cares for 1. I still get a ridiculous
Google-redirector URL when copying a link from the search results that has
enough entropy to uniquely identify every single atom in the universe 2^128
times over.

Despite showing the correct link in the status bar. It's a scummy dark pattern
that needs to die.

------
jc4p
@edent - what web server are you using? I wouldn't bother with any Wordpress
plugins, but if you're using Apache or something you should be able to
`mod_rewrite` pages ending in `/amp` to the same page minus the `/amp`, which
_should_ work right? Hopefully then Google will notice the 301s and catch up.

Posting this here because in the comments on the blog post he asked for any
code that might help with that, I think something like:

`RewriteRule (.+)/amp/$ $1`

might work

~~~
edent
Thank you for that. Not to seem ungrateful, but I'm wary of pasting "might
work" code onto my blog.

What if it goes wrong? What if it has unexpected side effects? What if Google
crawls it and makes things worse?

There are currently 3 variants of the above posted in the comments. I've no
idea which to choose...

I guess I'll try and hope that it doesn't make things worse :-)

~~~
jc4p
It's a very understandable worry :) Writing rules that when they fail just go
into server error logs is sub-optimal at best. The real solution would be
Google allowing per-site AMP de-registration, but that's a fantasy I bet.

This is a good article on Apache URL rewriting, if you want to go down that
path: [https://24ways.org/2013/url-rewriting-for-the-
fearful/](https://24ways.org/2013/url-rewriting-for-the-fearful/)

I believe in your use case you want to transform
`all/urls/of/any/sort/that/end/in/amp/` and simply redirect to everything
minus the `/amp/`, so the rewrite rule shouldn't be too bad to write (and
test).

I wouldn't use the "might work" in my comment since I wrote it without even
seeing if the regex works, but if you get an Apache test domain running off
your blog you can test the redirect rules in isolation before putting them on
your blog.

------
dangoldin
Earlier this year I spent some time moving my blog to AMP and so far I'm
pretty happy with the move. It's hosted on GitHub pages and I made the
decision to go full AMP (including Desktop so I never went the /amp/ subfolder
route) and allowed me to convert every existing page to AMP without having to
have a new set of URLs.

It's noticeably faster but there are a few hiccups I had to deal with - JS
needs to be in isolated iframes and getting Disqus comments took a bit of time
but in my case the performance benefit outweighs it. At the same time I could
just simplified my design without going full AMP and it probably would have
been just as quick. The biggest frustration is that if you make any CSS
changes it has to rebuild every single page since the style needs to be
declared inline rather than as a link to a CSS file.

For those interested: [http://dangoldin.com/](http://dangoldin.com/)

~~~
majewsky
I don't know what you did there, but it takes about 8 seconds on my desktop
before it displays _anything_. Talk about "accelerated".

Edit: I checked with the Developer Tools, but I have no idea what is going on
there. Assets are fully loaded within 500 ms, and then it just sits there for
another 7.5 s before rendering anything at all. (I will note that
cdn.ampproject.org is blocked by default in my uMatrix.)

~~~
quelltext
Does it get faster when you don't block it?

~~~
majewsky
Apparently yes. (Not on the same machine, but I just checked on my work
notebook where I have uBlock rather than uMatrix, and cdn.ampproject.org is
let through.)

~~~
dangoldin
Ah interesting. Thanks for bringing this up. I use uBlock but didn't have any
issues rendering it. Since I don't really care about the SEO/Google hosting it
it might make sense to just link to my own locally hosted version to avoid the
adblocking block.

------
makecheck
This experience basically ruined mobile Google for me and caused me to switch
my entire search engine to avoid it.

It is completely wrong to optimize for viewing while breaking expectations for
anything else. COPYING THE URL is very frequently the next thing I want to do,
and AMP destroys this. For example, when looking up recipes, I often create a
multi-device-sync note containing the URL, where I add a shopping list and
whatever other notes I want to make; it makes no sense to be forced to copy a
mobile-only, Google-domain link for almost every search result when next time
I might be opening the page from my desktop machine!

Another major problem is that the _only_ indication of this hijack is a little
lightning-bolt and "AMP" next to certain links. I guarantee _most_ users don’t
know what that even means so problems will be blamed on “the site I clicked”
and not “Google”.

------
f_allwein
Seems like a mixed blessing for users. I just started too realize that I'm
getting links like

[https://www.google.co.uk/amp/s/amp.theguardian.com/world/201...](https://www.google.co.uk/amp/s/amp.theguardian.com/world/2010/sep/06/germany-
extend-nuclear-power-stations?client=safari)

from Google. Sites load fast and webmasters seem to like it (1), but I think
it's a terrible user experience if you want to share the link etc. Apparently,
Google will address this someday (2).

Regarding the issue mentioned here, of course Google can’t give direct support
to all webmasters. But in my experience, the Webmaster forum is a great place
to get help as it is full of smart users (and Googlers). Then I would say
that, as I used to work for Google.

(1) [http://digiday.com/publishers/publishers-excited-google-
amp-...](http://digiday.com/publishers/publishers-excited-google-amp-traffic-
wonder-revenue-will-follow/)

(2) [https://www.seroundtable.com/google-disable-amp-
feedback-221...](https://www.seroundtable.com/google-disable-amp-
feedback-22173.html)

(3)
[https://productforums.google.com/forum/#!forum/webmasters](https://productforums.google.com/forum/#!forum/webmasters)

~~~
vuanotinv
What is the problem with sharing an amp link?

~~~
f_allwein
looks ugly, you cannot see where the link goes to on sites that shorten links
(e.g. Hacker News), and the link may break eventually, e.g. if Google decides
to change/ discontinue the service.

~~~
eponeponepon

      > the link may break eventually
    

Or, more likely, _Google_ may _break the link_ eventually.

------
ksherlock
As a developer type, I don't like AMP for a variety of reasons. As mobile
browser user...

Webmasters: you had your chance and you blew it. Your website is completely
unusable on my phone. AMP exists because of your indifference and
incompetence.

~~~
ninkendo
I feel exactly the opposite as a browser user.

AMP breaks the back button and makes it so I can't swipe to navigate back. It
puts google.com in the address bar so that I can't easily copy the link and
paste it to someone else. It puts a permanent, excessively tall border on top
of every page that I can't get rid of, making the usable viewing area much
much smaller. (Oh and that X button that looks like it would close it? That
takes you _back_ to the search results. Figure that one out.) It breaks nearly
every convention my device has for webpages and is totally nonstandard.

I really really wish google gave a way to disable AMP links in their results
but they don't listen to people like me.

~~~
iainmerrick
I realised reading these comments that I've never actually seen an AMP page in
search results.

Somebody mentioned that if you use duckduckgo and prefix your search with "!g"
(to search on Google), you don't get AMP results. That's what I do, so I guess
it's working for me. :)

------
fiatjaf
This thing breaks the internet hard. What is the meaning of an URL now?

~~~
eponeponepon
It's one of those long weird words that you see sometimes when you don't
Google for GMail like what you ought to.

Honestly, it's only a matter of time before we start getting proprietary
locators again. Remember print and TV adverts plastered with AOL Keywords?

------
Animats
Amp is like the Roach Motel, "they check in - but they don't check out".

------
cdata
Disclosure: I work at Google. Opinions are my own.

I'm surprised when I read discussions about AMP on HN (typically carrying a
negative tone regarding AMP) without anyone mentioning an obvious competing
concept: Facebook Instant Articles.

Here is an excerpt from Facebook's FAQ on instant articles:

> Rather than loading an article using a web browser, which takes over 8
> seconds on average, Instant Articles load using the same fast tools we use
> to load photos and videos in the Facebook app

Facebook has drawn a line around the open web and stamped it as slow compared
to Facebook's proprietary content delivery system. If nothing else, AMP is a
timely wakeup call for content publishers: if you like the open web, better
start producing content that loads quickly on a phone over a 3G network.
Otherwise, we will incrementally lose openness at the behest of users who will
demand the superior experience of channels like Facebook Instant Articles.

~~~
throwbsidbdk
Isn't google drawing it's own line around the open web with AMP? I mean with
AMP I'm literally browsing a site hosted at Google with a Google top bar on my
page. If a user hits the 'x' on my page it takes them back to google.

AMP is a competitor of instant articles rather than the 'cure'.

If google really cared that much about speed they would just punish slow
sites. I see amp as a land grab in cute packaging.

~~~
cdata
> Isn't google drawing it's own line around the open web with AMP?

Yes, I mean, AMP isn't the solution I might build independently. But, it is
built on standard, open web platform features. You can render an AMP article
from any source in a manner of your choosing, using the features available in
a web browser.

> If google really cared that much about speed they would just punish slow
> sites.

They have started doing this as well, I believe, by rewarding sites that are
optimized for mobile devices.

> I see amp as a land grab in cute packaging.

There is a land grab taking place, whether AMP exists or not. The territory at
stake is the growing mindshare of users who browse published content
(sometimes exclusively) on mobile devices. I would personally love to see a
more open movement than AMP or Facebook Instant Articles participating, but I
would take AMP over Instant Articles without much consideration.

~~~
sintaxi
> But, it is built on standard, open web platform features.

\- url highjacking isn't standard, or open, or a feature.

\- forcing javascript to load from a specific domain is not standard either.

~~~
cdata
Let's not conflate the text/HTML-based syntax and the distribution channel
implemented by Google. You can render an AMP document with your own
implementation of the AMP custom elements. Can I do anything remotely similar
with Instant Articles?

~~~
throwbsidbdk
The problem is that for amp pages to work with Google search, which everyone
uses, it needs to use Google's flavor.

Google should just stop pretending that AMP is any different than fb instant
articles. Yeah it gives you more syntactical freedom and you can run some
scripts in iframes, the lock in factor is the same.

Not sure why it matters that the scripts are hosted by Google, you can easily
add hashes to external scripts to guarantee they haven't been altered.

Yes it's more open than fb instant articles but both act to build a fence
around open web

~~~
cdata
That's all totally fair. But in my original comment, I tried to center my
observation on how Facebook has threatened the openness of the web with a
proprietary alternative. Is it even possible for Google to deliver the same
features without drawing a line around something? If so, how does that
hypothetical thing differ from AMP?

~~~
throwbsidbdk
Probably not. It's just the marketing that gets me. Google should say "use
AMP, a Google alternative to fb instant articles!" Not "use amp it will make
your site faster!" Which isn't true.

Worse is that users will start associating the amp icon with fast sites,
forcing everyone to start using amp or suffer lower conversions even if their
normal site is just as fast or faster. This is because google forces amp sites
to be fast, but doesn't punish slow sites in their other search results.
Suddenly this amp thing starts to look less innocent.

There is absolutely nothing stopping google from putting an icon next to fast
sites that don't use amp. They used slow sites as an artificial crisis to
market a fence they're building around the open web.

Pretty dark for the "don't be evil" google. Facebook isn't doing anything
better but at least their platform doesn't pollute search engine results

------
xg15
The criticism on AMP is imo absolutely justified, but for the current case:
Couldn't you at least solve the broken link by redirecting the AMP url to your
actual page?

Taking this a step further, you could serve a minimal AMP page that contains
just a link back to your original page.

------
TeMPOraL
All the discussions focus on AMP in isolation, but I keep wondering - is AMP
just a knee-jerk reaction to the utter absurdity of current bloat
proliferation on webpages, or is it a part of a bigger idea for reshaping the
web? If it is the latter, I'd love to learn what the idea is, so it can be
discussed in full.

------
EricBurnett
This post seems to conflate two ideas (1) AMP being an insufficient
implementation (update-ping not working, and that being an awkward pattern
anyways) and (2) AMP being actively harmful to the web ecosystem _in
principle._

(1) Comments on the implementation I don't know nearly enough to contest. It's
a new technology, and will take a lot of changes in and out of Google to get
right. It's also early days - continue raising a stink about things like this
and I expect it to get better quick.

(2) The principle of AMP leads to a very interesting discussion. The fact that
the top-level URL users go to is not the canonical URL for the page does stray
into "breaking the web" territory, at least until it's better supported in
browsers. On the other hand, as I understand it that's a technical requirement
for AMP to be able to verify the content served through it, which is a
requirement in turn for keeping AMP page quality high (in terms of latency,
etc, rather than content judgements). Which I think is the most enticing part
of AMP, and not something that should be given up lightly.

I see AMP as a possible answer to the tragedy-of-the-commons problems that
have resulted from standardizing on third party display ads for monetization,
third party scripts for analytics, etc. Giving someone else a hook into your
page that _isn 't_ incentivized to keep it fast and reliable leads to an end
state where publishers have no reason to clean up the experience on their own
sites because that'd cost them money, and because the bad experience on _every
other site_ prevents them from being commensurately rewarded for being a good
player. (E.g. adblockers affect every site equally). And the third party tech
providers have no incentive to fix things for similar reasons - alternative
providers out there would cause the same poor user experiences anyways, and
make more money from doing so and enabling them to sell to publishers better.
If we cannot rely on principled actions from publishers or tech providers, how
does the experience of the web get better enough broadly?

AMP to me is an answer to that - maybe not the best answer, but the most
viable one I've seen so far. It allows for direct control of what is/isn't
possible, and if it gains traction may have enough clout to push for some of
those better experiences that aren't arising naturally.

The other possible answers I see don't seem to be working better. Relying on
regulation seems destined to failure; user experience is too messy to craft
rules around, and nobody is placed to enforce them globally. Relying on common
gatekeepers seems to be failing - Google algorithm changes worked for a while
to incentivize page quality, but I don't think Facebook is (or should?) making
equivalent judgements about the quality of content users link to for ranking
purposes, and it seems even harder to enforce in other direct-user-sharing
sites like Twitter.

[Edit] Disclaimer: I work for Google, in Technical Infrastructure. I used to
be in Ads, though not related to AMP.

~~~
invisible
Although in theory AMP makes sense, I think the issue is actually more broad
than just mobile. On desktop, lots of people rely on an ad blocker to make
sites usable again. That mobile doesn't have a way to block ads is probably a
failure of Google, Apple and other players to allow extensions.

Google has a majority share of the first impression for ads so it's hard for
me to really understand how they can't just strong arm other advertisers and
other networks into having better ads. Maybe that's the AMP play but it's a
pretty weak appeal to consumers and (as evident from this thread) publishers.
Ad blockers proliferating are a response to this inaction in my mind.

~~~
EricBurnett
> That mobile doesn't have a way to block ads is probably a failure of Google,
> Apple and other players to allow extensions.

To be honest, I see this as short-term painful, long-term desirable. Ad
blockers make the incentives of the web worse - they mean that publishers get
punished for bad behaviour of _other_ sites. Whereas without, users make more
direct value judgements...if your site is covered in ads and a terrible
experience, I'll stop visiting it. (I'd accept arguments that 100% ad blocker
adoption could push us to a better place so we should let this run its course
instead, but when I think it through I think it more likely pushes towards
walled gardens and the death of the open web, so I'm skeptical.)

To your second point, I don't think that Google has the power you think it
does to strong-arm other ad networks, and that'd be a really dangerous thing
for Google to consider doing anyways. Publishers are often struggling right
now (especially newspapers), and so revenue is their only thought. They'll go
with whoever brings in the most money, because otherwise hastens the death of
their company. This is why I like the AMP argument - it isn't _forcing_
anyone, but it makes the argument that "if users can expect a good experience,
you'll make more money, in spite of not being able to be as free with the
technologies you jam onto the page". Yes, it's a weaker appeal, but that's
what I like about it...because it has to be predicated on _actually working
better_ , rather than about pushing people around.

~~~
jasonthevillain
> I don't think that Google has the power you think it does to strong-arm
> other ad networks

Not strong arm per se, but just having _any_ built in enforcement of technical
standards built into DFP would solve the lionshare of the problem. At the
moment, publishers have to play whack-a-mole with poorly-built creatives.

IAB's LEAN standard would be a fine place to start. (To your point about not
pushing people around, I agree, we should be talking about performance as an
industry standard, like viewability or HTTPS.)

~~~
EricBurnett
The catch here is that if DFP were to enforce technical standards to the
extent of including performance, publishers would leave en masse. What they
want from DFP (as I understand it) is hosting that just works; they don't want
anyone in the way causing some ad campaigns to not get trafficked at the right
time, or killed after serving for a while, or anything else. And worse, I
think that you'd find that a very large number of ads wouldn't comply with any
such standard - display ads aren't good, by and large. So even with a perfect
offering publishers would look at the numbers and say "you know what,
nevermind...turn the crappy ads back on." A pretty good approximation for
publishers I've found was to say "if you give them a knob between anything and
revenue, they'll turn it towards revenue." That by and large includes
sacrificing user-first principles.

So one difference to your example is that viewability is desired - it's a
direct metric that helps to approximate value, which advertisers like. But
performance is not. Users cannot generally tell _which_ ad made their browser
lag, or that it wasn't the page's fault. The best you could possibly do is to
measure long-term-value, but because any given publisher only gets a tiny
fraction of a user's time, and any single ad that much less, my recollection
is that the LTV isn't really moved at all regardless of experience. It's going
to take an industry-wide shift to move the needle here.

HTTPS is a closer comparison, except that it takes big parties again to force
the issue - it's user positive but revenue negative and lots of work. So it
comes back to the issue of who can get this change pushed through, without
some party (pubs, advertiser, or users) just walking away. Look at examples of
where/why HTTPS has been adopted if you want to see more.

AMP _may_ get to that point, we'll see, but I like it as a possibility. And
it's doing more to simply not show ads if they're taking too many resources
(with browser assistance iirc? Delay loading? Don't recall what I've read),
which is good in other ways.

Which reminds me, that's another plausible solution that I'm liking...if
browsers can be more involved in aborting rendering bad iframe'd content, or
preventing them from janking the page, etc, then the burden is squarely on the
advertisers to fix or suffer reduced impact, irrespective of publisher/ad
network. That's great, it puts the incentives cleanly where they should be. So
I'm also hopeful that browsers can push through positive results here. Doesn't
help with content badness (only latency and other such browser-measurable "bad
ad" issues), but is a great starting place. (And to be fair, I don't think AMP
solves for content badness either).

~~~
jasonthevillain
That's interesting. I've been working on the publisher side for a long time,
and we definitely want technical enforcement. (The devil is in the details.
It'd be dumb to automatically block an ad that's 5kb too heavy, but if
something is never going to serve because it has mixed content warnings, I'd
rather it get switched off and flagged to staff automatically. Otherwise it
just wastes inventory until a person notices it.) I can talk in more detail
over email if you're interested.

The browser approach is a good idea. It wouldn't even have to break anything,
just limit their allotted resources.

~~~
invisible
I hate to +1 these things but I have had similar experiences with 0 control
over the ads that were showing up on a platform. It was a single page app and
performance was a huge deal. Often ads didn't even load because of the
quality.

Maybe it shouldn't be DFP forcing things as I said, but I think if the
controls even existed for publishers it might mean that they tune things to be
pleasant for their users such that they get more impressions.

------
fny
Has anyone else struggled with getting to the original page/article in Chrome?
If anything, this is my biggest gripe.

------
tdkl
Google just place the opt-out for AMP search results in the search settings -
thank you.

~~~
jhayward
> Google just place the opt-out for AMP search results in the search settings
> - thank you.

Which means it's unavailable to people who use anonymous browsing.

AMP should be opt-in only.

------
edge17
Slightly off topic, but does anyone else have trouble loading AMP pages on
their iPhone Safari browser? Almost any AMP page I try to load is blank with a
banner on top containing the address of the page, and then my only solution is
to load the desktop version to see the page.

~~~
Veen
Content blocker problem? They load fine on my iPhone, but if you're blocking
the AMP JS library you may have problems.

