10 ms·

Why doesn't Google treat all websites that load under 100ms at par with an AMP site? They keep using the ruse that AMP is important because it is all about fas

Why doesn't Google treat all websites that load under 100ms at par with an AMP site? They keep using the ruse that AMP is important because it is all about fast loading sites and less frustrating user experience but they have page speed insights, and already rank sites based on load speed so why force this non standard on everyone? If they just said we'll give you a bolt icon and the perks for a site that loads under X ms no matter how you do it (AMP or anything else) a lot of people will welcome it.

masklinn 7y ago
> Why doesn't Google treat all websites that load under 100ms at par with an AMP site? Because then it wouldn't be a wedge anymore.
HALtheWise 7y ago
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
SimeVidas 7y ago
Google Search loads AMP pages from Google AMP Cache. It doesn’t matter how fast a website is. Google needs the assurance that it gets by loading content from their own servers. (I don’t work at Google. I’m just guessing.)

masklinn 7y ago

> Why doesn't Google treat all websites that load under 100ms at par with an AMP site? Because then it wouldn't be a wedge anymore.

HALtheWise 7y ago

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

SimeVidas 7y ago

Google Search loads AMP pages from Google AMP Cache. It doesn’t matter how fast a website is. Google needs the assurance that it gets by loading content from their own servers. (I don’t work at Google. I’m just guessing.)