5 ms·

I have to agree with this but if Google's goal is to make the web faster then the AMP mission can still be done almost exactly as they are doing it today. Just

by Meai 7y ago

I have to agree with this but if Google's goal is to make the web faster then the AMP mission can still be done almost exactly as they are doing it today. Just publish a profiling tool (expanding Lighthouse maybe) that reports the numbers back to Google and then you either get to use their cache and edge servers and get ranked higher or not based on whatever metric that Google wants us to care about. Maybe I'm missing something but that really seems like a much more obvious approach to solving the problem without going through this weird extra webcomponents library, different URL schemes and all that.

joshuamorton 7y ago
> use their cache and edge servers Using the amp cache requires pre-loading content in the end user's browser. That makes things really fast (there is zero request latency to "load" and AMP page), but has security implications. If I stick `window.onload(send a bunch of user analytics to my personal server);` in a preloaded page, than anyone who does a google search where my resource is a result unintentionally loads my page and then has data leaked to me, a random nefarious internet person. So given these two requirements: 1. 0 request latency 2. Prevent data leakage to third parties Come up with a scheme that is different from AMP. Or you can argue that either of these requirements is wrong: that data leakage is okay, or more likely that some low-but non-zero level of latency is alright. But my understanding is that the options are either use something amp-like and get approximately 0 latency, or use something non-amp like, and have latency of 50-100ms minimum on good, wired, HTTP/2 connections for well designed websites, and that becomes really bad, really fast, if you're on a 2g or 3g HTTP/1 connection in rural $wherever that's dropping some packets.
- Wowfunhappy 7y ago
  Perhaps give browsers the ability to load cached content across domains? So, Google would tell my browser to cache this resource, and then when another website requests it, it's already available in my cache. I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs... (Security-wise, the primary thing that comes to mind is you'd want to store and check a hash of any asset cached by a third party, to make sure they're actually the same file.)
  - tiles 7y ago
    And isn't that available today with `<link rel="preload">`?
    - Wowfunhappy 7y ago
      I don't think one domain can preload content for another domain from their own server, but I may well be wrong. If I am, great, Google could do this today.
  - lern_too_spel 7y ago
    You didn't solve requirement #2.
    - Wowfunhappy 7y ago
      How does the third party know the asset was cached if I don't actually visit the third party's page? The CDN (Google) knows all, but that's true with AMP too.
      - lern_too_spel 7y ago
        If that's what you're describing, you've described exactly how AMP works today (though AMP goes one step further and prerenders above the fold, making it instant instead of merely fast).
  - joshuamorton 7y ago
    > I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs... Prefetching cross-domain means that now anyone who loads google.com has the potential to also ping mywebsite.com/trackingendpoint, which is a resource that you have to cache. So I get some information, likely less than if you actually execute the page, but still enough to be worrisome. > It can't be worse than letting websites show fake URLs... I really don't get this complaint. I can absolutely understand the unease people have about "fake urls" but a lot of urls already lie. How many are really cloudflare or aws? It's completely possible I'm missing something, but as far as I can tell, signed http exchanges are more secure than a CDN, since they're signed. I guess that potentially since I, a nefarious person, can re-host your signed content, there might be data leakage possible there, but given that AMP is mostly static, I think that's mostly mitigated. Could be wrong here, I'm not a security (or AMP) expert, but I don't get the fear.
deogeo 7y ago
> if Google's goal is to make the web faster It's not. It's just a means to an end - lock-in publishers, and lure consumers.

by Meai 7y ago

joshuamorton 7y ago

> use their cache and edge servers Using the amp cache requires pre-loading content in the end user's browser. That makes things really fast (there is zero request latency to "load" and AMP page), but has security implications. If I stick `window.onload(send a bunch of user analytics to my personal server);` in a preloaded page, than anyone who does a google search where my resource is a result unintentionally loads my page and then has data leaked to me, a random nefarious internet person. So given these two requirements: 1. 0 request latency 2. Prevent data leakage to third parties Come up with a scheme that is different from AMP. Or you can argue that either of these requirements is wrong: that data leakage is okay, or more likely that some low-but non-zero level of latency is alright. But my understanding is that the options are either use something amp-like and get approximately 0 latency, or use something non-amp like, and have latency of 50-100ms minimum on good, wired, HTTP/2 connections for well designed websites, and that becomes really bad, really fast, if you're on a 2g or 3g HTTP/1 connection in rural $wherever that's dropping some packets.

Wowfunhappy 7y ago
Perhaps give browsers the ability to load cached content across domains? So, Google would tell my browser to cache this resource, and then when another website requests it, it's already available in my cache. I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs... (Security-wise, the primary thing that comes to mind is you'd want to store and check a hash of any asset cached by a third party, to make sure they're actually the same file.)
- tiles 7y ago
  And isn't that available today with `<link rel="preload">`?
  - Wowfunhappy 7y ago
    I don't think one domain can preload content for another domain from their own server, but I may well be wrong. If I am, great, Google could do this today.
- lern_too_spel 7y ago
  You didn't solve requirement #2.
  - Wowfunhappy 7y ago
    How does the third party know the asset was cached if I don't actually visit the third party's page? The CDN (Google) knows all, but that's true with AMP too.
    - lern_too_spel 7y ago
      If that's what you're describing, you've described exactly how AMP works today (though AMP goes one step further and prerenders above the fold, making it instant instead of merely fast).
- joshuamorton 7y ago
  > I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs... Prefetching cross-domain means that now anyone who loads google.com has the potential to also ping mywebsite.com/trackingendpoint, which is a resource that you have to cache. So I get some information, likely less than if you actually execute the page, but still enough to be worrisome. > It can't be worse than letting websites show fake URLs... I really don't get this complaint. I can absolutely understand the unease people have about "fake urls" but a lot of urls already lie. How many are really cloudflare or aws? It's completely possible I'm missing something, but as far as I can tell, signed http exchanges are more secure than a CDN, since they're signed. I guess that potentially since I, a nefarious person, can re-host your signed content, there might be data leakage possible there, but given that AMP is mostly static, I think that's mostly mitigated. Could be wrong here, I'm not a security (or AMP) expert, but I don't get the fear.

deogeo 7y ago

> if Google's goal is to make the web faster It's not. It's just a means to an end - lock-in publishers, and lure consumers.