Google’s AMP is a gilded cage
shkspr.mobi
shkspr.mobi
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" 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.
BTW. Without judging whether AMP is good or bad, I'll say in this comment you just highlighted the mechanism by which many a bad thing becomes commonplace. "I wish $thing wouldn't be done, but because $market_realities, I figure I should adopt the $thing for now". Even if nobody wants $thing to happen, when many people think like this, it'll get adopted anyway, and then enshrined as the new status quo.
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.
- 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.
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".
I agree with you. My site was already fairly lightweight, but I wanted to see if AMP improved things and made a better user experience.
It made it slightly faster, but other than that, didn't create a big enough impact for me to notice.
Reasons?
* Apparently the HTML should be minified.
* Apparently I should use gzip, because 4.95kb is too big.
* The inline styles are below the content to prevent showing the user nothing as it paints. Google thinks the 594 bytes of styles needs to be in a separate request.
I think insights is pretty useless at analysing sites below a certain size threshold.
At these sizes, network latency is the biggest drain on loading a page... Which effectively means users don't notice loading times when they click a link.
To me, AMP feels like a method for Google to sidestep the real issue at hand.
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...
Google's spider uses headless chrome which runs Javascript (to index flash and Ajax content). Why can't they detect how long it takes to run your page before getting useful content?
What about just penalizing Javascript?
What about penalizing download size?
I can see why Google would do this AMP thing. It's much easier to detect fast websites through positive rather than negative evidence.
Why? Because most sites are not just a single landing page -- they have links, or tabs, or new pages, and each request could take 0.2 seconds.
So instead of requesting a new page at the time of clicking on a link, and then re-loading your entire page, you just fetch information predictively and mutate the DOM to give a feeling of <instant>, faster than even an HTML CSS page behind a CDN.
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.
Can Google just give me an option to say "I'm a big boy and I can use the internet right"?
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.
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.
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.
the top banner is something that Google adds, and isn't, strictly speaking, part of AMP.
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.
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...
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 :)
But, yes, I agree. User hostile - and there are plenty of comments on Google's product forums to support that viewpoint.
Can you explain why AMP is a good idea? I still don't really understand it, I'm afraid.
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.
If you wanted to build a mobile directory or search engine you could make your own AMP server and do something like what Google does.
Google gets more gain out of it than anybody else because of their dominance of that space, having proven monetization methods in place, etc. If the shared Google result is displayed on the Google network they can reuse the same TCP connection, which gives them an edge.
You are free to build fast pages with web technology, in fact that is what I do. Most people seem to have a hard time with it, particularly because they include a huge amount of stuff using Javascript inclusions from third party sites and this is a critical technology since this is where the money comes from.
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.
AMP is faster than the alternative.
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... 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.
- Cut off third party ad networks
- Reduce bounce rates from Google.com to outside sites
> Reducing bounce rates that are due to slow pagespeed is probably a good thing!
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.
Despite showing the correct link in the status bar. It's a scummy dark pattern that needs to die.
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
If I got my redirect working, it killed all Wordpress's pretty url rewriting. Hopefully that was just an issue in my specific case though.
If the redirect rules don't work, there's lots of Wordpress redirect plug-ins though. I've used some in the past for when a post is edited and the slug is changed between initial social media burst and finalizing. Just a redirect from the old URL slug to the new one.
A plug-in like that alongside a script that allocates all the posts on the blog then manually writes into the plug-in's database table, that might work as a much uglier workaround.
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 :-)
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/
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.
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/
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.)
Glad you liked 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”.
https://www.google.co.uk/amp/s/amp.theguardian.com/world/201...
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-...
(2) https://www.seroundtable.com/google-disable-amp-feedback-221...
(3) https://productforums.google.com/forum/#!forum/webmasters
That's not my experience. I asked about this specific problem there. All I got was uninformed amateurs saying "I don't think it can be done."
https://productforums.google.com/forum/#!topic/webmasters/U3...
That seems to be a common experience - https://productforums.google.com/forum/#!topic/webmasters/3K...
> the link may break eventually
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.
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.
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. :)
Honestly, it's only a matter of time before we start getting proprietary locators again. Remember print and TV adverts plastered with AOL Keywords?
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.
Instant Articles only works in the Facebook app, while Google wanted AMP to work on every mobile browser out of the box on day one.
This has its advantages and disadvantages, but I just can't get past the hijacking of the domain. Facebook Instant Articles does not do that.
I love Facebook instant articles because it solves the real problem in very efficient manner - no markup on publishers side, semantics only. And it delivers really great user experience - zero loading time for all articles with a "bolt" sign in my Facebook Feed.
I don't see real value in AMP for two reasons:
1. The top banner plague from google makes my experience reading articles much worse. It consumes a large part of my phones really small screen. Is there single reason why do we need it. I doubt people engineering AMP implementation in Google use it daily.
2. You still can make AMP pages which will consume tons of bandwidth, drain my battery and make me hate web developers (see ability to include external fonts). And for developers who care for their users it's not helping much, even making it harder (see other thread in this HN page). Okay, preferching might help, but what else?
I hoped Google makes things better, instead all I see is just defensive rhetorics about open web. I don't care much about how open or free software is. User experience matters. And I see that Facebook cares about it much more than Google. So sad.
My personal opinion is that publishers have a choice: step up and build these types of distribution channels for themselves - to deliver the content in a format they prefer - or else the distribution channels will be built by others and the format of the content will be dictated to publishers by others.
The real danger for everyone is moving away from standard formats that can be rendered easily in a web browser towards something completely proprietary. For my money, AMP is better than Instant Articles in that regard.
> I don't care much about how open or free software is. User experience matters.
I agree that UX is important (if not most important), but I challenge you to consider the long term implications of investing in proprietary solutions just because they make hard problems appear to have been "solved" easily. Free and open source software has compounding benefits over time that proprietary software often fails to provide. Even Apple - a company (in)famous for its proprietary technical solutions - laid most of the foundation for its renaissance with free and open source software, and continues to benefit from (and contribute to) free and open source software development today.
> And I see that Facebook cares about it much more than Google.
Make no mistake: big tech companies care most about money. There is a trap that you can fall into, especially as a technical person, where you believe that a company cares about your success in particular. No company really does. They mostly just care about money. Plan accordingly.
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.
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.
- url highjacking isn't standard, or open, or a feature.
- forcing javascript to load from a specific domain is not standard either.
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
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
Taking this a step further, you could serve a minimal AMP page that contains just a link back to your original page.
(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.
With such statement, it would be appropriate you disclose up front that your employer is Google[1].
Maybe I misread that, but for me it sums AMP up in quite a good way: It's not really about making the web better, it's about more admoney for Google, if a former ads guy has to point out he didn't work on the AMP project there ;)
In short: AMP itself is not part of Ads, but there is a group within Ads focussing on AMP - because one of the biggest blockers to AMP adoption is (was?) getting ads supported within the model.
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.
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.
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.)
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).
The browser approach is a good idea. It wouldn't even have to break anything, just limit their allotted resources.
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.
Mobile ad-blocking works just fine for me (uBlock on Firefox for Android).
As a buy side guy, I'm worried that this is venturing into anti-competitive monopolistic territory if left unchecked. what are the alternatives for publishers? Don't use AMP and go out of business as your mobile traffic is slowly choked off?
Don't get me wrong, I think publishers dug their own grave here, but this is not the internet I want as a user and as an advertiser. No one company should be able to exert that much control.
Which means it's unavailable to people who use anonymous browsing.
AMP should be opt-in only.