I'm a contributor to AMP and also work on Google Search. We're currently investigating the issue of the blank page that's mentioned in the article. So far we've been able to reproduce the issue using the Chrome emulator; however, we haven't been able to repro on an actual device, either Android or iOS. So we'll keep digging into this.
The article also mentions the impact on conversion rate. We're interested to learn more details surrounding this. Blank pages loading for many users would explain a lower conversion rate but we'd like to figure out if there's any other possible cause since it doesn't currently seem like most users hit a blank page in actual usage. I'll get in touch with the article author to see if there's openness to digging in further.
An issue with projects like AMP is you are now essentially solving a completely self-inflicted problem. Nobody required the particular approach that AMP takes, and now site owners have to worry about blank pages for the first time since 300 baud modems?
The solution needs to start in much simpler terms: Google should publish page traits that are rewarded and punished, and tools for seeing where you stand. It should reward/punish all sites based on how they fare in the published areas.
We don’t need new protocols/wrappers/rehosting or extra scripting or whatever else to drag bad sites into the 21st century. These just create additional issues when we have plenty of engineering problems already.
It seems far easier to establish a standardized framework that forces everyone to adhere to it as opposed to trying to get the web to adhere to some nebulous perf standards.
The web has incredible variety in tech stacks, business structures and even views on what a standard means.
> The web has incredible variety in tech stacks, business structures and even views on what a standard means.
But AMP is a standard. Using AMP doesn't solve any of the problems you're talking about. If people's usage is too diverse to be accurately measured, then it's too diverse for AMP to meet everyone's needs. And if it's not important for AMP to meet everyone's needs, then why is it important for a set of page tests to do so?
I agree there might be problems building a small set of tests to check page speed, but that would still be strictly better than AMP. It would still cover at least all of the use-cases that AMP covers now, and it would open the door to cover more use-cases in the future.
If you're ranking search results based on whether or not someone uses a framework, you are implicitly ranking them based on the attributes of that framework. What people are asking is for Google to make those attributes explicit instead, and to directly test them.
Meh. For all practical purposes, it serves the exact same role as a standard. It's a set of rules/technologies that developers have to follow in order to get preferential treatment in Google search.
I don't particularly care whether anyone thinks that's technically a standard or a framework or a library by the ridged definition or not; at the point we start down that rabbit hole we're just talking about words, not concepts.
What I was trying to get at above was that any problems people bring up around Google profiling websites for search placement are still present in AMP. Forcing developers to use a specific set of technologies is functionally the same as forcing them to conform to a ridged set of benchmarks. For the purposes of this discussion, we might as well call AMP a standard.
To me AMP pages feel like a sort of "preview" for a site. What the linked article describes is actually very accurate about feeling trapped inside Google. I just can't figure out how to get google out of the way and view the site directly.
It's actually to the point that I have stopped using non-browser google search on my phone. In fact I didn't really notice it was AMP just that results from "Ok Google" were annoying as hell after upgrading to Google Assistant. Reading this article was an "oooooooohhhh that's what's going on" reveal to me.
I don't even know where he's getting this "Info" thing. To me it just looks like some sort of chrome window that doesn't let me edit the url. Even when I do "Open in..." to send the link from I guess it's called Amp browser (...that somehow looks like Chrome?) to my browser it leaves me trapped in AMP with weird urls. It's extremely confusing.
I just want to escape to the actual website in an actual browser and for whatever reason I end up having to try and re-find the site in the mobile browser. Maybe there's some obvious way to do this but it's just driving me bonkers.
AMP was one of the reasons that made me fully embrace Firefox mobile on Android. I've almost forgotten about AMP since, as its only supported on blink browsers and you automatically get redirected to the real site even when following an amp link. Not sure about non browser search though, i dont use that.
Firefox Focus is my primary browser on my phone and I did that at first because Chrome started to be really annoying. Or at least I thought that was it but maybe it was just AMP.
When I'm in "dumb user" mode, especially on mobile, I get very irked when I search for something (on Google, because no matter how much I like DuckDuckGo on principle, the results are just not good enough), tap on a link and find myself on a google.com address AMP. It's an irrational response, but I do feel like I've been swindled/misdirected; on mobile in particular it's annoying because if I want to link the page to someone I don't want the AMP link, and the process of getting the "real" URL is several steps too many. Not to mention the valuable real estate taken by the AMP sandwich button toolbar.
My non-technical significant other and my dad have repeatedly asked me if those pages are safe to visit: after training them for years on the heuristic of mistrusting a page where the URL doesn't match the expectation, AMP is now breaking it for them and causing unnecessary insecurity.
For me blank pages happen with content blockers because the content is hidden and there's some CSS animation which unblocks it after 8s if the JS hasn't loaded. 8s might be longer than someone is willing to wait, and either way is always slower than just rendering the content that's already there, sans JS.
Note that "content blocker" is congruent to "resource failed to load", which could always happen.
It's great that you guys are receptive to these issues but I can't help but wonder if, instead of solving this with what is clearly unpopular technology, we all would have been better off if Google had encouraged better practices?
If, as the article implies, Google will give me the same rankings if I do things to get the same performance as an AMP page then I would rather do that.
> It's great that you guys are receptive to these issues but I can't help but wonder if, instead of solving this with what is clearly unpopular technology, we all would have been better off if Google had encouraged better practices?
Unpopular where? Between web devs on HN which are the main cause of the web site bloat plague?
That's quite a big assumption from one usecase without much evidence backing it up. I'm not saying the author is lying but I'd need more data before saying this is a repeatable scenario...
Even the author couldn't narrow down what exactly was the cause other than maybe:
a) the domain name being different
b) the addition of chrome w/ a link to Google support + a notification "You're now logged in as [user]@gmail.com"
c) minor CSS changes as a result of minimizing static assets
None of these screams an obvious problem, especially given the other benefits this process has given in return (which of course could be accomplished without AMP).
Google has been using indicators like page performance in their ranking algorithm for quite a while now, so to be fair, it doesn't look like it helped that much. A single label and clear prioritisation apparently make it a far easier sell within companies.
That might be a more believable explanation of why they did it if they weren't hijacking the content and hosting it on their own domain with left-right swipes that take users off of your site. Users don't actually visit your site, but they visit a restricted shell of it on google.com.
Except there's NOTHING technically requiring google to serve AMP from their own domain. None of the speed benefits can justify that. AMP could just be another standard where the basic lib is preloaded on the browser.
If you want to pre-load the page in the background in search results without allowing the site operator to track the user, they do need to serve it from somewhere they control.
I only ask that you stop working on this shitty preview system you call AMP. I don't want preview versions of websites. I don't want broken pages that fail to load.
I don't trust google.com to host sites that aren't google.com.
what about amp pages not displaying a link to get to the actual source site? almost every time I open a link from my Google home feed it fails to display that header with the source URL link. I then have to manually force it to chrome and modify the URL
You assume that they care. Think of the bigger picture. This is not about usability, developer experience, standards or any of that useless shit. This is about control, which in the long run turns into money.
The article also mentions the impact on conversion rate. We're interested to learn more details surrounding this. Blank pages loading for many users would explain a lower conversion rate but we'd like to figure out if there's any other possible cause since it doesn't currently seem like most users hit a blank page in actual usage. I'll get in touch with the article author to see if there's openness to digging in further.