4 ms·

Basically, because it isn't actually possible to make a website that loads in under 100ms on poor connections any other way. For reference, on the fast universi

Basically, because it isn't actually possible to make a website that loads in under 100ms on poor connections any other way. For reference, on the fast university wifi I am currently connected to, news.ycombinator.com loads in 499ms. When I switch to my phone's hotspot, that rises to 2.38 seconds, and on a simulated slow 3G network, that rises to 6.51 seconds. I haven't tested a 2G connection in India, but wouldn't be surprised if it exceeds 10 seconds. Hacker News is not a heavy webpage, in fact, it is probably about as lightweight a webpage as is reasonably possible to create. The key technique that AMP promises will beat the limits of network latency is precaching. Unfortunately, users have a strong privacy expectation that random websites will not be notified that you are interested in them until you actually click the link in search results (or news, or whatever). For precaching to work without violating user privacy, the data needs to be loaded from some server that already knows that the link was shown to you, so there is no privacy violation from giving it that information. AMP's solution is for the host company of the results page to fill that role. The AMP lightning bolt is intended to mean "this page is already downloaded offline on your device, and so will load instantly", not just "this page is well-designed and fast". The difference is minor for blazing fast connections, but that isn't true for developing world users with weak connections and devices. Google has said that when open web standards like Web Packaging finally show up which enable the same safe preloading behavior, those sites will be included in AMP carousels. We'll see whether they follow through with that. [1] [2] * All experiments conducted with cache disabled, times are until Load event fires. [1] https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/ https://blog.amp.dev/2018/03/08/standardizing-lessons-learne... [2] https://github.com/ampproject/amphtml/blob/master/contributing/web-standards-related-to-amp.md https://github.com/ampproject/amphtml/blob/master/contributi...

manigandham 7y ago
Preloading is downloading data that you didn't actively request. It's a tradeoff between data usage vs latency so those users on limited connections might end up paying more in data vs saving a few seconds in load time.
etaioinshrdlu 7y ago
The dumb thing is that for me AMP doesn't even work. It doesn't seem to reliably preload.
- HALtheWise 7y ago
  It's possible that it's an artifact of some browser extensions or something, or it could be they just messed up the implementation (or that some heuristic is trading off bandwidth and latency). Implementing things is hard, and Google certainly didn't get AMP perfectly right. Hopefully the standardization efforts will be able to learn from the experience they have deploying at scale.
anfilt 7y ago
Caches disabled... The browser caches things for a reason. I understand disabling caches to measure the network performance. However, that does entirely give a clear picture. If your wanting things you have already visited to load instantly it's hard to beat the browsers own caches. The first thing that effects page time is network latency and there is no getting around that. AMP may help because google has lots of servers that may be closer, but if the underlying network is slow. AMP will still be slow. Also the next thing is frame size. If the network path has high latency, but the ability push large frames you can send more per request. This is where things like inlining can help. It also reduces the request number. AMP can't get rid the properties of the network. It's also generally the last mile that is slow not back bone. -edit- I find it interesting that the github link provided mentions portals are for "AMP Carousel like UI with navigation to publisher (alternative to iframe promotion)"
- HALtheWise 7y ago
  It simply isn't true that there is no getting around network latency. For example, when I tap an image in a Facebook feed in their app, the story actually does load instantly, regardless of how slow my network is, because it is already downloaded on my device. It may even work offline. AMP is an attempt to match that performance with web pages. Sure, none of this is true if the user manually types into the address bar, but most web navigation isn't done that way.
  - FridgeSeal 7y ago
    That latency and network slowness still exists. It’s just being hidden from you. It’s disingenuous to compare AMP style loading with a normal page visit and say “AMP is faster”; if I could preload my webpage before you click on it, it would be faster to load as well! That doesn’t actually mean the website is any faster.
    - twblalock 7y ago
      > That doesn’t actually mean the website is any faster. It is perceived as faster by the users, and that's the only standard of speed that users really care about.
jridgewell 7y ago
This is the most well-informed comment about AMP I've ever read. Disclosure: I work on AMP.
- JoshMnem 7y ago
  > Disclosure: I work on AMP. Do you all just not think about the long-term implications of what you're building? It's going to destroy the open WWW. Web publishers (and other people who are paying attention) don't want AMP or Portals, but they are being strong-armed into it under threat of losing their traffic.
  - dbbk 7y ago
    They do, they're just arrogant and believe they're right. And there's no one to stop them.
- lawrenceyan 7y ago
  Would you say that the majority of design decisions at Google in recent times have been in relation to the idea of building services towards developing countries/economies where infrastructure is not necessarily as well developed, tailoring it towards those few billion soon-to-be newly connected people who previously have never had access to the internet before?
  - jridgewell 7y ago
    I don’t really follow what’s going on with larger Google. AMP team specifically has a collection of older phones that we test on to remember that we’re making decisions for low end devices common in other parts of the world.
