Hacker News Reader

Comment by superasn | Hacker News Reader

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.

View on HN

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

[2] https://github.com/ampproject/amphtml/blob/master/contributi...

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

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.

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)"

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.

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.

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

There also a disadvantage to pre-fetching/preloading data. For users with data caps it wastes data on something they may never view.

So they used clever tricks to get around network latency, but there was still latency in the transaction at some point.

Saying there they removed latency is like saying they’ve removed the speed of light. Didn’t happen, they just preload content for you, because in you’re case, it’s possible to do so.

You can already tell browser to preload content without AMP.

https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading...

You can also prefetch.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

Also preloading/pre-fetching does not get around latency. It just changes when it happens.

HAL, earlier in the thread:

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

>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

I'm not sure that this is actually true, at least for the vast majority of users.

You can disable or enable in firefox. However if users do have strong privacy preferences what makes it okay for AMP to do that. At least a browser setting the user can configure.

And in firefox I can enable or disable pre-fetching/preloading not sure about chrome.

However, if the user has disabled pre-fetching what makes it okay for AMP to do it?

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.

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

Disclosure: I work on AMP.

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

They do, they're just arrogant and believe they're right. And there's no one to stop them.

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?

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.

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?

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

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

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

Reply on news.ycombinator.com