Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMP: the missing controversy

ferdychristant.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: AMP: the missing controversy

#111

Post by gorhill »

JoshMnem wrote: post #29
ddmd1 wrote: post #21

Earlier quoted context omitted.

Google already has your IP; it's their page. Preloading resources from it's own CDN doesn't tell them anything they don't already know. Preloading resources from someone else's domain would.

Google doesn't have a list of everything you do online unless you're loading resources from their servers after you leave their site. AMP always loads from Google. If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.

> If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.

The pages load fast, they are just styled to not be visible until after 8 seconds.

For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock:

    scientias.nl##body:style(animation: none !important;)
With an extension such as uMatrix or NoScript, blocking first-party scripts will cause `noscript` tags to be rendered, and one of these tags disable the CSS animation, causing the page to appear immediately.

When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay.

The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.

Re: AMP: the missing controversy

#112

Post by ocdtrekkie »

cromwellian wrote: post #84
ocdtrekkie wrote: post #2

We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, an…

The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want.

But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.

Re: AMP: the missing controversy

#113

Post by sseth »

philipwhiuk wrote: post #97
sseth wrote: post #86

AMP is one of a long series of Google's efforts to ensure the web remains competitive with walled gardens and native platforms. Chrome (with the V8 engine), NaCl, SPDY, QUIC, PWA, Dart, Certificate Transparency ... the list goes on and on. Some have succeeded (SPDY became HTTP/2) and some have failed (Dart, NaCl), but it has been consistent at least. Standards cannot become a strait-jacket. In many cases (such as HTT…

Neatly ignoring the fact they own and build one of the walled gardens.

AMP at the end of the day is an open source javascript library. The pages accessible on AMP via the cache, can also be accessed directly if you want. I don't see this as a walled garden - having a cache does not mean the content is not available outside the cache.

Google does not do this out of altruism of course - their margins on web search are much higher than on mobile, and if more and more content exists only in mobile apps and walled gardens they will lose revenue.

Re: AMP: the missing controversy

#114

Post by sseth »

dmitriid wrote: post #100
sseth wrote: post #86

AMP is one of a long series of Google's efforts to ensure the web remains competitive with walled gardens and native platforms. Chrome (with the V8 engine), NaCl, SPDY, QUIC, PWA, Dart, Certificate Transparency ... the list goes on and on. Some have succeeded (SPDY became HTTP/2) and some have failed (Dart, NaCl), but it has been consistent at least. Standards cannot become a strait-jacket. In many cases (such as HTT…

AMP is not open web though. It's Google's own walled garden under the guise of an open web.

As a javascript library it is pretty much as open as React or any other javascript platform.

It is the caching where the discussion lies - effectively Google is providing a CDN for AMP pages and I agree this needs some improvements. But these should in the realm of technical discussions rather than looking for conspiracies.

Re: AMP: the missing controversy

#115

Post by cromwellian »

dmitriid wrote: post #92
cromwellian wrote: post #84

Earlier quoted context omitted.

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, an…

Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it. At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules . Nowhere does…

The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render.

You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.

Re: AMP: the missing controversy

#116

Post by cromwellian »

ocdtrekkie wrote: post #112
cromwellian wrote: post #84

Earlier quoted context omitted.

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, an…

The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want. But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.

Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is the kick-in-the-butt that is needed to get the ball rolling, and like asmjs, it is nothing more than a subset of the standard web and works on all browsers and sites, albeit with different performance characteristics, just like asmjs's introduction.

Re: AMP: the missing controversy

#117

Post by mulmen »

Avshalom wrote: post #58
mulmen wrote: post #37

Earlier quoted context omitted.

I disagree with your defeatist message and I consider it harmful if spread. Individual action is the foundation of our entire social system. It is not "useless" by any measure. I don't want to use AMP in email so I'm not going to. It's just that easy. What are you doing and what do you suggest the rest of us do? Is voting with our wallets not a thing any longer?

And how productive do you think "voting with our wallets" can be for a product we don't pay for from a company with more money than all of us combined?

You're right, we should just use Google for everything because they have money. All is lost. Thanks for opening my eyes, you have really made a positive impact.

/s

On a serious note I don't like the negativity in your comment and I don't think there is anything insightful about it. I believe the free market is based on individual actions. I will continue to choose services based on how well they serve my needs.

Re: AMP: the missing controversy

#118

Post by fchristant »

cromwellian wrote: post #115
dmitriid wrote: post #92

Earlier quoted context omitted.

Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it. At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules . Nowhere does…

The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render. You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools a…

You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page.

The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.

Re: AMP: the missing controversy

#119

Post by fchristant »

ocdtrekkie wrote: post #2

We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…

hi, I'm the author of the article. I have no idea how to stop it. Bad press doesn't seem to matter, as this has been around for years.

One longshot I could think of is reporting it to the EU as anti-competitive behavior. In the case of exclusive AMP preloading on a dominant market (search), it's not that far fetched.

Re: AMP: the missing controversy

#120

Post by fchristant »

ec109685 wrote: post #56
jsnell wrote: post #24

> If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well. ... but they've been doing exactly that for ages. Originally with link rel=prefetch, and later with ever more elaborate schemes which I think culminated with this: https://plus.google.com/+IlyaGrigorik/posts/ahSpGgohSDo But prefetching based on giving hints to the browser has a…

Yes, exactly. They (Google, others) cannot instantly load arbitrary websites because those sites would have access to the google.com domain in an unsafe manner. That is why AMP is “different” than other HTML. It is a safe way to allow Google, Twitter, Bing, Yahoo Japan and others to cache pages and preload/prerender them in the background before the user clicks.

We have to differentiate between prefetching from search and prefetching from the actual page being opened.

Google CAN preload arbitrary websites. They fully load your website, JS included, when they index it. As for the security problem when on google.com, they could still preload the HTML, CSS, webfonts, do all the DNS/HTTPS overhead, all of which would be safe to do, save those first few seconds, and create a level playing field.

Post reply on HN