"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.
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.
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.
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.
>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.
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.
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.
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...
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.
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.
Readit News
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.
Back in the day, we called them websites.
I want to visit publishers own sites and not weird walled Google land.
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.
As for a "degraded experience" that's subjective, but users seem to far prefer it.
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 ;)
Link to the original blog post: https://www.alexkras.com/google-may-be-stealing-your-mobile-...
>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.
So my guess is that people were worried that Google would steal the advertising traffic and, therefore, revenue.
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.
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.
Or does it serve part from Google's cache and part from the publisher's site?
For example, it might serve page text and images from Google's cache but serve ads from the publisher's ad network.
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.
Don't you mean so you get paid for a click even if the user never visited your website?
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.
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.
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.
Deleted Comment
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.
That has not been my experience.
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?
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...
> 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.
https://developers.googleblog.com/2017/02/whats-in-amp-url.h...
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.
For the users. When looking at search results on mobile I usually go for the AMP ones, regular results take way too long to load.
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.