Live data from Hacker News

Kill Google AMP before it kills the web

theregister.co.uk

351–360 of 489 posts

Re: Kill Google AMP before it kills the web

#351
post #246

Earlier quoted context omitted.

The main problems I have are that it breaks two really important web features: sharing links and trust. Users seeing google.com URLs means they trust them more, which has helped propaganda sites and phishers. The other thing is that for me, AMP has not been faster many times. I know they're working on it but having to download and run 100KB of external JavaScript before rendering frequently meant that it was slower t…

Tap the link icon at the top of the page. Then long press the URL that appears. Or short press it then use your browser's share menu.

That's also not an alternative — Google can't be allowed to treat pages different in their results just for using Google's AMP Cache.

An AMP page served without cache has to be treated the same, or this becomed exactly the freedom issue that this entire discussion is about.

My pages are actually optimized a lot, and they actually get about 10x slower with AMP than without.

I don't want to have to choose between fast loading and good SEO, I want both. And Google only offering good SEO to those who let Google track all user interactions with their page is also not ideal (I specifically do not use any ads, analytics, or tracking, not even storing IPs in the server logs).

Re: Kill Google AMP before it kills the web

#352
post #258

Earlier quoted context omitted.

They didn't explicitly set the behavior that way, but they deployed it knowing that WAS the behavior. And they didn't bother to change it or give anyone an option to turn it off or do something else making everyone on iOS suffer since they started pushing AMP. They could've just as easily pushed you to a new page which contain the AMP content and wasn't an iframe, thus leaving all the standard feel and gestures worki…

I don't have an iPhone, so I can't check the actual behavior to see how broken it is. Is it just not fitting the Norms of the platform, or does it really impede usage? I think the "correct" response in a case like this, where the platform owner has a bug and has committed to a fix in the pipeline for delivery, is highly dependent on the problem. Even then, it's possible to make the wrong choice given the information…

I don't think it was a bug, I think it was an intentional choice by Apple but I don't think it really mattered to most people untill AMP started using it.

The big problem with that that only exists on iOS is that the 'weight' of the content is much much less than normal web pages. All your muscle memory of how far and how fast to move your finger to get the page to scroll a certain amount is wrong. Instead the page scrolls MUCH faster and further. This would be bad enough except you're still technically on the Google page and as soon as you go back or close the AMP result the scroll speed is what you're used to.

The end result is it's incredibly frustrating and feels "broken".

I understand that Google's preferred solution caused a behavior that is severely sub optimal because of the way Safari currently works. My problem is I think they handled this extremely poorly and forced all iOS users to deal with it for what, over a year?

I'm glad apples fixing it but I don't like the way Google handled it... effectively saying to iOS users "too bad" since they didn't do anything to mitigate it while waiting for Apple's fixed to come through the pipeline.

Re: Kill Google AMP before it kills the web

#353
post #83

Earlier quoted context omitted.

>Content should remain on the publisher's site. Publishers are free to implement their own cache and host their own content. AMP is open source and they can modify it however they like.

Publishers already host their own AMP content. Google caches that content, but anyone can go to the publisher's URL and get it directly. Disclaimer: I work for Google and have some involvement with AMP.

Well, I suggest you start giving AMP content that isn't in Google's cache the same preferred treatment in search results that you give cached content.

I'm just going to file another complaint to the EU Antitrust committee otherwise, as this is a simple and clear violation. (Although I doubt my own complaint would be very relevant — all large publishers already have filed such complaints, and Google will be fined for it).

My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)

I have the choice between a massively worse user experience, or worse search ranking. And that's a choice that's just not acceptable to me.

Re: Kill Google AMP before it kills the web

#354
post #316

Earlier quoted context omitted.

Such a solution has existed for at least a decade: ad blocker :)

Do ad blockers really solve the problems that this article criticizes AMP for? You've closed one bag of worms and opened another one. How can independent publishers live in an all adblock world? State publishers like criticized in the article might survive. You're again centralizing journalism, this time into the few organizations that can get their readers to pay a subscription.

I think that the ones that will best survive in an ad-blocking world would be hobbyist journalists and bloggers. That does not seem to be that bad to be quite frank as it would probably lead to higher quality content, less copy-paste and less clickbaits.

