So now if you buy more into Google's ecosystem (AMP) you get a special flag next to your content in search results? Interesting...
You know I don't understand this whole AMP'd thing. It's possible to make something just as efficient if you don't ruin your mark-up to begin with. The big advantage with AMP, as far as I can tell, is the Google caching mechanism. There is no reason someone can't use actual standards to create the exact same results.
It really bothers me that, to get preferential treatment, I have to now work with Google AMP and Facebook Instant Articles. If I don't the competition will. We originally had web standards for a reason, now we're doing this non-standard stuff.
The reason for AMP is surveillance capitalism. If you absolutely, positively believe you have to track your users, writing simple web pages is not an option.
Your choice is either the status quo (pull in lots of third-party cruft), or having a fast-loading page where Google runs the tracking and advertising infrastructure.
Seems a little unlikely, given that Google Analytics is already on 50-60% of the Internet and many mobile apps. Analytics is a much more effective tracking mechanism than AMP.
The docs explain that "AMP analytics is specifically designed to measure once and report to many". Google's not trying to drive out other players, they're making sure they run the table.
This way they see every request, and learn a lot about their rivals.
Note also that the AMP ad spec warns that there are major changes to come.
My point elsewhere in this thread is that Google already knows all about their rivals. They're already seeing every HTTP request via Analytics, DoubleClick, Chrome, etc. They're already seeing which of their competitors are in use on which pages via the crawl. While I didn't know of any project to join & analyze this data while I was at Google (indeed, joining log sources required high-up approval because of the privacy implications), doing so would be technically trivial. They certainly don't need to launch a whole new product to get it.
I also believe the stated reasons for the project—to make the mobile web faster–are genuine. I believe that is the sincere motivation of many of the engineers working on it.
But the ultimate purpose of this project is to preserve the status quo around ads and tracking. Bloat has made the current situation on mobile devices untenable, and people are turning to blockers as a solution. AMP is a way to get rid of the bloat without getting rid of the surveillance. Google bets (correctly, in my opinion) that people won't care about being monitored if the performance problems go away.
Controlling the platform that does this will be useful to Google in the long run. For example, Google will be able to blacklist ad networks that don't meet their specifications. And Google can be sure theirs will always be the fastest game in town.
I think this is a completely unfair characterization of AMP.
AMP's speedup doesn't come purely from blocking tracker JS, AMP acts like a framework, like any other, to allow people to leverage best practices for fast rendering, managing all resource loading asynchronously, preventing relayouts during rendering, etc. Most frontend developers, especially at many small publishers, simply don't adhere to good HTML/CSS/JS practices.
If the future is a future where everyone runs blockers, then you get some of the benefits, you also likely break legitimate websites as we have already seen, and you make the blocker vendors themselves into surveillance platforms that sell analytics and extract profit from those who want to punch holes in the blocker. Who do you trust more, Google or AdBlock, Inc? But if the future instead, is that people don't even use Web browsers to read web sites, but used silo'ed Facebook or Apple readers, then how does that benefit anyone? Prior to AMP, the mobile web itself was facing a crisis of bloat.
AMP allows publishing to stay federated and work in browsers, delivering performance that makes it less likely people will leave the Web. I don't see how it's any different than say, Twitter Bootstrap in that regard. If this effort gets people to trim down their mobile pages in order to get better search ranking, by drawing attention to it, we may finally get some traction on an issue that's gone mostly under the radar.
It is in Google's best interest to ensure the open web continues to be viable, as Google Search won't even exist if there is no mobile web to index and everything is published on Facebook or iTunes. Google's overall goal over the years has been to increase web usage, as it's core service relies on it. I compare the Web to logging a forest. You need to keep planting trees and be a good caretaker, else the forest may die out. Many other good projects have been released purely for improvement purposes (e.g. Pagespeed Insights).
I have to imagine that it's more better accurate to get raw numbers at the transfer point rather than browser-reported ones. This also allows them to get stats for no-js browsers, too.
Right, but my point is that between Google Analytics, Chrome, and Doubleclick, Google is already tracking basically every pageview on the Internet. There's no need to introduce yet another product to accomplish this.
I think a far more likely explanation is to take Google's statement that they want to accelerate the mobile web at face value. When people view pages faster, they view more of them, which in turn means that they search more, they click on more ads, and Google makes more money. This makes far more sense to me as a direct revenue play than as a surveillance/tracking play.
I think a lot of it is a response to Facebook's instant articles too. They were beginning to build up a story where the fastest version of the Web is via the Facebook app, not the browser and not search. It doesn't take a huge amount more before that story becomes a threat to search.
Oh, absolutely. This is 99% about keeping users inside of Google's walled garden (reserving 1% because cramforce seems like a good guy and genuinely interested in giving mobile users a faster, lighter-weight experience).
Wait, THAT'S why people want to use AMP? I set up AMP on my personal site for a couple weeks because I thought there was an SEO benefit (I didn't see any, so I removed it -- lowering page weight by something like 7x).
I had no idea that the reason it seemed pointless was because it was for ad infrastructure.
Funnily enough the AMP version of my page is larger and takes longer to load than the non-amp version. And ironically I don't even get that little "amp" bolt symbol because it's a software product page and not a recipe, news post or blog post (there's only a handful of categories that are amp enabled).
I think I'm going to remove the AMP page, too. It offers nothing to me and is actually worse for my visitors than the normal responsive page.
You need to add [this js file](https://cdn.ampproject.org/v0.js) that is near to 45KB. I have just uploaded an AMP version for my site and it felt a little bit ridiculous... I made a simpler version (with no js and limited css), changed `<img>` for `<amp-img>` and added this js. It would load even faster without this js!!
Advertisers (as a whole) have a veto on what advertising-driven websites can do since they write the checks. So I think the idea is that it's a compromise that users, websites that depend on ad revenue, and advertisers will all accept, since they all get something they want. If any of them are too unhappy then the new standard won't succeed.
What you wrote is technically true. We could build crazy fast pages without any AMP-ing. However high profiles sites don't do that and there's a reason for it. I think when revenue is considered, there's a lot more department at at news companies involved:
There's the Ad people ( add 2-3 external services ) there's the online marketing team ( add 10 more tracking tools ) then the UX guys have 2-3 tools to play with... The list is probably a lot longer. That's why sites like Mashable used to load 30+ external services (now 13). It all adds extra markup (static and generated), DOM manipulation, network traffic and all sorts of crap that slows pages down.
AMP-ing means saying no to all this by design. I'm not saying this is 'the' perfect solution, but this is a solution to an existing problem. And the problem is not that we somehow forgot how to build fast and light pages.
Actually, it's a result of startupifying every problem we see out there. Oh, AB testing is hard, let's make it easy just by inserting a line of JS to the page. It'll cost $99/month and the clients won't have to develop it themselves.
This is a side effect of the abundance of cheap and easy to use tools.
Probably somebody is already working on how to extract more data from AMP pages :D
Amp is not a proprietary format so Google lockin doesnt come in. Plus it is a subset of html so all browser should be able to open the amp pages.
Sometimes I feel people oppose stuff just because it is from a company that don't like rather than the technical aspects of it.
I didn't say it was proprietary, but it is an unnecessary addon that is already solved by the current standards. I oppose it because it's adding additional cruft, is from a non-trustworthy company, and doesn't address the actual problem.
Looking at how the current mobile web it is necessary. This gives an incentive for the web developers to change. And it gives an open option to facebook closed instant articles. Standards don't change peoples attitudes, money and incentives do.
We would still be stuck with ie and its unique html if not for google building chrome and forcing web developers to follow the standards more instead of staying with ie. The developers went where the money was.
Same thing is happening with web encryption web developers were not using it till google first speeded it up with SPDY and then started hitting non secured pages with lower ranking in its search. If not for what google has done over the last decade you would be looking at a very different web.
Developers like most people don't like change are happy with how things are unless they are forced to change to survive. I might disagree with google on many of its privacy practices etc but can't disregard the fact that many of advancement on the web and internet in general in the last decade have happened because of google forcing people to change or showing how it could be done better.
> Looking at how the current mobile web it is necessary.
I don't see why. We've had mobile pages that worked fine for a long time, they were just normal web-pages, without a lot of cruft.
> This gives an incentive for the web developers to change.
Better ranking practices, would do the same thing.
> And it gives an open option to facebook closed instant articles.
Possibly. I've never used those so I can't say.
> We would still be stuck with ie and its unique html if not for google building chrome and forcing web developers to follow the standards more instead of staying with ie.
uh... did you forget that whole Firefox thing? Google came in on the tail end of that. And they did it, by using standards, not coming up with their own standards that nobody asked for.
> If not for what google has done over the last decade you would be looking at a very different web.
And it would probably be better. Sure, searching through it was harder, but it was way less money-driven, and much more hackable/useful.
> I might disagree with google on many of its privacy practices etc but can't disregard the fact that many of advancement on the web and internet in general in the last decade have happened because of google forcing people to change or showing how it could be done better.
I don't disagree. I'm grateful for Google doing that. But it doesn't mean they get a free pass to make stupid decisions from here on out. This is still the wrong solution to the problem, no matter who is pushing it.
> Firefox was able to do nothing until Google chrome adoption forced the wider web to change instead of following Microsoft and ie
Do you have numbers to back that up? I admittedly don't, but I remember sites changing because of FF's popularity. If you can prove it, great, I'll believe you. But I remember it differently
This is exactly it. The problem has just got out of control and this is _one_ solution. It is also something that could be experimented with. Just AMP a few things and see how it goes.
When visiting non-US sites, they mostly don't seem to load 8 different JS files from different domains, which then load another layer of JS files, repeating for 3 to 8 iterations.
I think it's a global trend. If you can afford cheap data collection then why not do it?
For example ghostery indicates 8-11 trackers blocked on major Hungarian news portals. I'd guess this is close to an average. Check a DailyMail article ;)
I'm as skeptical of Google and any of their initiatives as the next guy, but I'll tell you what, I clicked the AMP link for a WSJ article (from HN web link, obviously), and it displayed instantly. Very un-modern web.
It's easy to armchair quarterback and say that. But the reasons and incentives behind web page bloat are complicated, and saying "Just make your page load faster! Just get rid of the ads and trackers!" is about as useful as abstinence-only sex ed. AMP is theoretically a way to have your cake and eat it too: all of the revenue from these ads and trackers, without the bloat. And it's at least somewhat open, compared to Apple News and Facebook Articles. It's not hard to see why publishers would gladly jump on board.
> all of the revenue from these ads and trackers, without the bloat.
That is impossible. AMP is just forcing some changes and using better tech architecture for the rest. There are already slow AMP pages because of all the re-added plugins, trackers, media and ads.
Other sites could easily work on better tech delivery to improve performance without AMP, which now only decreases the amount of resources/time they have to work on their own site.
The WSJ is a large site that gets lots of traffic. I assume they have a competent web team, which knows that long load times on mobile suck and knows how to do performance optimization to some degree. I am willing to bet that whatever low-hanging fruit there was to improve their PLT has already been plucked, and the remaining slowness is the complicated stuff I mentioned earlier.
That's why I think statements like your original comment are unhelpfully reductionist, and my paraphrasing of them was not misleading.
Or..... they could just get rid of the bloat. I'm sorry that so many sites suck at building web-pages, but that's not really my problem. I have no problem un-blocking sites that are respectful, and I often do, but pretending like this is a good thing for users is just silly.
AMP gives WSJ an incentive to serve a faster version. Why would they spend money improving their site - especially a big name like WSJ? Plus, from what I've heard from developers working at new sites, "our pages are faster and use less data" is a hard sell to the people in charge, who are more interested in integrating yet another ad platform.
Exactly this. the AMP badge is a visual indicator that says "we're not going to waste time your time with a slow loading webpage, so click this link over one that doesn't have the AMP badge", which incentivizes faster webpages in a way that wasn't available previously.
most clicks go to sites that are on the top of the search results, therefore prioritizing placement due to pageloading speed should be enough of an incentive to most sites. The AMP badge pretends to be an incentive in this way, but the purpose is to extend google lock in.
What would that be, out of curiosity? Not asking rhetorically. I would just assume the exact opposite -- they have every incentive to provide a monetized, just passable enough to be consumable experience. The content (and ostensibly the design) is the product, not the load time. Performance seems low on the list.
It shows a flag. This is an indication to the user to pick this site over others. Maybe not initially but unless someone proves to me, with data, that this won't affect what users click on I do not believe this won't affect user behavior. This is an indirect ranking.
> This is an indication to the user to pick this site over others.
This is an indication to the user that the site has certain traits (particularly, the UX they experience with AMP sites), and that if they like those traits, they should pick the site over others, and conversely if they dislike those traits, they should favor sites without the indicator over those with it.
> Maybe not initially but unless someone proves to me, with data, that this won't affect what users click on I do not believe this won't affect user behavior.
Obviously it is going to affect user behavior.
> This is an indirect ranking.
No, its information (the same as providing, e.g., [PDF] notations), not "indirect ranking". How it affects behavior, like a file-format flag, is dependent on the value (positive or negative) the user ascribes to the trait it provides notice of.
> This is an indication to the user that the site has certain traits (particularly, the UX they experience with AMP sites), and that if they like those traits, they should pick the site over others, and conversely if they dislike those traits, they should favor sites without the indicator over those with it.
You can make a website load like AMP without going through AMP. This is not an indication of a UX trait, this is an indication of using Google's technology and nothing more.
If you have Website A using AMP and Website B not using AMP but able to load in the same way, the Google search is going to show a label next to Website A and not Website B. Do you feel that this is fair? Or another way to force operators to now generate an AMP version of their website? Because I see this as the latter.
> No, its information (the same as providing, e.g., [PDF] notations), not "indirect ranking". How it affects behavior, like a file-format flag, is dependent on the value (positive or negative) the user ascribes to the trait it provides notice of.
Ranking determines where a website shows up and affects user behavior by users choosing the higher ranked websites. This has the same behavior without reordering things. I would call that a form of ranking but this is just splitting hairs; we're saying the same things.
Is that behavior not eventually used to influence ranking? If users continue to click AMP results more often than non-AMP I'm pretty sure the google algorithm will start favoring AMP.
> If users continue to click AMP results more often than non-AMP I'm pretty sure the google algorithm will start favoring AMP.
Perhaps, but, by the same token then, if users find AMP UX to be a bad tradeoff, and tend to click AMP results less often than non-AMP, the algorithm will start to penalize AMP.
dude, get real. if google really wanted to just be helpful to the users they could just put some kind open-source, investigable metric of web page load speed. or full front-page load payload size.
if the flag is google-service-specific, it's not "just information"
Its only "Google service" in that Google runs an AMP cache service the same as anyone else could; its open source project with open governance that manages its own open spec.
This is a different feature unrelated to the launch today. It doesn't always show on top, but often will because the sites posting AMP content tend to rank well.
Pretty much all the major browsers implemented websql, which then never made it into a standard as there were no competing implementations [0]. Nice while it lasted.
JavaScript is a good example. It wasn't the only web scripting language available, there was JScript and Java Applets and VBScript. JavaScript won and now it's ubiquitous.
And for an example of co-existence of competing languages, see javascript triggering flash/actionscript (e.g. for clipboard access) and vice-versa (e.g. for DOM access).
Both are somewhat dated examples, that is pre-HTML5.
Something like this had been on Google's wishlist for a long time. Google news stirred up the news industry way back and Rupert Murdoch took a big stake in fighting against it, rallying other publishers. Google also bought the wire licenses so it was free to display a lot of the breaking news directly but had to play a balancing act to avoid irking the publishers.
When FB moved to instant articles, Google moved to amp. It was the opening they had been waiting for, for a long time. AMP was an opportunistic play--a damn good one for Google.
It sucks for publishers but they are forced to play along because of you are always at the mercy of your dumbest competitor.
Users may win but this isn't something publishers want or desire. Building faster pages is easier now than ever. Not as fast as AMP or Facebook Instant but still.
Over time this will lead to commodification because of lack of standards. Bing and others will further lose their lead to AMP. Users will like the new UX. Publishers are confused.
There are many downsides when you don't control the standard. Microsoft is not in the meetings when Google PMs decide the roadmap nor will they have any clout in directing its future or adding its own features. It's merely a consumer.
The main thing about AMP is that it gives consent to the search engines which is why Microsoft is happy to use it. The consent allows search engines to display content without directing users to the publisher platform. And therein lies the rub.
> Microsoft is not in the meetings when Google PMs decide the roadmap
AFAICT [0], the AMP project is an open source project directed by its Tech Lead and Core Committers, which are a self-sustaining group (with Google, Inc. appointing a new Tech Lead in the event there are no Core Committers), even if the initial set was set by Google, and there is no barrier to Microsoft participating as fully as anyone else in that project.
There's also the consideration from the ad network side of things. This gives Google a lot more power in the ecosystem than they had before in theory if lots of people switch to it (which they will, because they don't have much of a choice).
Similarly with Instant Articles--the big players own the ecosystem and can enforce whatever constraints they want if they have enough leverage. In this case, it happens to provide a sizable benefit to end users so publishers and ad networks are really the only ones feeling the pain.
> If I don't the competition will. We originally had web standards for a reason, now we're doing this non-standard stuff.
I suggest you file a complaint here, if you believe you have to use AMP to not get a competitive disadvantage (because that would be unfair influence on the market by Google):
EDIT: The parent comment complains that the market is unfairly influenced by two large almost-monopolies in their respective markets – so why do I get downvotes for linking the official reference for filing antitrust complaints?
It's a very open and transparent standard that doesn't stop others from adopting or caching it as well. It just so happens that the nature of caching favours big players like Google, but Cloudflare or Bing could offer a cache as well. I fail to see it as some sort of Google ecosystem lock-in.
AMP is also compliant with web standards. It just uses Custom Elements which is a fairly new standard.
While i understand the philosophical grievance, will the AMP tag matter? Personally, when i search without an ad blocker i categorically ignore any 'Ad' result on Google. But will the typical user value AMP pages more heavily? Time will tell, i suppose, but i would be surprised to see a measurable impact on a top 1-3 search result.
AMP is of most use on mobile (possibly the only place it works?) where ad blockers don't normally exist. So, they will likely have an impact there.
I know that I have personally opened search results to AMP pages that I would not normally have opened because I knew the price of doing so would be small. But, then again, I know what the AMP symbol means. How this affects normal users remains to be seen.
For some sites, I seek out the AMP URL explicitly. For example, adding "/amp" to the end of TechCrunch URLs change them from frustrating to usable.
I don't know about everyone else but I HATE AMPed pages.
The idea is good, but being Google they've done.... something. I'm on iOS and the way pages scroll means they feel like they've got a different weight, they've adjusted something. And it makes interacting with the frustrating because the Google results page feels like any page in Safari and then you click into an AMP page (which does load very fast) and it suddenly feels wrong.
It's not a JS scroller—it's just a scrollable div with `-webkit-overflow-scrolling: touch` which enables momentum-based scrolling. I've done hybrid (and native) iOS apps before, and this is fairly common practice to make things feel more native in webviews.
For those who are interested: by default, iOS sets webview scrollviews to have a fast deceleration rate (UIScrollViewDecelerationRateFast). This is because old iOS devices weren't able to quickly render webpages, so they needed to set a soft limit on scrolling. I actually believe that native (AMP-like) scrolling offers a better experience now that mobile devices are fairly snappy.
> I actually believe that native (AMP-like) scrolling offers a better experience now that mobile devices are fairly snappy.
Doesn't matter. Personally I disagree, but that's not the real sin. The real sin is inconsistency with the rest of the web on Safari. If Apple thinks that's the way things should work then they'll make that change. Until then having the random page behave differently feels very strange to the user.
Presumably, Apple thinks that "the way things should work" is that the webpage author has the choice. After all, they're the one who put that CSS property into Safari. They wouldn't have done that if they thought one of the options was definitively better.
> Apple thinks that "the way things should work" is that the webpage author has the choice.
No, the way Apple thinks it should work is expressed in the defaults, the options are there if the author is trying to do something else. There are cases where it may be a good idea.
I don't see how this is one. I get Google thinks they know better (and I really do wonder what they think the benefit is), and I now avoid one of their products that I actually liked quite a bit because of it.
> The real sin is inconsistency with the rest of the web on Safari
Close, but I think it's a bit more subtle than that. AMP presents its content as a standard news article (in both function and form,) which is why scrolling should be consistent with other article-like webpages. When a site is actually a webapp, I think it's permissible to have momentum-based scrolling just to achieve parity with native apps. Perhaps I'm just being pedantic, but the real issue is that AMP's scrolling isn't consistent with a subset of other websites accessible through iOS Safari.
It's even worse than that. The search results on Google scroll with one "weight", then when you tap the AMP link and all of a sudden it scrolls differently. Keep in mind that your address bar says "google.com" the entire time - this is inconsistency within the very same site.
They mangle the URL and there is no link to the actual article.
They do have a "share" link on the previous page that does not have a copy to clipboard or a send as email. (why someone would share before reading something remains an unanswered question)
So in the share interface, you can share on Twitter, which gets the url rewritten. Then you copy it from the share text and paste it on mobile in a new browser tab to get the real url, then you can copy that to the clipboard again and actually share.
I don't see the share links, but I have noticed on Google News articles with the thumbnail on the left side, clicking the thumbnail opens the original source. This doesn't seem to work (and I can't find a workaround) for the headline stories at the top though.
Share is on the initial page before you read the article. When you tap, there's a popup that has the source in green, making it look like a link, but it's not one - it's just green text. (They've disabled the long tapping context menu btw)
There's a share on google+, facebook, and twitter. facebook and google+ is a "card" without the source URL ... only the twitter share exposes a url (a shortened one).
This doesn't sound like a big intrusive ui thing. They already have an over-sensitive "swipe left" and "swipe right" so you can read another mystery story. When you swipe back because the "send me to mystery story" isn't a feature anyone asked for, amp scrolls to the top ... losing your place.
So now you have to make sure your down and up swipes are directionally perfect otherwise you go to some other story.
Mobile ad tech on news sites is the climax of insanity, but google long ago went into the deep end of the designer dictatorship - lobbing off useful features to create fragile, unpredictable, inconsistent, error-prone interfaces with, miraculously some of the core functionality removed and really useless things triggered with no way to disable them (a poorly connected aux cable triggering google now is a personal favorite).
For me, that successfully redirects to the non-AMP version on desktop. Though of course it's confusing to not be able to share the original page url on Facebook / Twitter / etc.
Update 1: Actually it didn't work. Safari threw an SSL related error and redirected to the Mac Rumors homepage. Not sure if it's a quirk of that link yet.
Update 2: It breaks in Chrome on OS X too:
> Your connection is not private
> Attackers might be trying to steal your information from www.macrumors.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
I do not encounter this error visiting the original page [1] directly in either browser on OS X.
Update 3: The SSL issue may be Mac Rumors specific. A sample article from TechCrunch [2] redirects fine for me.
I call these "I'm so great" interfaces. When the creator thinks their thingy is so awesome that all the users will drop any other way of doing things and so they are free to generously cannibalize and dismember everything.
Google had another 'im-so-great' interface with hangouts a while back - trying to deprecate the separation of carrier sms, carrier mms, voip sms, and hangouts messages and combine them in some way where you don't know where things are coming from or where they are going ... so things hit carrier sms sometimes ... thus not being combined on all devices as before.
They took a working thing and made it broken in the name of making it work in the way they broke it.
I call things that make goals they set out to achieve less achievable a "car without wheels". The idea is that they are asking you to swap your wheeled vehicle for one without wheels that will just sit there on blocks.
---
another car without wheels, mobile reddit.
They've removed the "share a link" feature. On wikipedia reddit is described as "a social media, social news aggregation, web content rating, and discussion website".
They've removed the first 3 of those 5 goals in their mobile interface.
This is distinct from a 'no you can't' interface such as the soundcloud app and mobile site where you can't delete tracks on your profile. If you only have a phone (many people do), you'd have to "view as desktop" to delete and even then, it barely works...
I'm sure it's a single web request and a single menu item ... this isn't a huge development effort - they already have a hamburger menu for your tracks ... it could just be tacked on there. Really easy ...
I should go off and make a list of these mobile design anti-patterns.
I appreciate the effort to define a fast subset of HTML, but the AMP loader on google.com makes the whole page-loading experience different and worse in many ways. Several times today while trying to visit different sites, the AMP JS loader has broken down, displaying only the Google address bar, a fake AMP address bar below it with the intended URL, and a multicolored Android-style circle spinning endlessly (on an iPhone). All the native browser controls for page lifecycle (including timeouts and Reload button) were completely ineffective. It's important for the loader to get its replacement for these things right if it's going to try to supplant the browser's built-in functionality, and it currently doesn't succeed at that.
They've had them in Google News for ages. I've been using them for a while, work great (I'm on Android). So well in fact even though I am on the 0.1% of the population that's consciously aware of their tactics, they have already trained me to subconsciously prefer clicking on websites that have their AMP logo, compared to the rest, because I subconsciously know they load much faster.
When I first saw it (in the 'News' section of results) I was happy to see it. After clicking 2 or 3 of the links I quickly learned to avoid it and either go to another site or find the non-AMP link in the results below.
I really wish sites (AMP isn't the only thing to do this) would stop deciding they know how to implement scrolling better than my browser/OS does it. Here's a hint: YOU DON'T. Let the user have what they're used to. Sudden behavior changes for tenuous-at-best benefits ("It scrolls faster!") are obnoxious.
AMP doesn't implement scrolling in software. It is native GPU accelerated scrolling. iOS does have 2 modes and it might be that AMP hits the one some people don't like.
Knowing where the viewport is relative to the document is pretty valuable; It means that AMP can defer loading potentially sluggish content until the viewport lands on a particular position.
Unfortunately, blocking that API (listening for 'wheel' events) will entirely break large portions of many sites -- any element where they've manually implemented the scrollbar or have fancy stuff or whatever won't work. I tried writing a Greasemonkey script that killed smooth scrolling, but it broke way too many sites.
One thing that does work though, at least in a lot of cases, is using an adblocker to block the URLs of common smooth scroll scripts. My adblock filter rules are in a comment in this gist if you want them (actually, this gist is my aforementioned Greasemonkey script): https://gist.github.com/oxguy3/ebd9fe692518c7f7a1e9
They do not work as well on iOS. Two examples of this are "scroll to top" by tapping the title bar is completely broken under AMP. The other is that Safari Reader is mostly broken under AMP. That said, the experience with super fast, virtually instant loads, is great, and I think these are definitely kinks that can be worked out.
I'm just confused why they made it through to consumer release without someone else questioning them. These are major features of the most popular browser on [one of the two] most popular mobile OS that Google is choosing to break.
> "scroll to top" by tapping the title bar is completely broken
This is because the scrolling is in a container rather than the body. It's a tough problem on many mobile pages using sliding drawers for example, which rely on overflow based scrolling. There's no event, that I'm aware of, for a web app to listen for for tapping that UI element on iOS.
Ultimately, it's a non-standard convenience introduced on iOS only. Maybe someone else here has solved this :)
On iOS, there are various conventions that apps generally follow. On a list item you can swipe from right-to-left to bring up a Delete option. On a list of stuff you can tap at the top of the screen to scroll to the top. These are standard things in the iOS ecosystem.
A good parallel outside of iOS would be the pervasive use of right-click to bring up a context menu in Windows or the convention of having "--help" show help text in Linux.
A cursory look at those stats should tell you they're bogus. Going from 32% to 23% market share (about a 30% decline) in two months is not even remotely likely.
The point I was trying to make was that iOS, and Safari on iOS, has a massive, massive user base. Throwing #1 vs #2 into the mix is distracting from that point.
As far as the scrolling goes, I'm fairly certain they're just using native scrolling (as in, not using a JS implementation that doesn't get the weighting right). The AMP Runtime needs to know scroll position, and they seem to just be capturing scroll information on the scroll event
Just querying the existing position shouldn't cause it to feel faster. What do they need to know that for anyway?
I promise you 100% that it doesn't feel right. I'm not saying they invented their own page renderer in JS and are using a canvas element for output, but they've done something that changes the feel. I've seen it on other sites too, I assume it's some JS/CSS thing.
Do you find that it feels like the page is a lot "lighter"?
It seems like a flick of the thumb moves it a lot further than any other page. It's especially jarring since the search results page is just as "heavy" as any other page, then the AMP'd page feels like you're moving a feather.
I wouldn't start complaining about Google providing a good experience on Android while making users suffer on iOS.
Traditionally the Google services experience has been better on iOS than on Android. iOS had the most amazing Google Maps long before Android got that update... Even after so much time and updates, I still prefer the Google experience on iOS to the one on Android.
Is it (1) the home page news.google.com that exhibits the problem, or is it (2) the individual AMP news pages?
If #1 then the problem is completely unrelated to AMP it's just a subpar js scrolling engine that they decided to use on Google News. If #2 then that would indeed be an iOS-specific issue because on Android AMP pages are just using native scrolling to my knowledge.
I don't remember the last time I went to news.google.com, I see it on news results suggested at the top of the page after I do a normal Google search.
As I said, I wouldn't be surprised if Google was adjusting scrolling settings on iOS (using CSS or JS or something) to make it 'feel' more like Android, since that seems to be their MO recently: make everything feel like Android, not the native platform. Same way they apply material design to all their iOS apps instead of doing things the iOS way.
I hate it. All you did is make your software feel wrong and thus broken.
I know all the "It's more consistent if you switch between platforms" stuff. Switching between OS X and Windows never bothered me, and I don't use other platforms much so that benefit doesn't apply to me. I only get the downsides.
Could you link to an example page? I don't even know how to find out if a page is using AMP on iOS. Is the main AMP site AMPed? It doesn't feel any different from any other site to me.
Per the spec[0], AMP pages must load the AMP runtime via a script tag that references a Google-controlled server, cdn.ampproject.org. This means you are handing over both your site security and your traffic logs to Google. This is a non-issue for the many sites that have already made that bargain (by using Google Analytics, Google Hosted Libraries, Google Fonts, etc.), but it is definitely an issue to some.
Great point. IMHO Regardless if you use GA or not, AMP will be a non-starter for any respectable developer who advocates for the open web for this reason.
I think you'd feel different if it was the government installing a tracker in every page. Because it's a company, you say, it's like any other company.
Some companies own so much of a user's online identity, I think it's time they stop growing. If Maps, Gmail and others were all separate companies and they were all competing for market share, I would have no trouble with them. As it is, I'm avoiding all of them whenever possible.
Companies are typically beholden to shareholders and customer reputation, which in this instance is pretty strong.
You could just as easily argue that it's better to have a few gatekeepers with a strong reputation for security than a proliferation of many gatekeepers with little history or reputation, because the latter increases your chances of showing up on haveibeenpwned.com.
Yeah they said something about open source on the main page. My first thought was "good marketing point, they probably have that legally covered and will force real FOSS to find a new name to differentiate".
Then I got to the guide or spec or something. Saw the CDN. Opened it. Bunch of minified horsecrap of course, with no mention of a non-minified version or how you can host it yourself. Suspicion confirmed.
There are three stories here. Each is serious and should be evaluated separately as not to bias the conclusions of any.
#1 There is a big problem with mobile sites. I'm using a recent iPhone and many popular news sites, without ad blockers, are as close to unusable as the worst websites I've ever been to, dating back to using Internet Explorer in 1999. Auto playing inline video ads that slide in to view, just insane. These things clearly kill time on site and reader retention. I have theories about why publishers are ignoring this, but who knows.
#2 Google is using AMP to co-opt publisher's traffic. This means users are scrolling to another story from another publisher or easily bouncing back to the Google results when they land on your content. (See the X in the story link on the animated gif example.)
There goes your time on site and long term user retention. If #1 was a problem for you already, you probably don't notice.
#3 AMP & Instant articles are going to put a stranglehold on third party ad networks and represent a very real anti-trust issue.
There are a bunch of other privacy implications too, which have been discussed in length. Publishers should be thinking really hard about their future.
I guess I'm the only here who loves the idea of clicking on an AMP'd page and having it load instantly? I can start reading the article immediately, instead of waiting for allll of the assets and javascript to load. Including ads.
Don't get me wrong I LOVE the user experience of the loading but everything else about it, in my opinion, is very negative. You can't even share it like you normally would on the web so it breaks the web in far too many ways just to hard code Google analytics / ads into the website.
I can't check right now but last I looked you can't share AMPed search results and I thought a few pages depending on how they were structured. I could be wrong but I don't remember being able to generate a good URL from some AMP pages.
While the developer in me dislikes the implementation, I still love AMP as a user.
Mobile websites tend to be incredibly user-unfriendly, and I can't stand it. They load slowly, they bombard me with intrusive notifications and popup ads, scrolling is lethargic, and so forth.
As a user, I have two reliable ways to distinguish a "user-friendly" website in search results:
1. Prior knowledge (I've been to wikipedia.com. It's a great place. I'll visit wikipedia.com anytime.)
2. The AMP Badge
The AMP badge is such a reliable signal of a fast, cruft-less mobile site that I find myself avoiding non-AMP websites in search results. This is unfortunate from a fairness perspective ("...but my non-AMP website _does_ load fast!"), but as a user, it's exactly what I want. Non-intrusive ads, instantaneous loading, and general snappiness.
If the rest of the internet doesn't like the AMP badge, well, time to make your website leaner and faster. Until there stops being a meaningful difference between an AMP and non-AMP page, I'll be clicking on the AMP links. I shouldn't have to employ a bunch of counter measures (ad blockers, noscript, etc) everywhere I go on the internet.
Yes, but even if you follow all of the best practices and deliver a fast page, your site won't show up as "AMPed." In order to be "AMPed" it appears that you need to employ a whole slew of custom elements and syntax.
Although AMP is just a subset of HTML, if your site passes AMP validation, it gets cached by Google's CDN. I believe that's what makes AMP pages feel fast.
You can certainly write HTML that doesn't do anything of the things that AMP prohibits, but if it's hosted on a slow server, your users won't get the lightning-fast experience. By caching the pages, Google takes the quality of a publisher's host out-of the equation. (In fact, since the pages are being cached anyway, publishers probably have less of an incentive to invest in speedy server rendering.)
AMP is not a subset of HTML; AMP replaces many HTML tags with its own proprietary custom elements, like amp-img, while banning normal, standards compliant img tags. It also has a bunch of vendor-specific tags, like amp-instagram and amp-twitter (but no amp-flickr or amp-vk), so Google gets to be a bit of a kingmaker in what content gets bespoke tags. Ads have to go through amp-ad, where Google also controls which advertisers are allowed on AMP pages, so you're allowed to show ads from the Doubleclick network, but not from The Deck or Carbon networks. Oh, and Google rehosts your AMP pages, so you don't even get to see traffic data to your own content.
This is a massive landgrab by Google that only incidentally solves a real performance problem on the web.
So after 2 decades of dealing with really bad cross browser incompatibilities that we are just now emerging from we are going to dive into cross search engine incompatibilities to an even greater extent.
AMP for Google, something else for Bing, another format for duck duck go, one more for yahoo...ugh!
I work in developing markets, and am really excited for AMP. The web on 2g networks is a horrible experience -- imagine browsing the web today at netscape-era speeds.
My only big gripe with AMP is it's only built for publishing. It's missing a key feature of making the web complete: the ability for users to interact (ie no forms).
Completely agree. But instead of adding another layer of complexity and bullshit on top of the existing stack, why not just take away the existing layers of bullshit and complexity?
I like the premise behind AMP, but we already have a solution for that. This is just another attempt to lock sites into google.
We already had a solution in theory, but that's worth little when in practice we've had a mess that was rapidly getting worse with no sign of turning around. AMP is not the optimum, but it's actually happening, and it's one heck of a lot better than most of the status quo.
The only reason AMP is happening is because Google ignored the original problem for so long. If they had payed attention, we wouldn't be in this crappy situation in the first place. This is just them making another power grab and pretending it's for everyone else's benefit.
I don't see why they need to highlight these pages. Apparently they already use page load speed as a signal in their search rankings. Why not just increase its importance?
> I don't see why they need to highlight these pages.
To lock more sites into their system. Sure, they don't need to, but it's definitely beneficial to them.
> Apparently they already use page load speed as a signal in their search rankings.
I hear this a lot too, but I don't think they really place much importance on load speed. Try searching for "weather", and see how many sites are slow to load, but are at the top of the list. Meanwhile fast-loading sites like http://myfreeweather.com/ are buried in the results.
I have no insight to the other multiple factors of their ranking algorithm, but I've never found speed to play much importance.
Because increasing its importance could be seen as tampering with the results for their own benefit, i.e. pushing a web-technology that they control. Adding a flag to it is sort of the same, but I'm guessing they are testing the waters with this and if they don't get legal repercussion, they'll actually change the search rankings.
No I'm not saying they increase the rankings of fast AMP pages. I'm saying increase the rankings of pages that are fast regardless of the technology they use. You can have a fast page with normal HTML.
The evidence seems to suggest that the push for AMP us all about making sure Google gets its ad tags hardcoded on your pages. Otherwise, Google could release a YSlow type package of best practices. I believe it once considered doing this under the title Page Speed Project.
I disagree because the <amp-ad> tag [1] supports many non-Google ad networks. It doesn't force you to use Google's services at all.
It seems to me that they used this particular approach because best practices are a lot easier to ignore or misinterpret than AMP's "your page will literally break if you try funny stuff". It's why something like TeX was invented rather than releasing a "best practices" package for making Word documents.
Really? I tried it but I always found the Google results much better, especially when you're on the hunt for a weird error you're getting or a bootlegged copy of something obscure.
Since google stopped substring matching and started picking and choosing on it's own which keywords are important and dropping the ones it doesn't like, these things are no longer really working in google search either.
I too feel google results gave been getting worse in the past 6 years. It's hard to describe, but it feels like the internet is somehow getting smaller.
But duck duck go results are still noticeably worse, sadly.
I have the same combined experience of you two posters - DDG is worse than Google and Google is worse unless you start liberally using quotes, which I have switched to doing (and I actually would argue use of these delimiters has improved Google experience).
Yeah, definitely, trying to find actual torrent sites now amounts to adding "magnet" "btih" to your query or you get a bunch of junk spam sites filled with malware.
Yeah, that would definitely be nice. The result quality has definitely gone down noticably, well, at least until I throw quotes on everything. Used to be able to just use "+" in front of terms but of course they killed that too! Still better than duckduckgo with or without though.
Is Google or anyone else making any effort whatsoever to explain this AMP thing to anyone other than Web developers? For weeks, I thought AMP was some sort of news service. I would get news articles that were apparently from someone else, but they said "AMP" so I figured it was some kind of syndicator or something. I tapped on the "AMP" and the lightning bolt thing and nothing happened. So I gave up on figuring out what it was and then I stumbled on some story like this one.
Does Google just not care that people do not know what this thing is?
I'm not sure if I don't like AMP... Sometimes the page looks better and sometimes it doesn't. Sometimes you try to find a comments section that isn't there because it was amped out.
AMP pages are pretty finicky for me (and still only top stories).
That's under the control of the publisher, so it's up to them to make decent amp versions of their pages, it's not a fundamental limitation of the format. Agreed though that in some cases, these sites are throwing up an amp version that is simply inferior.
AMP makes pages fast by forcing you to drop all the website fluff. Most will argue that fluff is not needed on mobile sites (I agree)... but try telling your client that.
Well, if you include in your discussion that most internet traffic is now mobile, and mobile users want quick access, and Google is giving them a way to distinguish whether you site will likely be quick (AMPed) or possibly not, and it may be in their best interest to signal to users that they provide a good mobile experience, it might go smoother.
Unless I'm misunderstanding you, believe you're talking about the search result redirects that Google does; which is different, because the user get redirected the the real URL.
AMD'd links never redirect, if you click the X you're sent back to Google's results, there's no way to get to the real URL that an average user would easily be able to do, if the link is bookmarked the link it's not the real link, etc.
They "hijack" the search result url on any result. If you copy the address from the search result link, you always get a google link. But you could be talking about another url.
I'm fine with AMP as long as i can get a link to a result that is opted out of it. Which i did not see a way to easily do, recently. So basically, I'm not fine with AMP.
Because SPOF's are bad. Not just from an architectural perspective, but from a privacy, independence and total systematic perspective. You want to be an agent in between me and the Internet that basically caches a fast version of everything after being pushed through your systems? Let me opt out.
Has anyone who implemented AMP on their personal site actually seen the AMP result show up in search? I implemented AMP some time ago just for fun and I see no sign of it in search results for my blog. The AMP validation tool as well as the Search Console say there are no problems.
I hate the Google News AMP section from my phone. I don't know if related but it seems to have also disabled opening google news results in new yabs on Firefox on Android ever since they changed the page.
My hypothesis, as someone who doesn't work on AMP, is it forces people to copy/paste the boilerplate rather than writing their own version (and maybe getting it wrong).
I think he's implying the use of an emoji in the html tag is kind of ridiculous. Personally, I'm split being it being ridiculous and being pretty cool.
The end user will stay longer on Google and Facebook. That's what they want.
Anyway, it feels pretty broken on iOS.
Would be great if Adblockers would mangle the Google search results to replace the AMP links with proper links to the full website of e.g. WashingtonPost.
The best part about AMP is it provides an incentive for major content publishers to create non-bloated pages. Without the AMP standards marketing teams start adding "all of the things" causing page loads to become much heavier.
I like amp but what is with responsive pages? I thought the best practice went towards not serving a different page for mobile users and have everything full responsive.
Now with amp, the opposite seems to be the case
Any ad network folks here care to weigh in on how you view AMP and its impact on the industry? Seems like a major moat-building exercise ala FB Instant Articles since Google has all the leverage with publishers.
The change is still rolling out and is not yet available for all users. But if you search for something like "obama" you can see AMP already in use in the "Top Stories" section of the results page
(1) It prescribes a stripped-down version of HTML and uses a JS loader to render fast and load as much resources as possible asynchronously
(2) It caches the website in the Google CDN and delivers it via HTTP/2
By applying best practices of structuring web applications and optimizing for the critical rendering path (1) can be achieved, too. The AMP loader is just an opinionated way to do this for simple pages. Everyone can get similar results without AMP by following web performance best practices like [1]:
- Reducing the critical resources needed
- Reducing the critical bytes which must be transferred
- Loading JS, CSS and HTML templates asynchronously
- Rendering the page progressively
- Minifying & Concatenating CSS, JS and images
And there is lots of good tooling for this (e.g. postcss, processhtml, cssmin, UglifyJS, imagemin, critical, gulp-rev-all, ...)
(2) is not only harder. It is what limits the broad applicability of AMP. Cached data in the Google CDN cannot be invalidated, neither in the CDN itself nor in ISP interception caches, corporate proxies or the browser cache [2]. The effective consequence of this is that you can only use AMP when the content is mostly static. This is the case for news websites or other publications that are only changed by human editors. It completely breaks down when you try to create a dynamic site, for example a social network or a shop.
That is why our startup Baqend [3] takes a different route. We say that developers are clever enough to use existing tooling to achieve (1): an efficient rendering and loading experience. And for (2) we add a caching scheme that also employs CDNs for delivery but keeps data consistent. This is made possible by a simple process:
1. When a browser connects to a Baqend-based website, it loads a Bloom filter containing all potentially stale cached URLs.
2. Every stale URL is requested using HTTP revalidation to refresh stale copies and update caches.
3. When an update operation changes a resource (e.g. an image, JSON object or even a complex query result) its URL is instantly invalidated in the CDN [4] and marked as stale in the Bloom filter.
4. When loading resource, a statistical estimation of the expected TTL (cache liftime) is made. Whenever that prediction fails, the Bloom filter and the automatic CDN invalidation compensate the difference between estimation and real lifetime.
Using this scheme (developed at the University of Hamburg in cooperation with Baqend), every kind of dynamic data can be treated as cachable data and the applicability of is not limited to data that seldomly changes and even works for write-heavy resources with rich consistency guarantees (Δ-Atomicity, Read-Your-Writes, Monotonic Reads, Monotonic Writes, Causal Consistency) [5].
Of course I'm biased but you'd like to see AMP-like acceleration coupled with fresh cached data plus tooling, layout and frameworks of your choice, have a look at our Backend-as-a-Service.
AMP also forces precalculated layout of the page and disables bad CSS selectors. You can take a page, take out all the JS cruft, and put all the resources on a CDN, and still end up with mobile layout adding 500 milliseconds to the initial page render, or more, if relayouts are triggered during render.
The majority of regular web developers aren't even aware of layout costs.
You know I don't understand this whole AMP'd thing. It's possible to make something just as efficient if you don't ruin your mark-up to begin with. The big advantage with AMP, as far as I can tell, is the Google caching mechanism. There is no reason someone can't use actual standards to create the exact same results.
It really bothers me that, to get preferential treatment, I have to now work with Google AMP and Facebook Instant Articles. If I don't the competition will. We originally had web standards for a reason, now we're doing this non-standard stuff.