10 ms·

I mean, there are valid concerns over the ethics or intentions behind AMP, but let’s not kid ourselves—it’s definitely damn fast to load. Say what you will abou

by dkh 7y ago

I mean, there are valid concerns over the ethics or intentions behind AMP, but let’s not kid ourselves—it’s definitely damn fast to load. Say what you will about the implications or whatever, but they nailed it in a technical performance sense.

dmitriid 7y ago
They didn’t. It only loads fast because tgey aggressively preload AMP scripts when you search. A cold load is hardly performant.
- boromisp 7y ago
  But that's the point. AMP makes preloading feasible by making it safe.
  - manigandham 7y ago
    Any HTML page can be preloaded. It's even built into modern browsers.
    - londons_explore 7y ago
      Google's entire reason for not using the browser preload function is is violates the users privacy - the site gets to know the users cookies and IP even if they never end up visiting. It's a legit excuse, but not enough if a privacy leak in my opinion to slow down everyone's browsing substantially.
    - lern_too_spel 7y ago
      Indeed. Facebook does this. It deanonymizes Facebook news feed visitors to every third party whose links appear on their news feed. You consider this a better approach? In addition to losing in privacy, it loses in speed because it doesn't prerender the page, and it doesn't know enough to load just the resources needed to render above the fold.
      - manigandham 7y ago
        I don't consider either necessary. Clicking a link and then loading the page works just fine for the web. Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site (and now SSR) is a worse approach than placing loading speed into search results ranking and letting sites optimize the site for everyone with a browser.
        lern_too_spel 7y ago
        > Clicking a link and then loading the page works just fine for the web. No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP. > Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.
        manigandham 7y ago
        No, none of this is needed. Make speed a factor in search results and sites get faster. The single HTML version will get faster for everyone on every device, not just mobile sites from certain platforms. Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
        lern_too_spel 7y ago
        > No, none of this is needed. Make speed a factor in search results and sites get faster. You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to. > AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. If that's the case, why does Bing use it? > It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software. What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with. > Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?
chrischen 7y ago
It's also been consistently buggy. I'm just using a stock iPhone, but maybe 30% of AMP pages just show up blank for some reason.
- millstone 7y ago
  AMP on iOS is profoundly buggy. Rotation, reader mode, and URL bar hiding are routinely broken in all modes. AMP in landscape is particularly unusable. Google should be embarrassed to have shipped this.
  - londons_explore 7y ago
    To be fair, iOS safari is becoming the IE6 of the mobile world.
    - dmitriid 7y ago
      It’s not. They are just not rushing to implement half-baked standards that are being hastily designed and forced down everyone’s throat by a handful of Google engineers.
      - manigandham 7y ago
        What standards are lacking?
        dmitriid 7y ago
        Just an example, quoting Dan Abramov [1]: "Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up)." Service Workers is drafted by 4 people. 3 of them are from Google. [2] A lot of standardisation work on web standards is completely taken over by Google. A lot of discussions on JS and HTML are being handled by the same group of ten or so people who are in every open issue and every open proposal on GitHub. A common thread is "oh yes, we should involve the wider web community that's why we reached out to Angular and Polymer for comments", which are, unsurprisingly, also Google projects. A recent proposal where I saw this happen is a proposal by Apple, Template Instantiation [3] Which is now almost entirely taken over by Google. See for example this issue: [4]. Three engineers from Google decided on the future of the project and chose only Angular and Polymer as the frameworks to talk to. And you can see this everywhere. [1] https://dev.to/dan_abramov/comment/6kh1 https://dev.to/dan_abramov/comment/6kh1 [2] https://w3c.github.io/ServiceWorker/ https://w3c.github.io/ServiceWorker/ [3] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [4] https://github.com/w3c/webcomponents/issues/747 https://github.com/w3c/webcomponents/issues/747
manigandham 7y ago
Hackernews is just as fast to load. There's no amazing innovation with AMP, it's only a fork of HTML to limit what people put on the page, incentivized by higher search result placement.
- hombre_fatal 7y ago
  Does AMP even make sense for a website like HN having user authentication? I sheepishly haven't even seen an AMP page yet because I rarely surf on mobile. But it seems like you'd click into an HN AMP page from google results which of course is cached unauthenticated. And then you'd have to click into the website proper if you want to up/downvote or write a comment.
