You can't help the network request if it has to be made when the user clicks but there is nothing stopping browsers from preloading my site and nothing stopping google from noting that my site could be preloaded when it crawls it. Limiting ranking influence to sites with the AMP structure is an option Google has decided to make and not an inherent restriction in the technologies at play.
The technology behind AMP is very cool mind you, I just find it being an exclusive ranking factor to be an unecessary pressure to use their technology when many other technologies could work just as well. Google is a major force in the way people make websites and they are being very heavy handed in this instance.
There's a whole host of security problems with trying to see if an arbitrary site can be preloaded. Logging, tracking, etc, not to mention more nefarious tricks like mining Bitcoin in the background.
Maybe Google could try to detect those things, but then you just end up in a cat and mouse game. A "safe" subset of html and js that can't do those bad things is much, much easier to analyze. One such subset is AMP.
(Disclosure: I work at Google on Ads, and I work with the AMP folks a bunch. Speaking for myself, not the company.)
I'll grant you that the branding/communication here is atrocious, but as I'm reading this, what I'm seeing is "They should have implemented <description of AMP>, instead they implemented AMP, which is much worse."
AMP supports a subset of standard HTML, plus a whole bunch of AMP-specific extensions. That's a significantly different thing from being just a safe subset of HTML.
Webcomponent custom elements are part of the HTML5 standard.
`<literally-any-element-name-i-want-here>` is a valid subset of html. You added the "standard" modifier, which like, I mean, WebComponents are part of the standard, so using them is still a subset of standard HTML.
If you mean "they should have limited themselves to using older HTML APIs and doing custom polyfills based on css-classes instead of element names", which is probably closer to what you actually mean, I'd ask why.
The behavior would, in general, still be the same. You'd be required to include some metadata information, you'd be restricted to some amp.js provided to you, and you'd need to use class='amp-html' instead of <amp-html>. And that would be the entire difference.
Wow, color me disabused of the notion that AMP added stuff on top of that simple requirement to allow capture of publishers by Google, I had assumed bad intent and invented fanciful scenarios of what I would do if I were an evil corporation trying to control the web like requiring people to load my script on their pages and only using my analytics library so I would have all that data for me, or maybe just create a 'standard' set of components that I control and have people use those so they have tied up money in implementing my tech and I have lock in and in order to keep their ranking in my search app they sink more and more money into doing things the way I want, increasing my capture of them.
All sorts of evil stuff I might do, but gee, it turns out all Google did was publish a document saying use this stuff that is already standardized, and leave out these parts of the standards because they can be problematic and make things perform badly, and we will rank you higher in search results. Nothing else, just rank you higher.
Now I'm really sorry I thought Google was as evil as I am likely to be when working in a group of people trying to control a market. Google is as pure as the driven - gee, I don't know what, Snow? No, Climate Change means that metaphor is soon no more, what else can be driven, hmm, oh I know, a sociopath! Google is as pure as the driven sociopath, that sounds good.
Yes. Or at least, in practice its not really distinguishable from this other than technical nits that aren't practically relevant to the overall design or what anyone complains about.
>requiring people to load my script on their pages and only using my analytics library so I would have all that data for me, or maybe just create a 'standard' set of components that I control and have people use those so they have tied up money in implementing my tech and I have lock in and in order to keep their ranking in my search app they sink more and more money into doing things the way I want, increasing my capture of them.
These are the things you have to limit yourself to. You have to limit yourself to predetermined subsets of Javascript, because if not there's no way to ensure the safety/speed/etc. of the site.
You're shifting goalposts here. Now you want the set of things you're limited to using to be broader than is possible for valid technical reasons. You're also conflating AMP and Google, which like valid, because its confusing, but again, AMP doesn't require Google anything. So all of your complaints about forcing you to use Google's analytics library or include Google's JS aren't true. Yes, for AMP (JS) to work you need to include a Cache's JS, and Google is the biggest cache, but they aren't the only one.
As for the rest of your post:
> Don't be snarky. Comments should get more civil and substantive, not less, as a topic gets more divisive.
Could you at least try to be polite.
Apart from that a lot of websites started showing an overlay on top of the AMP pages, clicking on AMP pages don't work as expected a lot of times, it has a noticeable delay between actions (scrolling/tapping).
I disliked AMP when I first started seeing it but the way it has evolved has made the experience way worse than it started with... Probably because Google also caved in and tried to cater to customisations requests from big publishers.
The first solution is not AMP. The first solution is to go back to when a web page was a "page", not a program made up of cobbled together bits of JavaScript.
Cookie preference popups, join the newsletter popups, animated or dynamic ads, and everything else stupid websites do that causes the browser's rendering engine to grind away non-stop...
The current user experience is worse than I think it ever was.
But as other posters have comments, AMP is probably intended to be a control and data tracking system first, with user experience being second or lower priority.
And no attempt to fix the slowness of the modern web will succeed without blocking ads and tracking scripts.
This is the downside of the dominant browser being made by and ads-and-tracking company.
See HTTPS adoption.
https://storage.googleapis.com/cdn.thenewstack.io/media/2018...
Great example. You just proved my point that it is possible to have positive change in large communities.
That graph shows that there's an obnoxiously large number of websites that don't support something that there's zero reason not to support.
It costs $0 and takes maybe half an hour to implement, browsers are screaming "not secure" to each visitor, and one in five websites still don't support it. "Make websites faster", on top of being vague, is way more difficult to implement.
If fast site performance ensures you get listed first, every site would get faster overnight.
However, since Google aggressively preloads most of that data while you search, it gives you the illusion of AMP pages being lightweight.
Non-AMP pages? Oh, Google will happily penalize them even if they perform better.
USA Today (582KB, first item in the top news section) https://www.google.com/amp/s/amp.usatoday.com/amp/3431466002
Vox (486KB) https://www.google.com/amp/s/www.vox.com/platform/amp/policy...
The New Yorker (565KB) https://www.google.com/amp/s/www.newyorker.com/news/current/...
I meam, why exactly are 500kb of cruft is being served to present 5kb worth of data?
So even if the AMP Pages are small, they're still much larger than the page ought to be
---
USA Today AMP page: 45 requests. 755 KB transferred. 1.6 MB resource
USA Today EU Experience: 10 requests. 209 KB transferred. 251 KB resources.
AMP version is significantly worse for essentially the same content (AMP version and EU version are nearly identical)
---
VOX AMP: 37 requests. 575 KB transferred. 1.4 MB resources.
VOX AMP not served from Google [1]: 22 requests. 403 KB transferred. 935 KB resources.
VOX non-AMP [2]: 19 requests. 627 KB transferred. 1.3 MB resources
So, AMP is worse when served from Google. And on par with non-AMP version
---
The New Yorker AMP: 129 requests (and they keep coming). 796 KB transferred. 1.9 MB resources
The New Yorker AMP not served from Google [3]: 70 requests (and they keep coming). 745 KB transferred. 1.5 MB resources
The New Yorker non-AMP page[4]: 245 requests (and they keep coming). 8.2 MB transferred. 13 MB resources.
So. The only example where the AMP page is significantly better than the non-AMP pages.
---
But the page weight is already accounted for in Google Search algorithms, and The New Yorker page should have been deprioritised from search. It's not, it's in the carousel, it will redirect to the 13MB version on desktop. Meanwhile, as Vox, and USA Today and many many many others show, the regular properly made website will not differ significantly from AMP versions.
[1] https://www.vox.com/platform/amp/policy-and-politics/2019/4/...
[2] https://www.vox.com/policy-and-politics/2019/4/10/18305175/t...
[3] https://www.newyorker.com/news/current/william-barr-goes-ful...
[4] https://www.newyorker.com/news/current/william-barr-goes-ful...
Google decided to dominate the search world, and it now underpins a huge portion of online businesses. That comes with a level of responsibility to be fair to it's patrons that in this particular instance I feel isn't being met.
Of course they can do whatever they want, it is their product, but we don't have to like it.
That sure doesn't seem to be true at all.