Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc). So it's an implicit signal boost rather than explicit. You may think that that's fine and there's nothing wrong with that, but no doubt Google see this as a way keeping users within the Google system as much as possible while they browse.

I'm personally on the fence regarding the whole situation. On one hand, I like less bloat, on the other I don't want a 3rd party involved more than is required in delivering a news article to me.



"It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc)."

So Google is guilty of making things that users want?

"Google see this as a way keeping users within the Google system as much as possible while they browse."

Well, isn't giving users what they want a way to keep them inside your system?

I don't see the point in your comment, are you saying that Google should not be optimizing for what users want?


>So Google is guilty of making things that users want?

Well, I'm a user and I don't want this.

I want Google to not invent a new format for web pages, and instead help make the actual web faster.


"Well, I'm a user and I don't want this."

You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Remember, India has more internet users than the US has people.

And you can just not click on AMP sites if you don't want them.


Indian users are the worst example for this, given the regular 2G connections. Hundreds of KB of JS is not helping this, especially not on low-end mobile devices.


It is helping this when you consider all the JS is cached because they've visited an AMP page before.


No, they are not, that's a misconception. Many low end devices simply lack the capacity to efficiently cache this many things, so they are going to re-download it once it's purged.

For the downvoters: https://danluu.com/web-bloat/


Many low end devices simply lack the capacity to efficiently cache this many things

Very low-end devices still have an outrageous amount of memory and storage compared to the scopes we're talking about. In the actual anecdotes of people in India expressing their good user experience with AMP, actual results seem to differ.

But as a North American with a GS8 and a very fast LTE connection, I still love getting AMP results. Just confining to best practices is alone worth it.


Oh I see. So low end devices in india which are predominantly android smart phones do not have the capacity to cache 500kb of frequently used JS?

Reducing the overall page size of a given page doesn't help

Optimizing rendering for content first and images loaded as required doesn't help

Serving pages from a super fast global CDN doesn't help

And prefetching content behind the scenes also doesn't help

I think you should take these to Google because it seems like they've totally goofed this AMP thing!


All those 500KB JS adds up, and the memory on those devices are shared with the fb, twitter, whatever bloatware apps.

And yes, amp is a horrible idea. Block ad networks instead.


"All those 500KB JS adds up, and the memory on those devices are shared with the fb, twitter, whatever bloatware apps."

No, those are pushed out of memory.

"And yes, amp is a horrible idea. Block ad networks instead."

Well, just don't access any ad-funded content. You can't have the cake and eat it too.


>You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Yes, but the typical internet user has never heard of AMP and wants it even less...

>Remember, India has more internet users than the US has people.

Which can always use simple lightweight html pages instead of AMP with its JS cruft?


"Yes, but the typical internet user has never heard of AMP and wants it even less..."

But they might have seen the icon, and realized it means "it loads fast!", and they want it.

Users want faster pages, we can agree on that, correct?

They don't know what AMP is, and don't care about it.

"Which can always use simple lightweight html pages instead of AMP with its JS cruft?"

You can, but no publishers seem to want to do so. But you can. AMP is optional.


> But they might have seen the icon, and realized it means "it loads fast!", and they want it.

Imagine your country's water sources are filthy and crappy. Your tap water literally stinks - all of that because of unrestricted commercial development. Now imagine that to solve this problem, your government created a certificate mark (Aqua Model Premium, complete with a cool icon), which can be issued to bottle water companies who meet a set of water quality criteria.

People want clean drinking water, they might have seen the AMP icon, so they'll go and buy the water bottles from government-certified companies, right?

(Oh, and let's not forget the criteria are written in such way that the bottle companies can literally shit in the bottle, as long as they use government-certified shit dispensers for that.)

Or how about the government starts issuing penalties to water delivery companies and to those who pollute rivers, until the tap water again meets the AMP criteria?

It's not a perfect analogy (Google is not a government, but it kind of owns most of the web as we know it), but it's more-less how I see this situation. Google already penalizes some bloat; they could push this much further (especially for mobile searches) instead of creating a new pseudo-standard.

The point being, as a solution for bloat, AMP is at best a workaround. But as this article proves, it's not even an effective workaround - AMP pages are free to include all the usual resource-heavy crap, just through a new set of "AMP-optimized" JS libraries.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: