Standardizing lessons learned from AMP • Hacker News Board

Re: Standardizing lessons learned from AMP

#91

Post by TheCoelacanth » Fri, Mar 09, 2018, 4:52 PM UTC

beokop wrote: post #70

Ajedi32 wrote: post #56

Earlier quoted context omitted.

Fair point, but that problem (at least as far as AMP is concerned) is exactly the one this blog post is addressing: Google is planning to stop pushing AMP specifically in its search results and instead push a set of open web standards which achieve the same technical goals.

Even so, I’m tired of jumping through hoops to adhere to bullshit standards that make life hard without any actual benefit. We have HTML and CSS, why do we need AMP? How does my personal webpage benefit from HTTPS? Why did they enforce mandatory HTTPS across the entire .dev TLD in WebKit, breaking my local test env, when it’s only used by a few internal projects at Google? They seem to have a vested interest in makin…

> How does my personal webpage benefit from HTTPS?

It prevents bad actors like ISPs or public WiFi APs from injecting bullshit into it.

Re: Standardizing lessons learned from AMP

#92

Post by Ajedi32 » Fri, Mar 09, 2018, 10:27 PM UTC

dmitriid wrote: post #87

Ajedi32 wrote: post #45

Earlier quoted context omitted.

And yet, AMP has succeeded at getting publishers to deliver fast and performant pages where other efforts did not. I dispute the idea that technological factors are not at play here. AMP's preloading and automatic CDN caching system have a pretty big impact on load times, and its technically-enforced restrictions on what sort of performance-impacting content publishers are allowed to include in their pages seems to d…

- Open Chrome - Open Chrome Dev Tools - Switch to mobile view (to force chrome open AMP pages) - Search in Google - Open an AMP page - Force refresh to force reload from cold cache I've yet to find a page below 1 MB. I've routinely seen pages anywhere from 2 to 4 MB. So much for "slimmed down performant webpages". The only reason they are "performant" is Google preloading them while you search

Check out the non-amp versions of those pages though.

First example I got (via searching Google for "news" and clicking the first AMP link).

AMP: https://www.google.com/amp/s/www.sfgate.com/crime/amp/Active... (2.4 MB, loaded in 760ms)

Non-AMP: https://m.sfgate.com/crime/article/Active-shooter-reported-a... (4.7 MB, loaded in 7 seconds)

The non-AMP page is twice as big and takes an order of magnitude longer to load. So, yes. I would _absolutely_ describe the AMP version as a "slimmed down performant webpage".

Could it be better? Of course! But users are still _much_ better off with AMP than without, at least in terms of performance. (And that's ignoring the fact that preloading is part of AMP. It's not "cheating" if it works in a real-world situation.)

Re: Standardizing lessons learned from AMP

#93

Post by siimtalvik » Sat, Mar 10, 2018, 5:52 PM UTC

Ajedi32 wrote: post #31

ocdtrekkie wrote: post #8

Earlier quoted context omitted.

The fact that Malte is still trying to call the AMP project "well-lit" is really what throws a lot of question on this blog post. AMP is not a "well-lit" project. Why not hand AMP itself over to standards groups as well as all of the other things mentioned here? What about the proprietary GMail implementation of AMP4Email? Or the fact that none of the justifications for AMP given in this (or The Verge interview[0]) h…

> AMP is not a "well-lit" project. How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.

With difficult discussions being locked and limited to collaborators.

With the main answer to questions being, we can discuss this somewhere else, some-other (unknown) time in the future, usually in a more private setting. Unless pressed further.

Case in point: https://github.com/ampproject/amphtml/issues/13457#issuecomm...

Or as carmforce(Ubl) so nicely put it. "our project, our rules" but those rules keep changing, are not public and the raised issue about defining/clearing up those rules is obviously not a priority.

https://github.com/ampproject/amphtml/issues/13597#issuecomm...

https://github.com/ampproject/amphtml/issues/13603

Re: Standardizing lessons learned from AMP

#94

Post by dmitriid » Sun, Mar 11, 2018, 10:51 AM UTC

Ajedi32 wrote: post #92

dmitriid wrote: post #87

Earlier quoted context omitted.

- Open Chrome - Open Chrome Dev Tools - Switch to mobile view (to force chrome open AMP pages) - Search in Google - Open an AMP page - Force refresh to force reload from cold cache I've yet to find a page below 1 MB. I've routinely seen pages anywhere from 2 to 4 MB. So much for "slimmed down performant webpages". The only reason they are "performant" is Google preloading them while you search

Check out the non-amp versions of those pages though. First example I got (via searching Google for "news" and clicking the first AMP link). AMP: https://www.google.com/amp/s/www.sfgate.com/crime/amp/Active... (2.4 MB, loaded in 760ms) Non-AMP: https://m.sfgate.com/crime/article/Active-shooter-reported-a... (4.7 MB, loaded in 7 seconds) The non-AMP page is twice as big and takes an order of magnitude longer to load.…

My personal non-AMP page weighs ~800 KB (including all images and JS). It still has no chance in hell competing against a 2.4 MB AMP page because I don't have Google's CDN.

Even if I follow all of Google's own performance guidelines, it won't help, as AMP pages load faster than text-only http://motherfuckingwebsite.com

> It's not "cheating" if it works in a real-world situation.

No. It's still cheating. Even if it works

Re: Standardizing lessons learned from AMP

#95

Post by Ajedi32 » Mon, Mar 12, 2018, 1:51 AM UTC

dmitriid wrote: post #94

Ajedi32 wrote: post #92

Earlier quoted context omitted.

Check out the non-amp versions of those pages though. First example I got (via searching Google for "news" and clicking the first AMP link). AMP: https://www.google.com/amp/s/www.sfgate.com/crime/amp/Active... (2.4 MB, loaded in 760ms) Non-AMP: https://m.sfgate.com/crime/article/Active-shooter-reported-a... (4.7 MB, loaded in 7 seconds) The non-AMP page is twice as big and takes an order of magnitude longer to load.…

My personal non-AMP page weighs ~800 KB (including all images and JS). It still has no chance in hell competing against a 2.4 MB AMP page because I don't have Google's CDN. Even if I follow all of Google's own performance guidelines, it won't help, as AMP pages load faster than text-only http://motherfuckingwebsite.com > It's not "cheating" if it works in a real-world situation. No. It's still cheating. Even if it wo…

Call it cheating if you want. I as a user still strongly prefer a "cheating" site that loads instantly over a "non-cheating" one that I have to wait 5 seconds to load.