Standardizing lessons learned from AMP • Hacker News Board

The thing that makes the web slow isn't web standards, but too many ads and too much tracking code. If only there were a company that controlled a lot of the ads and tracking code on the web...

Re: Standardizing lessons learned from AMP

#16

Post by jashkenas » Thu, Mar 08, 2018, 7:12 PM UTC

Just for kicks, folks, let's collect all of the adjectives, adverbs and qualifiers used in this post to describe ~AMP:

    * a leading format
    * consistently excellent
    * invest strongly in ...
    * well-lit
    * user-first
    * instant-loading
    * tightly-integrated
    * highly-optimized
    * great
    * well-lit
    * great
    * well documented
    * easily deployable
    * validatable
    * opinionated about user-first principles
    * fast development
    * constant adjustment
    * more important than ever before
    * invest strongly in ...
    * engaging storytelling experiences
    * pushing the boundaries
    * deep integrations
    * well under way
    * super excited
    * instant-loading
    * well-lit
    * great
    * continue to invest heavily in ...
    * continue to innovate on ...
    * incredibly excited
    * can't wait

I'm imagining a Dilbert cartoon, where this list is a cheatsheet of things you can say about your project to get approval from your pointy-haired boss...

Re: Standardizing lessons learned from AMP

#17

Post by skybrian » Thu, Mar 08, 2018, 7:13 PM UTC

ocdtrekkie wrote: post #8

dmitriid wrote: post #6

A lot if big words disguised as good intentions. There’s nothing fast, instant, or open about AMP. The latest article debunking those myths: https://ferdychristant.com/amp-the-missing-controversy-3b424... Google’s fully opaque process around AMP for email (yes, it’s a thing): https://github.com/ampproject/amphtml/issues/13597 and https://github.com/ampproject/amphtml/issues/13600

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…

Handing over AMP would prevent the standards committee from making backward-incompatible changes to please other participants. It seems better to start fresh and have a compatibility break? Not to mention that there's little point in preserving a name that's pretty controversial.

And in the meantime, AMP would still need to be maintained.

We've seen this before in less controversial areas. For example, SPDY was proprietary and HTTP/2 is a standard that entirely replaced it.

I'm wary of AMP4Email as well, but the process of doing something quick and dirty and then standardizing the 2.0 version (under a different name) is pretty common.

Re: Standardizing lessons learned from AMP

#18

Post by ocdtrekkie » Thu, Mar 08, 2018, 7:18 PM UTC

skybrian wrote: post #17

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…

Handing over AMP would prevent the standards committee from making backward-incompatible changes to please other participants. It seems better to start fresh and have a compatibility break? Not to mention that there's little point in preserving a name that's pretty controversial. And in the meantime, AMP would still need to be maintained. We've seen this before in less controversial areas. For example, SPDY was propr…

Google is not replacing AMP, or promoting the standards group to replace AMP. Google is using things like web packaging with AMP, and intends to continue to do so. Their statements today, if anything, state a clear intent to continue to invest in and build on AMP.

So, while all of these other components are going to be going to standards orgs, why not let them also have AMP? (A standards org is never beholden to keep an existing standard, they can always make a new one.)

Re: Standardizing lessons learned from AMP

#19

Post by [deleted] » Thu, Mar 08, 2018, 7:25 PM UTC

jashkenas wrote: post #16

Just for kicks, folks, let's collect all of the adjectives, adverbs and qualifiers used in this post to describe ~AMP: * a leading format * consistently excellent * invest strongly in ... * well-lit * user-first * instant-loading * tightly-integrated * highly-optimized * great * well-lit * great * well documented * easily deployable * validatable * opinionated about user-first principles * fast development * constant…

[deleted]

Re: Standardizing lessons learned from AMP

#20

Post by wolfgang42 » Thu, Mar 08, 2018, 7:26 PM UTC

andrewn32 wrote: post #14

Haven't tried this myself but came across this interesting AMP workaround: https://www.goinflow.com/amp-mobile-pagespeed-score/

Not related to AMP but this caught my eye:

> From a peak of 1.9% conversion rate at around 2 seconds

This sentence and the graph it accompanies seems to imply that if your site is too fast it could reduce your conversion rate. What's going on here?

Well, at the bottom of the article that graph came from:

> What about all those fast pages with low conversion rates and high bounce rates?

> Good question. Faster pages should retain and convert more visitors, right? In general, yes, but some of the speediest pages on a site are 404/error pages, hence the poorer business metrics.

It seems like you'd want to control for this, to get statistics on bounce rates only for pages that wouldn't otherwise bounce the user anyway.