chrismorgan 7y ago
Strongly disagree. It’s way faster than a badly-implemented strawman (which is most media sites, admittedly), but markedly slower than implementing basically the same thing but without AMP. AMP’s main benefit has been making it harder to do expensive things. (Not impossible, by a long shot; merely harder.) And they’re deliberately planning to scuttle that benefit by allowing you to run your own scripts (see worker-dom). At that point, I believe that the only benefit of AMP will be how Google search treats it, rather than anything about actual performance.
- ocdtrekkie 7y ago
  The fact that Google is also moving forward with AMP4Email, which has nothing to do with fast-loading mobile websites, reveals that the true purpose of AMP is simply to create a Google-proprietary replacement for HTML.
  - lern_too_spel 7y ago
    Another explanation for the name is that it uses a subset of the components of normal AMP, which are all prefixed with "amp-". Microsoft, Yahoo!, and Mail.ru are also moving forward with AMP4Email.
    - ocdtrekkie 7y ago
      As we've discussed previously, the other mail providers are being forced to comply with Google's proprietary format since Google holds a near monopoly on email and they want to remain compatible. It isn't a defense for Google's behavior. And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, a replacement of the open standard everyone agreed upon in HTML5.
      - lern_too_spel 7y ago
        Your conspiracy theory doesn't explain mail.ru. I'm also curious how you explain link aggregators other than Google using AMP caches. > And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, It doesn't support everything that full HTML supports, so this statement is obviously false. > a replacement of the open standard everyone agreed upon in HTML5. That's like saying RSS is a replacement for XML. It's a replacement for Apple News and Facebook Instant Articles, not for HTML5, which it is built on.
deleted 7y ago
[deleted]
buboard 7y ago
- in most cases loading the amphtml page of the website is faster and contains the same article - Wait a few months until amp pages become as heavy, and then heavier than their html counterparts. Amp is at best a hacky temporary patch, it doesnt solve the problem.
underwater 7y ago
The only reason AMP is faster than most webpages is because Google preloads and prerenders the content when you are still on the Google results page. It's not a fair contest. We've seen our HTML pages be consistently faster than our AMP pages when all else is even.
- jsnell 7y ago
  But the whole point of AMP is to make prefetching possible in a safe and privacy-preserving way. The AMP caches are where the big wins come from, and what clearly guided the rest of the design. If option one makes prefetching possible and option two doesn't, why would a comparison with prefetching be unfair? (Signed exchanges could in theory change this and allow safe cached serving and prefetching of arbitrary HTML pages, but the crowd that hates AMP seems to despise signed exchanges even more. Such is life.) Incidentally, there was just a large scale study made on the performance characteristics of AMP in the real world. https://blog.apnic.net/2019/08/08/amp-up-your-mobile-web-experience/ https://blog.apnic.net/2019/08/08/amp-up-your-mobile-web-exp... TL;DR is that the AMP pages from the origin were loading on average in 3.1 seconds compared to 7.7 seconds for the matching HTML. (Not all sites are as diligent as you about keeping their HTML light). And then pre-rendering sped that 3.1 seconds to 1.2 seconds. Though the bandwidth used for the prefetching was more than I would have expected.
  - auslander 7y ago
    > But the whole point of AMP is to make prefetching possible in a safe and privacy-preserving way. Scripts forced on us by biggest Ad company are privacy-preserving? Was it sarcasm?
    - jsnell 7y ago
      No. I could elaborate, but given the tone of your comment it seems pretty obvious you have no interest in that.
      - craftinator 7y ago

by dkh 7y ago

dmitriid 7y ago

They didn’t. It only loads fast because tgey aggressively preload AMP scripts when you search. A cold load is hardly performant.

boromisp 7y ago
But that's the point. AMP makes preloading feasible by making it safe.
- manigandham 7y ago
  Any HTML page can be preloaded. It's even built into modern browsers.
  - londons_explore 7y ago
    Google's entire reason for not using the browser preload function is is violates the users privacy - the site gets to know the users cookies and IP even if they never end up visiting. It's a legit excuse, but not enough if a privacy leak in my opinion to slow down everyone's browsing substantially.
  - lern_too_spel 7y ago
    Indeed. Facebook does this. It deanonymizes Facebook news feed visitors to every third party whose links appear on their news feed. You consider this a better approach? In addition to losing in privacy, it loses in speed because it doesn't prerender the page, and it doesn't know enough to load just the resources needed to render above the fold.
    - manigandham 7y ago
      I don't consider either necessary. Clicking a link and then loading the page works just fine for the web. Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site (and now SSR) is a worse approach than placing loading speed into search results ranking and letting sites optimize the site for everyone with a browser.
      - lern_too_spel 7y ago
        > Clicking a link and then loading the page works just fine for the web. No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP. > Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.
        manigandham 7y ago
        No, none of this is needed. Make speed a factor in search results and sites get faster. The single HTML version will get faster for everyone on every device, not just mobile sites from certain platforms. Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
        lern_too_spel 7y ago
        > No, none of this is needed. Make speed a factor in search results and sites get faster. You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to. > AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. If that's the case, why does Bing use it? > It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software. What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with. > Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?

chrischen 7y ago

It's also been consistently buggy. I'm just using a stock iPhone, but maybe 30% of AMP pages just show up blank for some reason.