- whalabi 7y ago
  The problem is, Google is using its monopoly to strong-arm publishers into using a sub-par technology that harms their brand and reduces their income. And the worst thing is, without these publishers, Google would have no content and therefore no value. Yes, sub-100ms is attractive. But what do you compromise to achieve that goal? Who pays the price? Publishers who are already struggling, so that the only content on the web becomes content farm affiliate sales shit?
sam0x17 7y ago
Poor connections are a bit irrelevant though for the purposes of ranking URLs by page load time. Presumably whatever bot google would use would have an extremely fast connection, so if the bot loads it faster than X where X is reasonably selected, then it could be considered "fast". Percentiles might make even more sense here -- if the page is in the top 5% of all pages in terms of short loading time, then it is "fast".

manigandham 7y ago

Preloading is downloading data that you didn't actively request. It's a tradeoff between data usage vs latency so those users on limited connections might end up paying more in data vs saving a few seconds in load time.

etaioinshrdlu 7y ago

The dumb thing is that for me AMP doesn't even work. It doesn't seem to reliably preload.

HALtheWise 7y ago
It's possible that it's an artifact of some browser extensions or something, or it could be they just messed up the implementation (or that some heuristic is trading off bandwidth and latency). Implementing things is hard, and Google certainly didn't get AMP perfectly right. Hopefully the standardization efforts will be able to learn from the experience they have deploying at scale.

anfilt 7y ago

Caches disabled... The browser caches things for a reason. I understand disabling caches to measure the network performance. However, that does entirely give a clear picture. If your wanting things you have already visited to load instantly it's hard to beat the browsers own caches. The first thing that effects page time is network latency and there is no getting around that. AMP may help because google has lots of servers that may be closer, but if the underlying network is slow. AMP will still be slow. Also the next thing is frame size. If the network path has high latency, but the ability push large frames you can send more per request. This is where things like inlining can help. It also reduces the request number. AMP can't get rid the properties of the network. It's also generally the last mile that is slow not back bone. -edit- I find it interesting that the github link provided mentions portals are for "AMP Carousel like UI with navigation to publisher (alternative to iframe promotion)"

HALtheWise 7y ago
It simply isn't true that there is no getting around network latency. For example, when I tap an image in a Facebook feed in their app, the story actually does load instantly, regardless of how slow my network is, because it is already downloaded on my device. It may even work offline. AMP is an attempt to match that performance with web pages. Sure, none of this is true if the user manually types into the address bar, but most web navigation isn't done that way.
- FridgeSeal 7y ago
  That latency and network slowness still exists. It’s just being hidden from you. It’s disingenuous to compare AMP style loading with a normal page visit and say “AMP is faster”; if I could preload my webpage before you click on it, it would be faster to load as well! That doesn’t actually mean the website is any faster.
  - twblalock 7y ago
    > That doesn’t actually mean the website is any faster. It is perceived as faster by the users, and that's the only standard of speed that users really care about.

jridgewell 7y ago

This is the most well-informed comment about AMP I've ever read. Disclosure: I work on AMP.

JoshMnem 7y ago
> Disclosure: I work on AMP. Do you all just not think about the long-term implications of what you're building? It's going to destroy the open WWW. Web publishers (and other people who are paying attention) don't want AMP or Portals, but they are being strong-armed into it under threat of losing their traffic.
- dbbk 7y ago
  They do, they're just arrogant and believe they're right. And there's no one to stop them.
lawrenceyan 7y ago
Would you say that the majority of design decisions at Google in recent times have been in relation to the idea of building services towards developing countries/economies where infrastructure is not necessarily as well developed, tailoring it towards those few billion soon-to-be newly connected people who previously have never had access to the internet before?
- jridgewell 7y ago
  I don’t really follow what’s going on with larger Google. AMP team specifically has a collection of older phones that we test on to remember that we’re making decisions for low end devices common in other parts of the world.
whalabi 7y ago
The problem is, Google is using its monopoly to strong-arm publishers into using a sub-par technology that harms their brand and reduces their income. And the worst thing is, without these publishers, Google would have no content and therefore no value. Yes, sub-100ms is attractive. But what do you compromise to achieve that goal? Who pays the price? Publishers who are already struggling, so that the only content on the web becomes content farm affiliate sales shit?

sam0x17 7y ago

Poor connections are a bit irrelevant though for the purposes of ranking URLs by page load time. Presumably whatever bot google would use would have an extremely fast connection, so if the bot loads it faster than X where X is reasonably selected, then it could be considered "fast". Percentiles might make even more sense here -- if the page is in the top 5% of all pages in terms of short loading time, then it is "fast".