"It also has under development a Web Share API that would allow AMP viewers to pull the original URL into the native sharing flow on the platform, instead of the AMP Viewer URL."
Holy Moly, this is a huge amount of rigamarole just to support a degraded experience that helps ONE company do ONE thing in order to make further lock-in and profits in ONE way. It's hard to believe that any company would ever invest this amount of technical effort on a flawed product offering -- unless of course, it was one company with enough damned vertical integration to make it possibly worth their while.
I like AMP over publishers' own formats, which I have to put into Reader mode to make, well, pleasantly readable. I don't like AMP's implications. But I don't think your rendering is fair.
And I still visit them! POLITICO, The Information and others have me at their sites every day. Other publications, e.g. the Washington Post or Wall Street Journal have me Googling for AMP versions.
Note that my main search engine is Duck Duck Go. For me, Google's doing something meaningfully helpful with AMP.
If you’re really “googling” for AMP versions I recommend you should get the “AMP Validator[1]” extension. Aside from validating, it parses the <meta> tags on current website and lets you click-through to go to AMP version.
I use ddg for search. I like it but it is a hassle to have to toggle safe mode every time. I wish they had a url/alternative to toggle this literally every browser load.
This appears to work. The "settings" tab appears to say that safesearch is on but this overrides it. Not sure if for the session or just a oneoff but nice to know and gets the job done.
Going to check out some other "bangs" now im aware.
AMP is not the problem - the AMP cache is pure evil and if it wasn't for Google forcing it on people through their SERPs there would be no reason for Google to add it or have to work around it...
I want to visit publishers own sites and not weird walled Google land.
You present no real argument rather than calling it pure evil. It loads fast, ads and analytics go where they're supposed to, and now the URL issue is mostly gone too.
For users, it's basically seamless benefit with no draw backs.
For developers, yes it takes effort but a lot of it is done for you, and you also inherit this huge cache, which you call evil but in reality, costs quite a lot of money and you're getting for free.
It's easy to call something "evil" and completely dismiss all the huge benefits of a technology, but I'd like to hear what exactly are the remaining issue.
The AMP team has done their best to one by one address anything that has come up.
The "press close to go back" idiom you've invented out of thin air is terrible.
This is a solved problem. We already have a button for going back and it works swimmingly.
Even my grandmother knows that the "X" gets rid of annoying overlays (usually ads) so she can properly view the content she was trying to get to in the first place.
Google maps for iPhone is incredibly confusing when it uses "custom chrome tabs". Unlike almost every app that hands off to a browser application. When in a "custom chrome tab", I want to go back maps, so I hit the home button. Because that's how you switch apps, but wait, where is maps? Oh I'm in maps. I don't see how this could user test well when it's an anti pattern to the device itself.
Did the team think eliminating a banner or frame that wraps enclosing content was not MVP material? I'm glad Google has now made this available, but I was shocked - and unhappy - when I first realized AMP did not originally have it.
Since I do not stay up to date with the latest from Google all the time, and didn't even know AMP was a thing until I encountered it in a production google search one day, I had no chance to offer feedback. I imagine many iOS developers, who must be focused on native app things rather than Web-based things, would be in a similar boat; we would be happy to provide feedback, but I don't know how I would have even been asked for feedback, let alone have discovered that something like this was coming so I could proactively make a comment.
I hate it for custom tabs too. But what I really hate is the way AMP hijacks scrolling and page navigation. It totally breaks the feature of Android Chrome that allows you to quickly search a selected word by swiping up from the bottom. Have you tested the interaction of AMP with that prominent Chrome feature? It's symptomatic of the way AMP breaks web assumptions.
Appreciate you sharing that, good to hear it's under consideration.
More cynical me might say that rolling out the 'X' with that behavior, though, gets the conversation to be about fixing the banner...versus removing it altogether.
What is the URL to the accompanying article? This screenshot seems disturbingly effective, I'd like to see the rest of the flow. I wonder if the scam breaks down once you click the link or if it would be very hard to tell it's fishing even to a trained eye.
Well, because the implementation uses google urls, right? I assume they could have asked users to create amp.theirdomain.com CNAME records and upload appropriate certificates, right? Or the solution that cloudflare is using, or?
Ahh, I finally get it. An intentional walled garden that's a little bit open for now. I'm in the pot, and it's not terrible yet, but you just barely turned on the heat.
I assume it ends with everything in the serps being preloaded. And the only things in the serps being compliant content.
That language is misleading: only AMP articles are eligible for "Top Stories" placement, which means non-AMP results are completely excluded from the most prominent ranking on SERPs.
AMP may not be used as a ranking factor within each class of results, but it absolutely creates two distinct classes of results, where AMP is given priority over the open Web.
You're right in that I really shouldn't be directing that at you. I believe that you, personally, are trying to do the right thing. Apologies for the snark.
However, I believe the Google devs behind Froogle also had good intentions. They provided a framework to make product pages easier to consume for Google. They provided a real incentive for publishers to conform to that standard. They got nice placement in a carousel, cached display of product images, and so forth. Then, later, well...
Edit: And whatever the technical reason for the google urls, it does open up possibilities for the future that aren't desirable. It's a dangerous precedent.
None of the benefits come from the "evil" part. You could get the same from just enforcing validation, without routing everything through google CDN, cloaking URLs and breaking the UI.
The complete forking of HTML for primarily google search traffic will do more harm than good.
HTML is already fast. Google could've used search rankings to factor in site speed and forced many sites to become much faster in a few months, instead of now requiring more resources to maintain an alternative version just for them. Also 90% of the ads on the web are served by Google's own Doubleclick for Publishers, one of the slowest ad servers available.
Search rankings and the resulting traffic are a priority, changes would be made quickly. AMP pages were rolled out within weeks as well, but all that time and effort could've been spent on making the universal HTML page much better.
Lol you haven't worked with may real sites in the wild around 80% of the ones I have worked with need the CTO to tell the developers to pull their socks up or your all on a PIP
What? What are "real sites"? I'm in the adtech industry and know execs and devs at all the top publishers. Revenue/traffic issues are at the top of the list. They don't sit around doing nothing all day.
Regardless, resources are always constrained and working on AMP means not working on the standard (mobile) HTML version.
These tricks have always been the bread and butter of spammers and scammers: Make users think they have clicked through to NYT when they are actually still on your site. Show NYT's content on your own site in an iframe.
Except NYT put their content there and has near full control of it. It's just hosted (and paid) by someone else. It's just like you using my server as a mirror. You can take it down or edit it at any time you want. So your example makes no sense.
This is a mutually beneficial setup. Google provides fast servers all across the globe for free and includes it in the AMP carousel. There's value both ways, and user gets a much faster experience.
Yes, there are a couple UX that are a bit rough, but looking at this change, it seems like they are actively working to improve it.
proof it is evil: a site that doesn't support amp but is as nimble/fast and have Datacenters with lower latency to their readers than google, will still be punished (on Google's serp) over a site that has a crap website but gave in onto amp.
I think it might be that the technical team behind the AMP has good intentions but they are so focused on the perf/UX that they can't see the bigger picture about creating walled gardens, punishing sites from outside it, and other confusing things.
It's not the first time you
could see that googlers live in a bubble and need a strong criticism from external world to see some problems. Google != Internet (though it's a big subset)
> The fact that there's a list means that some are not on it, which means that there is a gatekeeper.
It's not a whitelist, those are just the pre-written supported analytics packages. Scroll up on that page. It sends configurable requests to an HTTPS endpoint based on the configuration you provide.
This. What is the process to be added? Does Google have sole control to approve and revoke access to that list? Does it place an unreasonable burden on ad tech startups that might one day be viable competitors to Google's own offering? How much will it hinder FB and their attempts at rolling out a GDN competitor?
1. Sign a Contributor License Agreement granting relevant copyright and patent licenses to Google so they can redistribute your contributions to AMP. You also give Google an unrestricted right to use those patents and copyrights in any of its projects, not just AMP.
2. For ad networks, submit a pull request according to /ads/README.md
3. For analytics providers, submit a pull request according to /extensions/amp-analytics/integrating-analytics.md
> Does Google have sole control to approve and revoke access to that list?
> Does it place an unreasonable burden on ad tech startups that might one day be viable competitors to Google's own offering?
The work of the pull request does not seem particularly burdensome, however, if AMP successfully replaces the Web, then it may be prohibitively difficult for new startups to gain enough traction to merit inclusion in AMP's whitelist.
> How much will it hinder FB and their attempts at rolling out a GDN competitor?
AMP's legal and design constraints may limit Facebook's ability to innovate in that space, however, I'd be shocked if Google excluded Facebook from the amp-ad whitelist. The AMP project has been very willing to accept pull requests from established ad networks. They also provide a bespoke amp-facebook tag for embedding Facebook content within AMP documents, so there's some indication of cooperation.
Do I recall correctly that you are a Googler working on AMP? Or am I mistaken?
Regardless, the questions were hardly rhetorical--I'd really like to know, and the other responder answered some of the questions with answers that confirmed some of my concerns.
Don't get me wrong...I think parts of what Google is doing here are solid and admirable. Publishers screwed the pooch and something had to give. But that doesn't mean Google gets a free pass on the strategic pieces of this they are clearly trying to set up and what they've done to date. The questions are valid and if you feel they are unwarranted concerns, I'd love to learn why you think the concerns are overrated.
I'm looking to provide website integrations including analysis for publishers in a new way that AMP doesn't support. Embrace and extend really screws up my idea here.
Speaking only and solely for just myself, I do not care whose site I read the material on. I just want it presented in a reasonable, readable manner. A number of publishers seem to struggle with this.
I think the fact AMP (cache) was at least initially broken for lots of people is very concerning; next there is duplicating and breaking pieces of the web (links!). In my opinion the AMP cache should be opt in then quite a few of my concerns go away.
That's what I was doing, because I hate scrolling on AMP pages.
However it also made Google useless. I may see an interesting page, but then notice that it had the AMP stamp, and no (visible) way to get the non-AMP page.
AMP made Google useless for me. Then I discovered DDG. And now I use DDG as the default search everywhere, because I get more relevant results than with Google! So I guess I should thank Google for ruining their search with AMP and opening my eyes to alternatives.
The issue is that google has been pushing these slow, bulky pages to the top of their results, then they swoop in with AMP to fix the problem. The problem AMP is trying to solve is very real, but the answer isn't to consolidate things further into google's ecosystem.
If we were able to provide quick and light pages with an equivalent experience to AMP and have these pages receive the speed and SEO boosting which AMP pages enjoy, that would be fair.
Currently, because the New York Times' website is overloaded with ads and bullshit, Google takes it upon themselves to identify "accelerated" sites and penalising everyone who doesn't implement AMP regardless of the speed of their site.
same boat; duckduckgo + safari has been working really well together. I set the custom theme to hide the search bar in the page because I just use the address bar, and bangs have been really useful.
AMP is built on WebComponents, an open HTML5 platform. Google's AMP Cache service isn't even exclusive as Cloudflare offers one as well. What "lock-in" are you talking about?
As for a "degraded experience" that's subjective, but users seem to far prefer it.
If I can't get from the search engine to the source page, that's a degraded experience. If I can't copy-paste the url but there's some ridiculous browser-defined JS method for inserting whatever the site host says the link is into my clipboard, that's a degraded experience. And we'll see further degraded experiences as Google turns "We screwed up web linking!" from a despised practice into a first-class, browser-supported practice.
The Google AMP viewer/cache is how AMP works in reality. Google has indicated that they are not willing to turn the cache off so it's fair to evaluate AMP in that context.
I don't see anything in AMP syntax to turn off the cache or choose which one is used. For links coming from Google search, Google's AMP cache will be used.
It's the same way you get any page into Google's search results. You can either wait for it to be indexed, or submit it manually. As long as you're supporting the protocol, there shouldn't be a problem. AMP pages have a custom attribute in the <html> tag that lets Google distinguish them.
You can also link your pages explicitly, as described here.
My understanding is that this markup will trigger Google to add the page to their own cache and present a link to the page in their cache in the search results. (The search result pointing to "google.com/amp/...", the page showing the infamous header, etc.)
I don't see how you can use that to get other caches (or even just the original AMP page) into Google's search results.
(Sorry if I'm mistaken though)
> The cache acts as a CDN to improve page speeds, but isn't a requirement for indexing.
How, as a site author, would you control that?
Is there a way to use AMP but explicitly opt-out of caches? I'm not aware of one. (Short of deliberately violating the AMP spec, but then you can't really say you're using AMP anymore)
By having the "desktop" version of the site (which has a high PageRank) point at the AMP version of its pages using rel="canonical", perhaps? (And then the AMP version could redirect desktop viewers back to the desktop site.)
What do Web Components have to do with anything? This seems like reading "Apple's App Store encourages lock-in and provides a poor user experience" and replying "The App Store is built on open standards like HTML, HTTP and URIs." None of that is untrue, but it's essentially talking around the point.
The criticism of AMP I keep seeing is that "because it uses weird HTML, it must be proprietary and designed for lock-in". But because WebComponents allow you to extend HTML by introducing new elements, it's actually completely standards compliant in HTML5.
Based on the parent comment's criticism that it's designed for "lock-in" (without any elaboration), that's the argument I was addressing.
Google, and solely Google, control what tags are allowed on AMP pages, and thus what advertising and analytics companies are allowed to compete on AMP sites. AMP also requires that every page depends on external JavaScript sourced from Google, which can explicitly change without notice, and thus can't be audited and locked via SRI hashes.
These points of centralization and control are antithetical to the premise of the Web as an open, inter-operable, democratic medium.
You could also serve the JS from your own domain if you prefer. Similar to Google's cache, it's something available as an option to you.
Regarding the Amp standard, that is indeed something controlled by Google. Particularly as it pertains to the SERPs. But because it's open you also have the option to fork it, or write a completely different implementation if you desire.
If you'd like to modify Amp but still stay within their standard, you can submit a PR as well. It looks like about 75% of PRs are merged.
> "AMP is an evergreen JavaScript library. We will not allow users to lock themselves into a particular release."
Which completely precludes using SRI.
Further, pages serving their own copy of the JavaScript "won't be considered valid AMP," and thus would be ineligible for the placement benefits afforded to AMP pages in Google results.
AMP's governance is not similar to HTML's. Changes to HTML require consensus between mutually competing browsers, while AMP is a single-vendor land-grab. That consolidation of power threatens to return us to the dark ages of Microsoft's sole dominance of the de facto Web.
>However, there has been some misunderstanding about how AMP works. One widely circulated blog post written back in October claimed Google was stealing traffic from publishers via its AMP pages.
I am really happy to see this change, as the author of said blog post :)
> But that wasn’t true. Google does display the AMP URL in the search results, which serves up the page content from Google’s cache, but the traffic remains the publisher’s, and the content is served from the publisher’s site.
So which one is it? Does it server content from Google cache or from publisher's site ;)
I received the same sort of self contradicting response from Cloudflare. Their AMP bot mirrors and rehosts any pages one of their subscribers with AMP enabled links to. And their FAQ is so badly written it seems like english may have been their second language: https://support.cloudflare.com/hc/en-us/articles/11500063530...
>Will Accelerated Mobile Links if the AMP links are pointing to content publishers who are not part of Cloudflare customers?
>Yes. Only the discovery site (the website that has the links to AMP content) needs to be a Cloudflare customer.
When I saw their AMP-bot in my server logs I emailed them about this. 2 weeks later I finally managed to talk to a human. That was about 4 days ago and they still haven't responded. If you're not a Cloudflare customer they don't care that they're re-hosting and serving your content.
Yeah. After I saw the bot I added it to my robots.txt and I blocked all of Cloudflare's IP ranges to the server. But the bot had already come and gone. And the email I'm waiting back on from Cloudflare is about what to put in the robots.txt since it's not on the FAQ page. As of right now I'm trying,
So if I have AMP on my site and a user clicks an AMP link, does my web server record a hit? That's what I care about, since I use traffic stats to negotiate deals with sponsors. I don't run third-party (even Google) ads on my site, it's all native "sponsored content", so making sure traffic is recording correctly is pretty important to me.
The first question I hear when I start a conversation about a sponsorship is "how many hits did you have last month" and the second question is usually "how many hits do your sponsored posts usually get?". I need to be able to answer those questions, and prove it too.
The server itself doesn't (you don't get extra load), but analytics is forwarded to you. So you can still get the numbers you need to convince the higher ups, just not directly from your server logs.
At first my distaste for AMP has been as a user: broken inertial scrolling, wasted space, and broken links.
But as I learn about it AMP becomes even more distasteful. Waiting for an intermediary to forward analytics to you is horrific.
What's going on at Google these days? Everything about AMP sounds like a bald-faced attempt to destroy the web. At every point there are horribly unjustified architectural decisions that hurt the web but also help Google.
which discounts people who use various content blockers specifically to stop intrusive analytics. these seem to be becoming more popular, so it's only going to be more of an issue to measure traffic
Does it only forward analytics using Google Analytics? If I use other forms of analytics, anything from Jetpack to AWStats, it sounds like I'd be missing out on recording traffic.
Most of the negative feedback I've heard is because it makes it very difficult to bypass amp on mobile (impossible?) and, yes, copy the URL of a google result without linking to google.
Since the #1 cause of latency I experience is waiting for ads to be fetched from a publisher's ad network, I'm pretty sure AMP would not work at all if it worked this way.
I bet "traffic" here means clicks counted by AdSense, so you still have to pay for a click even if the user never really visited your website ;)
In any case, google is just trying to copy Facebook Instant Articles here. They want people to stay within the walls, because they realized they make more money that way.
what is the market share of adwords things (my understanding this is mostly going to be people offering services) that is impacted by AMP? An ecommerce site won't support AMP so won't be affected, and are news sites and blogs going to be using adwords to advertise their news and blog offerings that much?
E: (and then does it even matter if you're ads are still shown on your AMPed site so you get paid per hit?)
Yes. My understanding from conversations with those in the know, and our limited testing at AMP launch, is that you treat the CDN as a proxy. All the downsides of losing visibility to your domain and none of the upside from offloading traffic.
That being said, we did notice some single digit percentage traffic bumps when we rolled out AMP, and it felt really good telling the hordes of product/business people that I literally couldn't add the dozens of analytics scripts they wanted.
So, I still need to take an extra step to view the original link and then click again to visit it. Why not just make the entire top banner a clickable link to the source article? My browser already shows the title of the page separately.
The whole AMP / SERP interaction is such a headache. They already insist on us having structured page content to source previews from, the last thing I want to do is write more quasi-semantic markup that just repeats what my original source code already states. Get out of my way Google.
To share the original link, to read more posts by the author, to visit the publication's home page to see what else they publish, to use their comments section which is not yet supported by AMP...
Do you share links before visiting the article? With this change, it seems like sharing the link will be the same amount of clicks.
Same goes for reading more about the author. How often do you do that, and do you do it before you even read the article?
For visiting the homepage, almost every AMP page I go to these days as a big logo at the top linking to their (real) homepage, so there's 0 difference for the user.
The only valid one is comment section. I just tried a few articles, and they seem to have a button which redirects to the real website. I think that's a fair compromise. Honestly most article sites do this anyway, load the comments after a click.
> Do you share links before visiting the article? With this change, it seems like sharing the link will be the same amount of clicks.
Before today, here's what it looked like:
Real web:
1. Click on Google search result
2. Read article
3. Click share and get real URL
AMP:
1. Click on Google search result
2. Read article
3. Click share and realize that you're on an AMP page which is broken for anything other than mobile web browsers
4. Either go back to the search results to find the non-AMP URL or navigate to the publisher's site and use site search find the real URL
5. Share the real URL
As of today, Google has made this a little faster but it's still an extra step:
4. Click on the small link icon in the header to display the real URL
5. Share the real URL
That's still considerably worse than the standard web experience. The only reason anyone is defending this is because it's associated with Google.
Absolutely, for example if I've read the story before and I'm just googling it now to reference it.
Furthermore, I care not that it is the same number of clicks, I care that users can access my website in a way that conforms to their expectations for the rest of the web. That's the crux of my problem with AMP. If it was everything except the page cache it would a lot better.
I want the AMP page because the original page is usually an awful user experience. If websites served up fast webpages I wouldn't want AMP. But in my experience browsing news on AMP pages has been faster and better in nearly every respect.
We wouldn't need AMP if the average website experience didn't suck. It's unfortunate that most websites cannot do this[0] without Google forcing them to, but that's the world we live in.
> The issue is that google has been pushing these slow, bulky pages to the top of their results, then they swoop in with AMP to fix the problem. The problem AMP is trying to solve is very real, but the answer isn't to consolidate things further into google's ecosystem.
The original page is what I wanted, originally. AMP has been a bad user experience as evidenced by the fact that this news story is near the top. AMP just boxes the user in, to the point of frustration.
My news workflow is: open news.google.com and then open-in-new-tab the news stories I want to read. Then I can read the loaded pages later or offline. AMP's JavaScript hijinx break open-in-new-tab or accessing the original page's URL.
Literally the only reason to use google. It just happens to be useful to click into the URL most times, but finding the URL is what matters. I can fill in the rest of the usability myself if I really want it.
Also, if I ask for an orange and I'm handed an apple, I'll stop asking you for anything.
Conversions, and time on the site, matter. Becoming a one-hit-wonder at most, is a broken practice for the way the business side of most websites functions.
"One widely circulated blog post written back in October claimed Google was stealing traffic from publishers via its AMP pages. But that wasn’t true."
I suspect the writer didn't really look into what the publishers were saying. AMP shoved a UI element at the top of your content that, when you interact with it, goes back to Google.
End users already know how to use a back button. So, adding another one, without being clear about what it was, would certainly create more traffic to google, and fewer "second pageviews" of your content/site. Google knows that the top portion of the page is the most valuable.
AMP is really ridiculous. I tried a top article from mobile.nytimes.com via AMP (google link) and direct link. The AMP version takes more than 3 times longer to render above the fold with a 3g regular throttling and cold caches, while the direct link was done in <2s. Chrome doesn't even record enough frames to show when the above the fold content is visible. With warm caches the render performance difference is roughly the same. Wasn't AMP ment to help with that? Superior client side rendering and top notch caching?
So basically they just add a button on the already obnoxious banner on top of the page?
This article also claims that the speedup is partly due to loading the content in a hidden iframe on the search results page. So it's potentially using more data in order to be perceived faster?
Let me introduce CASUVP -- Cooperatively Ad-stripped universally viewable pages. It's a concept, there's no implementation yet.
Basically, it's a version of the web where users cooperatively clean up web pages from ads and other unwanted material (e.g. scrollbar-hijacking, user-tracking), so that only the plain text with minimal markup of the article, and images remain.
The cleaned-up pages are distributed by torrent or by IPFS, and there is a consensus algorithm to make sure that pages are not tampered with (e.g. by content distributors).
Browser plugins help users view and seed the material.
Now if only people pick up this idea and implement it...
Exactly, all they did was add a link underneath the "..." menu to see the canonical URL. Apparently, the whole justification for the Cache is that smaller websites don't have CDNs or developer resources or something?
> For a small site, however, that doesn't manage its own DNS entries, doesn't have engineering resources to push content through complicated APIs, or can't pay for content delivery networks, a lot of these technologies are inaccessible.
However, I work for a publisher that delivers almost all our assets through a CDN, over https, etc... we don't really need our pages to be served through the AMP Cache, we could support users visiting the AMP version of our articles on our site, and hopefully get more second-page visits. I don't get it, who is AMP really for, big publishers or small publishers? If I am already a performance-minded developer, I don't need any of the things AMP provides, but I am forced to implement it for the magic google juice.
There's nothing preventing adblock from working on amp pages. Amp is currently a mobile only thing, and most users on mobile are not blocking ads.
I don't know where this myth comes from that amp is all about blocking adblockers: amp pages require a markup that specifically tags ads as ads and prevents running scripts after page load. The only two adblock-defeating techniques are to disguise your ads as content, and re-insert them after page load, both of which are rendered impossible by the amp spec.
> Amp is currently a mobile only thing, and most users on mobile are not blocking ads.
Most users anywhere are not blocking ads, adblocking by its nature as a non-default option and something you have to know how to do will most likely never be the thing that "most users do".
Worldwide, there are almost 150m more mobile adblock users than desktop adblock users. The trend of only blocking ads on your desktop is largely a North American phenomenon.
I can't speak to whether or not AMP is designed to try and stem this tide or not, but I can say without a doubt that mobile adblock is exploding, especially when considering the worldwide market, and that publishers are probably very nervous about this.
Most of the time if the main site is already crippled to death I am positive you won't see an AMP version and they probably don't care about performance at all by cramming a thousand ads/JS files in a single page.
Most decent website are already fast on mobile, I really don't get all the fuzz about AMP when in reality the small margin you gain from using it is almost non comparable to the real website.
What is considered fast or slow at this point? I can barely see the difference so why go through all this hassle just to please Google?
Its not that I hate it but their approach to page optimization is just wrong but lets just keep feeding the beast.
> Most decent website are already fast on mobile, I really don't get all the fuzz about AMP when in reality the small margin you gain from using it is almost non comparable to the real website.
That's not my own experience, and that's why I keep favoring AMP links when searching on mobile, but YMMV.
Not to defend AMP but the justification is pre-rendering the pages in hidden i-frames on the search result page. This indeed requires the URL hijacking.
However, the URL hijacking, combined with the obnoxious UI and making the big X sign return you to google rather than show the non-amp site make me still dislike AMP.
I like the TechCrunch title better ("Google fixes a big problem with AMP"). "Google fixes problem with AMP" makes it sound like there's only one problem with AMP.
This entire AMP project is already workaround after workaround, but this gets even worse.
All that would have been required to solve these problems would have been a simple standard for lightweight pages that anyone could implement, and a better ranking for any complying page.
Google could offer the cache optionally, or sites could do their own stuff.
Then, the entire rendering and preload problems could have been improved with a simple JS api to allow for exactly that.
Then none of the rest would have had to be solved, we’d get none of Google’s increased dominance over the web, and we wouldn’t have to put up with thousands of AMP pages loading slower than normal pages (because they bundle fucktons of useless JS) for the sake of improving the loadtimes of a handful of sites.
AMP is not a standard. It is a Google product with developer documentation, but that documentation does not make it a standard any moreso that Twitter having an API makes it a standard.
AMP allows your websites to rank better / more prominently within Google and Bing, but it comes at the cost of ceding control of markup itself to Google. A truly open standard would not have hard dependencies on a single for-profit corporation.
I'd love them to standardize the serving aspects, in addition to the formatting aspects. Changes like these seem somewhat arbitrary but yet impact everything end-to-end.
> a simple standard for lightweight pages that anyone could implement, and a better ranking for any complying page.
It doesn't even need to be that much work: simply publishing desired time-to-render scores would have had the same effect: x seconds for mobile 3G, y seconds for desktop, etc. Maybe add a couple of <link rel=preload> tags for the top 1-2 results and the mobile experience would be enormously better than what we get with AMP and its 100KB of render-blocking JavaScript.
I would love to know what is really going on here.
I'm admittedly not very technical, but like a prisoner scratching tally marks on the wall each day, I try to keep up on the latest "how tech companies are fucking us over" news of the moment, even though I can't do anything about it.
Google is pushing AMP on pages in their search results today. Fine, implemented it like idiots. Happens.
But I would not be surprised if in the near future Google comes out with "AMS" "Accelerated Mobile Sites", and forces entire websites into this madness.
I get it, "fast, efficient" is always the story. Monopolistic nerves, quasi-TLA control fetishes, and an old-fashioned internet land-grab is the rumor. But that is too simple for this much trouble and expense. A few years ago Google was dealing with SPDY, QUIC, HTTP2, and talking about "fast, efficient" but you know something felt fishy there too and there was a back-room-dealy vibe with more to the story.
Anywho, while I would love to know what's going on and I have some guesses, I don't really care anymore. Google is wasting everyone's time with these games. So...
Why doesn;t Google just get on with it and host the entire internet? [1]
For free.
Please correct me but Google is already cacheing the internet.
Offering to just host the world will allow them to implement whatever bullshit protocols they were going to do anyway. It would kill off most competitor risk from AWS and whatever Microsoft came out with 9 years late. They can afford it. And they have the space (yottabtye my ass).
That's it Google. Just bend us over and host the internet.
[1] ok not the entire internet, 99% of it. Doubt they would host the porn for free.
Google's standard analytics.js is currently 28K. If you're running AMP, the AMP compliant version of the same thing, is 64K. Neither of these block rendering and both of these run largely in the background, yet making it AMP compliant more than doubles whatever code it requires.
AMP will make progress when I can use it without actually introducing bloat.
tl;dr: it took a little more than two decades to give us the incredible power of HTML5, CSS3 and modern JavaScript; it took countless hours for the W3C to define the standards, and years of browser wars to get this far with compliance. But Google wants us to abandon them in favor of its thing (because, you know, some websites actually suck). Now, fixed...
Unless you knew that google.com made their main domain redirect to anything(!) to provide amp, you'd really believe that the click was going to end up on the google.com servers, the place where your login data for Google services really is. Instead, google.com was used as the least expected redirector of them all.
But google at that time kept it being a fully invisible redirector. Their explanation then: they "do not consider open redirects to be a security issue." They also wrote: "we generally hold that a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk." Benefits for whom but Google? And what was proper then in this Podesta redirect?
It seems they now finally changed the handling of the redirection, adding "The previous page is sending you to ..." instead of doing it invisibly. It took the Podesta e-mail hack, possibly changing who's gotten to be a US president, and some time to go by for them to add that change.
That's the untold story of who, how, and for which goals influenced the election (Google, Amp, as the unexpected effect of the profit goals of spreading amp as much as possible).
Apparently the aide of Podesta later claimed to have made a typo: "When the phishing email first arrived, Podesta referred it to a number of aides. An aide named Charles Delavan replied, “This is a legitimate email"" "Delavan says he had meant to write “illegitimate email,” and simply mistyped." Or maybe it really looked legitimate to him at that moment: the server behind the link was obviously google.com. Who didn't carefully follow what Google did with amp couldn't possibly guess that the main google.com domain just became an invisible redirector thanks to amp.
I know that as I saw the link and "parsed it" in my head I've concluded "but it obviously goes to google.com", the real place where also I log myself in. Later, I couldn't have believed my eyes as I've typed such an address in the browser and ended elsewhere, wherever, I had to use curl to convince me that, yes, google.com/amp just invisibly redirected to the site and the page of the rest of the url, whatever the rest was.
“URLs and origins represent, to some extent, trust and ownership of content. When you’re reading a New York Times article, a quick glimpse at the URL gives you a level of trust that what you’re reading represents the voice of the New York Times. Attribution, brand, and ownership are clear.”
Oh, Google suddenly acknowledges the value of real URL for the user...
How hard is to build a simple HTML5 website with little CSS3 and little to no (vanilla) Javascript. You know a website can be very tiny and fast. Yet people who don't know need Google to market them AMP "technology" to do the same but lock them in, and get full access to analytics data.
AMP is literally the most user-unfriendly thing I have seen on the internet in years. It's like an exaggerated example of an aggressively awful UX antipattern.
It's what finally caused me to switch to DuckDuckGo on my phone. Sucks that the results aren't nearly as topical as Google's for most searches.
Holy Moly, this is a huge amount of rigamarole just to support a degraded experience that helps ONE company do ONE thing in order to make further lock-in and profits in ONE way. It's hard to believe that any company would ever invest this amount of technical effort on a flawed product offering -- unless of course, it was one company with enough damned vertical integration to make it possibly worth their while.