millstone 7y ago
AMP on iOS is profoundly buggy. Rotation, reader mode, and URL bar hiding are routinely broken in all modes. AMP in landscape is particularly unusable. Google should be embarrassed to have shipped this.
- londons_explore 7y ago
  To be fair, iOS safari is becoming the IE6 of the mobile world.
  - dmitriid 7y ago
    It’s not. They are just not rushing to implement half-baked standards that are being hastily designed and forced down everyone’s throat by a handful of Google engineers.
    - manigandham 7y ago
      What standards are lacking?
      - dmitriid 7y ago
        Just an example, quoting Dan Abramov [1]: "Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up)." Service Workers is drafted by 4 people. 3 of them are from Google. [2] A lot of standardisation work on web standards is completely taken over by Google. A lot of discussions on JS and HTML are being handled by the same group of ten or so people who are in every open issue and every open proposal on GitHub. A common thread is "oh yes, we should involve the wider web community that's why we reached out to Angular and Polymer for comments", which are, unsurprisingly, also Google projects. A recent proposal where I saw this happen is a proposal by Apple, Template Instantiation [3] Which is now almost entirely taken over by Google. See for example this issue: [4]. Three engineers from Google decided on the future of the project and chose only Angular and Polymer as the frameworks to talk to. And you can see this everywhere. [1] https://dev.to/dan_abramov/comment/6kh1 https://dev.to/dan_abramov/comment/6kh1 [2] https://w3c.github.io/ServiceWorker/ https://w3c.github.io/ServiceWorker/ [3] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [4] https://github.com/w3c/webcomponents/issues/747 https://github.com/w3c/webcomponents/issues/747

manigandham 7y ago

Hackernews is just as fast to load. There's no amazing innovation with AMP, it's only a fork of HTML to limit what people put on the page, incentivized by higher search result placement.

hombre_fatal 7y ago
Does AMP even make sense for a website like HN having user authentication? I sheepishly haven't even seen an AMP page yet because I rarely surf on mobile. But it seems like you'd click into an HN AMP page from google results which of course is cached unauthenticated. And then you'd have to click into the website proper if you want to up/downvote or write a comment.

chrismorgan 7y ago

Strongly disagree. It’s way faster than a badly-implemented strawman (which is most media sites, admittedly), but markedly slower than implementing basically the same thing but without AMP. AMP’s main benefit has been making it harder to do expensive things. (Not impossible, by a long shot; merely harder.) And they’re deliberately planning to scuttle that benefit by allowing you to run your own scripts (see worker-dom). At that point, I believe that the only benefit of AMP will be how Google search treats it, rather than anything about actual performance.

ocdtrekkie 7y ago
The fact that Google is also moving forward with AMP4Email, which has nothing to do with fast-loading mobile websites, reveals that the true purpose of AMP is simply to create a Google-proprietary replacement for HTML.
- lern_too_spel 7y ago
  Another explanation for the name is that it uses a subset of the components of normal AMP, which are all prefixed with "amp-". Microsoft, Yahoo!, and Mail.ru are also moving forward with AMP4Email.
  - ocdtrekkie 7y ago
    As we've discussed previously, the other mail providers are being forced to comply with Google's proprietary format since Google holds a near monopoly on email and they want to remain compatible. It isn't a defense for Google's behavior. And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, a replacement of the open standard everyone agreed upon in HTML5.
    - lern_too_spel 7y ago
      Your conspiracy theory doesn't explain mail.ru. I'm also curious how you explain link aggregators other than Google using AMP caches. > And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, It doesn't support everything that full HTML supports, so this statement is obviously false. > a replacement of the open standard everyone agreed upon in HTML5. That's like saying RSS is a replacement for XML. It's a replacement for Apple News and Facebook Instant Articles, not for HTML5, which it is built on.

deleted 7y ago

[deleted]

buboard 7y ago

- in most cases loading the amphtml page of the website is faster and contains the same article - Wait a few months until amp pages become as heavy, and then heavier than their html counterparts. Amp is at best a hacky temporary patch, it doesnt solve the problem.

underwater 7y ago

The only reason AMP is faster than most webpages is because Google preloads and prerenders the content when you are still on the Google results page. It's not a fair contest. We've seen our HTML pages be consistently faster than our AMP pages when all else is even.

jsnell 7y ago
But the whole point of AMP is to make prefetching possible in a safe and privacy-preserving way. The AMP caches are where the big wins come from, and what clearly guided the rest of the design. If option one makes prefetching possible and option two doesn't, why would a comparison with prefetching be unfair? (Signed exchanges could in theory change this and allow safe cached serving and prefetching of arbitrary HTML pages, but the crowd that hates AMP seems to despise signed exchanges even more. Such is life.) Incidentally, there was just a large scale study made on the performance characteristics of AMP in the real world. https://blog.apnic.net/2019/08/08/amp-up-your-mobile-web-experience/ https://blog.apnic.net/2019/08/08/amp-up-your-mobile-web-exp... TL;DR is that the AMP pages from the origin were loading on average in 3.1 seconds compared to 7.7 seconds for the matching HTML. (Not all sites are as diligent as you about keeping their HTML light). And then pre-rendering sped that 3.1 seconds to 1.2 seconds. Though the bandwidth used for the prefetching was more than I would have expected.
- auslander 7y ago
  > But the whole point of AMP is to make prefetching possible in a safe and privacy-preserving way. Scripts forced on us by biggest Ad company are privacy-preserving? Was it sarcasm?
  - jsnell 7y ago
    No. I could elaborate, but given the tone of your comment it seems pretty obvious you have no interest in that.
    - craftinator 7y ago