5 ms·

> MAX = <reasonably fast load time> If you define 'reasonably fast' as ~10ms after click, the only possible option is AMP. Even a .txt file will be orders of

> MAX = <reasonably fast load time> If you define 'reasonably fast' as ~10ms after click, the only possible option is AMP. Even a .txt file will be orders of magnitude slower. Privacy reasons mean that it is basically impossible to load the content from the publisher's server until after the user clicks on the result. If you wait until the user click event to load the content, then there is nothing you can do to avoid a full network round trip. AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load. There are unavoidable technical requirements to do this: - Loading from Google's (or link provider X's) servers to preserve privacy. - Constraining the html so that the load itself can't break privacy or add jank to the search result page. If you aren't willing to accept these constraints, then you are always going to face a network round-trip in added latency. You can't have all 3 of: - Zero perceived latency - Privacy - Serving from the publisher server You can only pick 2. AMP forces choosing the first 2 which are what the vast majority of users care about. Then AMP goes way out of it's way to give publishers back everything they could possibly miss from the 3rd.

dingo_bat 9y ago
> AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load. There is another way which enables almost instant loads. Turn off js completely. Try it yourself before you disregard it. It literally turns page loads instant over a regular home connection.
- gregable 9y ago
  This is strictly slower than an AMP preload, which is why I mention that even a .txt file will load slower. The .txt file document still requires a network round-trip, regardless of javascript. On some wired connections, a network round trip is within user-perceivable 'instant', but for many people on mobile devices, this is very noticeable. https://hpbn.co/mobile-networks/ https://hpbn.co/mobile-networks/ Even on the best LTE networks, the 'core network latency' is 40-50ms. 'core network latency' is the latency for getting the packet from the phone to tower to the packet gateway. This is before the packet even goes on the internet. And you need to double it for the round trip. You usually need to double the whole thing for initial DNS lookup. Best possible latencies for an html page load on excellent LTE connections without prefetching are around 150-200ms. Most users in the world will experience >1s. A United States major city wired connection is not at all representative of what most people experience on a mobile connection.
  - dingo_bat 9y ago
    Yeah I was talking about computers, not phones.
    - fixermark 9y ago
      Then you are missing the point of AMP. Increasingly, phones are the dominant computing tool accessing Google search results. Optimizing for phone experience is key to serving the largest growing demographic of searchers.
      - tscs37 9y ago
        Preloading website content is not what I want for my phone. I have a very low datacap and I go out of my way to disable AMP and preloading because web publishers believe that my bandwidth can be used freely by them in an effort to "reduce latency". Instead it robs me of the little data I have for my cap.
        gregable 9y ago
        That's fair, but I think losing perspective of the tradeoffs. The AMP preload will fetch only the main html file and AMP javascript. Images, videos, etc are all deferred until later. The javascript is cached for a year, so you probably already have it. So, compressed, this is probably ~100kb or less. Google doesn't start preloading 50 documents, it loads the top result or 2. Even viewing a hundred amp pages in a month is going to cost you less data than one 10kx10k unoptimized image that a publisher decides to load, which happens a lot. Note that AMP optimizes images too taking into account your device resolution, so it's most likely saving you bytes.
        tscs37 9y ago
        I don't want anyone preloading anything on my mobile connection other than the absolute necessary. Period. Everything else wastes my bandwidth and I don't care that it is only 100kb, my monthly, effective datacap is about 50MB and I always browser without images. The "100kb or less" is only about 500 pages preloaded, not accounting for the size of the google webpage itself. I'd rather not have any preload at all.
yorwba 9y ago
> - Constraining the html so that the load itself can't break privacy or add jank to the search result page. Why this? If the HTML is already loaded from Google's servers, the load shouldn't be able to break privacy even more, and jank shouldn't be affected by the specific HTML that's being served, just by its size. So Google could just preload everything that's small enough.
- gregable 9y ago
  Good question. Preload that actually renders the documents includes running enough javascript and parsing enough CSS that the initial document will render. With a non-constrained document, that can include fetching resources not on Google's servers and which can peg the CPU, causing jank. If you do constrain what can run in your preload to avoid these, you end up designing AMP.

dingo_bat 9y ago

> AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load. There is another way which enables almost instant loads. Turn off js completely. Try it yourself before you disregard it. It literally turns page loads instant over a regular home connection.

gregable 9y ago
This is strictly slower than an AMP preload, which is why I mention that even a .txt file will load slower. The .txt file document still requires a network round-trip, regardless of javascript. On some wired connections, a network round trip is within user-perceivable 'instant', but for many people on mobile devices, this is very noticeable. https://hpbn.co/mobile-networks/ https://hpbn.co/mobile-networks/ Even on the best LTE networks, the 'core network latency' is 40-50ms. 'core network latency' is the latency for getting the packet from the phone to tower to the packet gateway. This is before the packet even goes on the internet. And you need to double it for the round trip. You usually need to double the whole thing for initial DNS lookup. Best possible latencies for an html page load on excellent LTE connections without prefetching are around 150-200ms. Most users in the world will experience >1s. A United States major city wired connection is not at all representative of what most people experience on a mobile connection.
- dingo_bat 9y ago
  Yeah I was talking about computers, not phones.
  - fixermark 9y ago
    Then you are missing the point of AMP. Increasingly, phones are the dominant computing tool accessing Google search results. Optimizing for phone experience is key to serving the largest growing demographic of searchers.
    - tscs37 9y ago
      Preloading website content is not what I want for my phone. I have a very low datacap and I go out of my way to disable AMP and preloading because web publishers believe that my bandwidth can be used freely by them in an effort to "reduce latency". Instead it robs me of the little data I have for my cap.
      - gregable 9y ago
        That's fair, but I think losing perspective of the tradeoffs. The AMP preload will fetch only the main html file and AMP javascript. Images, videos, etc are all deferred until later. The javascript is cached for a year, so you probably already have it. So, compressed, this is probably ~100kb or less. Google doesn't start preloading 50 documents, it loads the top result or 2. Even viewing a hundred amp pages in a month is going to cost you less data than one 10kx10k unoptimized image that a publisher decides to load, which happens a lot. Note that AMP optimizes images too taking into account your device resolution, so it's most likely saving you bytes.
        tscs37 9y ago
        I don't want anyone preloading anything on my mobile connection other than the absolute necessary. Period. Everything else wastes my bandwidth and I don't care that it is only 100kb, my monthly, effective datacap is about 50MB and I always browser without images. The "100kb or less" is only about 500 pages preloaded, not accounting for the size of the google webpage itself. I'd rather not have any preload at all.

yorwba 9y ago

> - Constraining the html so that the load itself can't break privacy or add jank to the search result page. Why this? If the HTML is already loaded from Google's servers, the load shouldn't be able to break privacy even more, and jank shouldn't be affected by the specific HTML that's being served, just by its size. So Google could just preload everything that's small enough.

gregable 9y ago
Good question. Preload that actually renders the documents includes running enough javascript and parsing enough CSS that the initial document will render. With a non-constrained document, that can include fetching resources not on Google's servers and which can peg the CPU, causing jank. If you do constrain what can run in your preload to avoid these, you end up designing AMP.