Hacker News Reader

Comment by gonational | Hacker News Reader

> But who will measure it "objectively"

One potential solution that fits the theme of the letter could be logic like this:

    MAX = <reasonably fast load time>

    if page loads in > MAX:
        -> punish page rank

Rather than the current logic:

    if page uses GOOG proprietary:
        -> show at the very top
        -> trick anyone that clicks
        -> profit
    else:
        -> ban website
        -> reach out to sell AdWords

"Reasonably fast" could be relative to the context - for example, ecommerce results might be a bit larger on average than news results, etc., so not a static "3 seconds at 3G speed".

"Reasonably fast" could also be defined more loosely as "page uses good optimization practices" (e.g., like a YSlow grade).

View on HN

  >  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.

> 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.

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/

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.

Yeah I was talking about computers, not phones.

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.

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.

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.

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.

Note also that Google doesn't show AMP for desktop user-agents.

Any WebPageTest comparison between Desktop and Mobile will demonstrate that RTT can be _vastly_ different between Desktop and Mobile.

Just look at Time to First Byte (TTFB); when you pile on SSL negotiation (since most have moved to HTTPS), the advantage is even greater since all AMP pages currently fall under the aegis of Google's domain and all non-AMP pages will require that overhead at first click.

> - 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.

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.

Google already measures a bunch of site speed parameters (time to render start, time to render the content text the user is trying to read/search for, etc.)

They factor in all that stuff to a user happyness metric which impacts rankings, probably via a bunch of machine learned models.

The AMP logos and stuff are to try and force webmasters to take speed seriously. For years people have said it's important, yet big sites like eBay and Amazon, who certainly have the financial means and motivation to, still take 10x longer to load than what would maximize both revenue and user happyness.

> They factor in all that stuff to a user happyness metric which impacts rankings

And speed is way down on the list. Try searching for lyrics to any popular song and tell me it isn't so.

All they really need to do is add more weight to it. But they don't want to because that breaks the lock-in that they are striving for.

Reply on news.ycombinator.com