Google fixes a problem with AMP, lets you view and share publisher’s own links
techcrunch.com
techcrunch.com
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.
Note that my main search engine is Duck Duck Go. For me, Google's doing something meaningfully helpful with AMP.
https://duckduckgo.com/?kp=-1&q=%s
does what you wish.
Going to check out some other "bangs" now im aware.
I spent this weekend writing a google proxy to inject the actual urls into the results. Ultimately I would have switched to bing, or maybe yandex.
I end up just using DDG's results most of the time though since they're pretty good.
[1] https://chrome.google.com/webstore/detail/amp-validator/nmof...
I want to visit publishers own sites and not weird walled Google land.
Are your concerns addressed sufficiently?
AMP is opt-in on the publisher's end. Publishers choose if you get their site or AMP.
I wonder what the EU will thought of that.
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.
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.
Ooops, that's why AMP was made in the first place.
Similarly, here's a list of supported ad-networks with almost a 100: https://www.ampproject.org/docs/reference/components/amp-ad#...
Far from being Google only.
I think we need to pick our poison: an open web with a potentially degraded experience. Or speed-optimized but closed.
I for one choose the former because it's precisely the openness that made/makes the web great, and to me that trumps speed and convenience.
I invite you to hangout on the open source project for a while and make your own impression.
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.
> What is the process to be added?
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?
Yes, though this is not disclosed on the roster, every member of AMP's governance board is a Google employee: https://www.ampproject.org/contribute/governance/
Issue 5846 requests disclosing employer affiliations: https://github.com/ampproject/amphtml/issues/5846
> 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.
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.
Meanwhile you can write a PR to get your pre-configured service added to the list: https://github.com/ampproject/amphtml/blob/master/extensions...
I don't touch AMP and this was seriously like 10 seconds of searching.
End users are accustomed to a banner at the top of sites, with an 'X' on them. Things like, for example, the "EU Cookie Notice".
However, they are used to using the 'X' to get the irritating banner out of the way.
In AMP land, clicking the X sends you back to Google. What are the chances this is what the user is expecting? Who benefits from this setup?
Edit: Remember the DiggBar? https://techcrunch.com/2010/04/06/diggs-kevin-rose-diggbar-i...
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.
I assume it ends with everything in the serps being preloaded. And the only things in the serps being compliant content.
AMP is not a ranking factor and so the percentage of results it makes up is largely a factor of the percentage of publishers publishing AMP.
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.
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.
Umm, AMP itself is phishing paradise. https://motherboard-images.vice.com/content-images/contentim...
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.
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.
Any ideas how this process could be improved?
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.
There are already too many issues with people going to sites that are not what they claim, so further pushing cloaked URLs does not help.
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.
Regardless, resources are always constrained and working on AMP means not working on the standard (mobile) HTML version.
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)
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.
Browsers already support WebComponents. This is just Javascript, there's nothing proprietary about it.
It sounds like you're not even complaining about how AMP itself works, but the CDN/caching services such as Google AMP Cache.
Regardless, none of this results in lock-in as your original comment claimed. And again, degradation is too subjective to compare directly.
Can you elaborate? Google's AMP Cache is an optional feature. Cloudflare also provides an AMP cache.
Using rel canonical on your main page could be very dangerous from an SEO perspective, as it gives complete authority to the other page.
You can also link your pages explicitly, as described here.
https://www.ampproject.org/docs/guides/discovery
The cache acts as a CDN to improve page speeds, but isn't a requirement for indexing.
Sorry if I came off as crass in my previous reply, but the amount of misinformation around AMP is really astounding.
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)
Based on the parent comment's criticism that it's designed for "lock-in" (without any elaboration), that's the argument I was addressing.
These points of centralization and control are antithetical to the premise of the Web as an open, inter-operable, democratic medium.
<script async src="https://cdn.ampproject.org/v0.js"></script>
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.
https://github.com/ampproject/amphtml/pulls
The Amp standard is locked down, but the technology isn't. Which is not too dissimilar from HTML itself.
> "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.
I'll concede that point. Locking you in to use their js copy, even if it's faster, is less open than trusting the real HTML.
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-...
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.
Ads can be served from the publisher's server, but this is rarely done.
>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.
User-agent: Cloudflare-AMP
Disallow: /
So my guess is that people were worried that Google would steal the advertising traffic and, therefore, revenue.
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.
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.
That can be very easily answered with "no". This is intentional in this design, for faster loads.
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.
This is a case where adblocking doesn't really happen. So those users are welcome to come along, and view the content.
https://www.ampproject.org/docs/reference/components/amp-ana...
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?
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?)
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.
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.
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.
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.
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.
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.
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.
But I'd be willing to bet that most users are like me, but I have no data besides the fact the Google seems to be doubling down on it.
(They may or may not actually prefer the experience, but I think it'll be tricky to determine a real signal one way or the other)
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.
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".
However, the idea that people on mobile do not block ads is just false: https://pagefair.com/blog/2017/adblockreport/
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 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.
That's not my own experience, and that's why I keep favoring AMP links when searching on mobile, but YMMV.
lol. For the users looks like the Debian Social Contract. This is for Google's pocketbook.
Users vote with their clicks, and have far more power than publishers.
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.
AMP header takes 10% of screen and it doesn't disappear when you scroll down
No comments section on AMP versions or on Reddit comments are not expendable
Hard to get real URL to bookmark or share
Request desktop option is completely broken on news.google.com
https://developers.googleblog.com/2017/02/whats-in-amp-url.h...
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.
FWIW that's exactly what AMP is. It's not a W3C standard, but a standard nonetheless: https://www.ampproject.org/docs/get_started/create/basic_mar...
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.
That’d be a solution. This is merely a workaround.
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'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.
Either way, the user get sent to the "native" version of the URL they requested when they click the URL.
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.
now I see there are legal (intellectual property) reasons why that is wrong as well.
Switched to Duckduckgo.
See the picture(1) here:
https://motherboard-images.vice.com/content-images/contentim...
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.
It was known among the security people:
http://seclists.org/bugtraq/2016/Apr/70
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.
----
1) The picture is from the following article:
https://motherboard.vice.com/en_us/article/how-hackers-broke...
Oh, Google suddenly acknowledges the value of real URL for the user...
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.