Google’s AMP is a gilded cage(shkspr.mobi)
shkspr.mobi
Google’s AMP is a gilded cage
https://shkspr.mobi/blog/2016/11/removing-your-site-from-amp/
129 comments
Thanks for writing the review, it's a summary.
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.
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.
I get it though. Because while I dislike many things about AMP (mentioned elsewhere in the comments here), my non technical friends and family don't seem to rely on the functionality that's getting hosed. They don't actually ever look at the URL bar for example (incidentally may explain their propensity to fall for phishing attacks).
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.
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.
I have implemented both AMP and Instant Article "views" for a website and boy is the latter a bigger pain in the ass. The format is way more restrictive than AMP. Whereas the latter allows for nested lists, columns, or nested pictures Instant Articles require almost everything to be linearly placed on the top level. So unless your source format has a similarly simple structure you will have to think about ways to transform it down to that. Then, documentation is missing all the crucial details, so I ended up sifting through FB's SDK internals, which still ended up not covering all the issues reported by the web editor. Also, the only way to visually test the output is via the Page Manager app.
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.
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.
- 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.
The AMP only js, hot linking and non-local copy is part of the cache magic that makes it work so I wouldn't expect that to change.
So have we gone full circle on turned html into a basic document structure? I thought the next cycle would have been in json.
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".
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".
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.
To me, AMP feels like a method for Google to sidestep the real issue at hand.
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.
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...
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 doesn't force you to add ads to your site, though. It's disingenuous to suggest that it's the ad provider's fault that you wanted ads on your site.
Nor does the pusher force his marks to start smoking his crack.
I don't disagree with you. However, I think the best solutions almost always address root issues, so I'd much rather Google more heavily penalized slow sites. That gets to the heart of the issue without harmful side effects. AMP does neither.
The solution is very simple.
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?
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?
Websites already can detect whether the client on the other side is Google's spider (either by checking for the well-known IP ranges, or by looking at the User-Agent). So they could supply a fast, cached version to Googlebots, and thus appear faster than they are.
I can see why Google would do this AMP thing. It's much easier to detect fast websites through positive rather than negative evidence.
I can see why Google would do this AMP thing. It's much easier to detect fast websites through positive rather than negative evidence.
That's cloaking, and doing much of it will get you severe penalties.
Yeah you'd think that isn't very hard, but time has proven that we are quite incapable of writing websites with sane amounts of ads, trackers, and JS libraries.
How much of AMP's speed is coming from re-hosting content on very very fast CDNs with edge nodes everywhere?
I would say that JavaScript can also make <some> aspects of your site faster than pure HTML CSS.
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.
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.
[deleted]
(I'm the author of the blog post)
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.
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.
According to Google PageSpeed Insights, your speed scores are 59/100 for mobile and 40/100 for desktop. The "optimize images" section says there are 1.3MB of image optimizations to do. That's just the image bloat, not the image content, and it's just one of the improvements to make. If you want to make AMP go away, make slow webpages go away.
https://developers.google.com/speed/pagespeed/insights/
https://developers.google.com/speed/pagespeed/insights/
Interesting. I put my own blog (link in my profile) into there, and it scored only 90/100 on mobile. Google now wants to talk me into enabling compression and caching on a website that is literally 4.98 KB large (including all assets).
I got 91/100 mobile, 90/100 desktop for a site that is 4.95kb.
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.
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.
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.
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.
In a world where CloudFlare MITM is so openly embraced, I'm not surprised at all that AMP is at least somewhat popular.
Yeah if I wanted to use some crappy reader I would have installed it. It's not just a website issue, it's a pain for users too!
Can Google just give me an option to say "I'm a big boy and I can use the internet right"?
Can Google just give me an option to say "I'm a big boy and I can use the internet right"?
Added bonus is the damage being done to Google's credibility. A number of the fake news sites now appear as being "google.com", due to the funky hosting approach of AMP.
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.
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.
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.
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.
+1 on this one.
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.
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.
>2.) top banner plague
the top banner is something that Google adds, and isn't, strictly speaking, part of AMP.
the top banner is something that Google adds, and isn't, strictly speaking, part of AMP.
Is there any use of AMP which isn't driven by Google? I've never seen it referenced except in Google search results.
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?
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.
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.
I get AMP pages via the Facebook app quite often
Those are Instant Articles - Facebook's version of AMP, but not AMP itself.
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.
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.
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
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...
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...
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.
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 :)
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 :)
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.
On some AMP sites I see "click here to comment" which takes a user back to the main site.
But, yes, I agree. User hostile - and there are plenty of comments on Google's product forums to support that viewpoint.
But, yes, I agree. User hostile - and there are plenty of comments on Google's product forums to support that viewpoint.
> 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.
Can you explain why AMP is a good idea? I still don't really understand it, I'm afraid.
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.
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.
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?
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.
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.
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.
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.
AMP is faster than the alternative.
> 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... 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.
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.
It is a syndication format.
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.
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.
Encouraging? No. Enforcing.
[deleted]
It's just fast. It loads the page damn near instantly. Similarly to facebook Instant Articles.
I don't really understand why it's not done as a typical content-negotiation thing. Perhaps there's a good reason but since my first query of why they were doing something wasn't valid HTML and the reply was "O(fun) is important"...
Perhaps who ever came up with it, an engineer, had some good ideas, and then when Google executives took a look they said wonderful here is an opportunity to:
- Cut off third party ad networks
- Reduce bounce rates from Google.com to outside sites
- Cut off third party ad networks
- Reduce bounce rates from Google.com to outside sites
I think AMP is the wrong solution, but it does support quite a few third party ad networks:
https://www.ampproject.org/docs/reference/components/amp-ad
https://www.ampproject.org/docs/reference/components/amp-ad
> Third party ad networks can transact on AMP pages. (http://rubiconproject.com/press-releases/rubicon-project-lau...)
> Reducing bounce rates that are due to slow pagespeed is probably a good thing!
> Reducing bounce rates that are due to slow pagespeed is probably a good thing!
Of course you can't because now you just share Google's AMP link and they can keep harvesting data...
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.
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.
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.
Despite showing the correct link in the status bar. It's a scummy dark pattern that needs to die.
@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
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
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 :-)
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 :-)
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/
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.
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.
Yep, I just posted almost exactly this on the blog.
The only thing that worries me about it is I haven't used Apache for years but I distinctively remember the last time I used Apache + Wordpress I failed to setup redirect rules that would keep my blog functioning but also let `/resume/` redirect to `/resume.pdf`.
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.
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.
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/
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/
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.)
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.)
Does it get faster when you don't block it?
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.)
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.
Wow, the pages on your site load so quickly they're finished rendering before I even start reading the article. Thanks for sharing this. Very cool.
Yea - that was my first experience using it for some of the news sites and I ended up spending a weekend redoing my entire site to do pure AMP for desktop as well. The general idea of AMP is to avoid forcing a "rerender" of the DOM so it tries to do as much processing beforehand in order to only render the page once. This is why you have to specify the CSS inline and associate dimensions to each image.
Glad you liked it!
Glad you liked it!
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”.
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”.
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...
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
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
> the Webmaster forum is a great place to get help
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...
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...
What is the problem with sharing an amp link?
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.
> the link may break eventually
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.
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.
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.
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.
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. :)
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. :)
This thing breaks the internet hard. What is the meaning of an URL now?
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?
Honestly, it's only a matter of time before we start getting proprietary locators again. Remember print and TV adverts plastered with AOL Keywords?
Amp is like the Roach Motel, "they check in - but they don't check out".
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.
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.
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.
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.
> 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.
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.
> 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.
- url highjacking isn't standard, or open, or a feature.
- forcing javascript to load from a specific domain is not standard either.
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?
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
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
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?
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
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
[deleted]
[deleted]
If Facebook was the search engine and could do what Google's search results do for AMP pages for their own offering, you'd probably see a lot more complaints about it.
I work at media company, we have a lot of traffic from both search engines and social media. We have implemented both AMP and Instant articles from day 1 they were introduced.
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.
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.
> I hoped Google makes things better, instead all I see is just defensive rhetorics about open web.
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.
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.
The idea of a more open version of Facebook Instant Articles is great, it's the implementation that bothers me.
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.
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.
What loads faster than straightforward clean basic HTML? The answer to speed issues is dialling back on fancypants javascript, not buying into corporate giants' content vaults. IMHO, obviously.
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.
Taking this a step further, you could serve a minimal AMP page that contains just a link back to your original page.
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.
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.
(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.
> AMP to me is an answer to that
With such statement, it would be appropriate you disclose up front that your employer is Google[1].
[1] http://www.thelowlyprogrammer.com/
With such statement, it would be appropriate you disclose up front that your employer is Google[1].
[1] http://www.thelowlyprogrammer.com/
My apologies. I work at Google, used to be in Ads (not AMP), these days I'm in Technical Infrastructure.
What is your view on the control Google is exerting over the ad ecosystem here? It is pretty noticeable how the Facebook Audience Network is not an approved network. What about all of the third party analytics providers? Seems a bit lopsided if Google gets all that data and nobody else does, no?
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.
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.
>I used to be in Ads, though not on AMP.
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 ;)
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 ;)
You read correctly, but it also doesn't tell the full story. I've edited to be "not related to AMP" to try to convey this better.
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.
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.
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.
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.
> 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.
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.
> 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.)
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.)
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).
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).
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.
The browser approach is a good idea. It wouldn't even have to break anything, just limit their allotted resources.
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.
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.
> That mobile doesn't have a way to block ads is probably a failure of Google, Apple and other players to allow extensions.
Mobile ad-blocking works just fine for me (uBlock on Firefox for Android).
Mobile ad-blocking works just fine for me (uBlock on Firefox for Android).
Has anyone else struggled with getting to the original page/article in Chrome? If anything, this is my biggest gripe.
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.
Content blocker problem? They load fine on my iPhone, but if you're blocking the AMP JS library you may have problems.
[deleted]
They load fine for me, but look absolutely terrible. A large bar at the top of every page, and Safari's native collapsing of its top and bottom bars is disabled. Usable screen real estate is reduced massively.
Content blocker problem? They load fine on my iPhone, but if you're blocking the AMP JS library you may have problems.
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.