Re: Kill Google AMP before it kills the web

#355
> it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view

Is that what was happening. It just felt like scroll was spazzing out. Usually I was just trying to push a button near the top of the screen.

Re: Kill Google AMP before it kills the web

#356

I do not understand the dislike this community harbors for AMP. I personally really enjoy the system; whenever I'm searching for any type of article on my phone (Android), I prefer AMP pages, because they load faster and are far more responsive than some of their more bloated counterparts.

This community hates AMP the cache, AMP the centrally controlled place for all news which Google can easily manipulate or censor if a totalitarian government should ask them to, the AMP that gives pages an advantage in search results only if they let all their content go through Google.

No one's complaining about AMP the web framework — which is the part responsible for the performance and responsiveness.

Re: Kill Google AMP before it kills the web

#357
post #188

Earlier quoted context omitted.

Security isn't everything.

Remember what happened just over a week ago to the NHS and all sorts of other computers? Security is becoming EXTREMELY important, although it was already pretty important. Apples very strict (occasionally draconian) app model on iOS is one of the reasons it has so few problems with the software destroying the system or viruses or other such things. There's a reason Microsoft is eyeing it jealously for Windows. That…

[deleted]

Re: Kill Google AMP before it kills the web

#358
post #202

Earlier quoted context omitted.

Sorry, but there is some irony there. We were as surprised as anyone. I do like the new inertia much better. Allows for much faster scrolling similar to Android.

I don't think there's any irony here. You deployed something that worked horribly on iOS, you didn't offer a way to opt out, and when someone else put in a fix for your terrible UX that just happens to change everything else to the way your stuff currently works you use it to gloat and a guy who pointed out how terrible your UX was. Honestly this whole thing (AMP and your comment) come off arrogant as hell to me. I l…

This is amazing.

A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work. Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber. In your eyes, this makes it all their fault.

When called out on it, you double down by saying that the team is still to blame because they chose not to work around Apple's bug. You basically want Google to be part of Apple's captive audience.

No, seriously, take a step back and consider that this is what you're saying.

Re: Kill Google AMP before it kills the web

#359
post #341

Earlier quoted context omitted.

Because users seeing AMP links as faster will pressure more sites to do it. Keep in mind, AMP pages on google aren't just fast because you're not using bloated javascript, they're fast because: - The JS that is used is CDN cached and shared with all other AMP sites - You're loading the content from the same origin (google.com) so no need to establish a new TLS connection, or look up DNS, etc - Google's servers/networ…

> What choice do sites have? Offer better experiences on their websites and apps, the technology is available but publishers choose to shovel crap in with food and call it beef tenderloin. Now Google is offering something better. What did you expect Google to do when Apple News Format and Facebook Instant Articles are creeping up? Both offer impressive experiences and this isn't even nearly as impossibly mind-bogglin…

I can?

I'm running my own sites, no ads, mininal content.

How do I get the preferred treatment in the Google sesech that AMP pages get again?

(My pages are all tested on a Huawei Ideos X3 on 64kbps GPRS internet. They always load consistently faster than AMP pages)

Re: Kill Google AMP before it kills the web

#360
post #221

Earlier quoted context omitted.

It's worth pointing out Cloudflare has a competing AMP serving tool: https://www.cloudflare.com/website-optimization/accelerated-...

I haven't yet seen a non Google hosted AMP page in Google's carousel. Does that happen? If not, it's somewhat telling.

No, it does not happen, nor will it ever because that's fundamentally not how AMP caching works. A site doesn't pick an amp cache like they pick a hosting provider, with some sites cached on cloudflare-amp while others are hosted on google-amp. All amp content is on all amp caches. Google search is one AMP client, and it uses google's AMP cache. If, for example, bing wanted to serve AMP pages, they would need to choose an AMP cache to serve them from, and cloudflare's offering would be an option. One of the problems that AMP is trying to solve is individual websites hosting on insufficient architecture. If each site was allowed to choose what AMP cache it was served from, that would defeat the purpose. It's up to the client to choose the cache it uses, to ensure a consistent speed.
Post reply on HN