Comment by donohoe | Hacker News Reader

Comment by donohoe | Hacker News Reader

Parent Full thread

The whole marketing aspect behind AMP is that its fast. This is the narrative that has sucked most publishers in. It is also not true (to the degree you think).

I run a leaderboard of major news publishes (mostly English language based ones). It relies on WebPageTest.org and tests about 60+ articles pages nightly on 3G and 'Fast 3G' speeds. The myth that you cannot have a fast web page AND have ads on it is a myth. Several organizations do it and do it well (DotDash dominates the board with their sites).

https://webperf.xyz/

Before I hit API limits on WPT I was also testing against the AMP version of the page too. The speed differences between the regular page load and the AMP page load was often very similar. I recall in some cases (Quartz, Guardian, NYT) that regular pages loaded faster than AMP.

That aside, assuming a regular web page took 10 seconds to load (a top 10 article) you would expect that the AMP page would be faster, say down to 2 or 3 seconds in Load Time in order to make the effort of having yet another template/format to support and to justify the effort to re-implement analytics, pay-wall, and ads?

Very often it was the a saving of only a second or two. It all adds up, but as someone who works with resource strapped publishes thats not worth the resources. Thats especially true when I could have spent all that time optimizing our regular pages instead of this other project.

Why do people think AMP is faster? Pre-caching by Google.

The thing is Google (IMHO) could pre-cache regular web pages too. They don't. They don't even issue guidelines on how to make your site cache friendly, they insist on this whole specification/implementation and insist on hosting it remotely and create all sorts of barriers.

I have a different take. It's not that you can't do normal HTML as fast as AMP. It's that by preventing a lot of the things that make "normal" sites slow, it changes the whole conversation at publishing companies.

For example, here is an example conversation at a web company before AMP (and this is not really hypothetical - I had more than a few conversations like this):

Marketers: We need you to add these 623 tracking pixels from these 300 ad networks to the page.

Developers: But that will kill page performance!

Marketers: But you guys are smart, make it work!

And after AMP:

Marketers: We need you to add these 623 tracking pixels from these 300 ad networks to the page.

Developers: Get bent. AMP doesn't allow that, and without AMP our SEO positioning will tank.

Marketers: Oh, OK.

And in a world where Google isn't malicious:

Marketers: We need you to add these 623 tracking pixels from these 300 ad networks to the page.

Developers: Get bent. If we add tracking pixels our SEO positioning will tank.

Marketers: Oh, OK.

This is a wishful thinking counterfactual. No major search engine ever weighed obscene numbers of tracking pixels or heavy page weight very high in their SEO algo.

I'm not saying Google doesn't have perverse incentives (and with AMP, they do). But it wasn't fixed before Google and AMP is one of the counterweights to web ads + tracking beacon overload.

> This is a wishful thinking counterfactual.

Well, yes, I did say that.

> in a world

It might be a naive question, but: in the first case, can't you say that's impossible? Show them a competitor's website with a shitload of tracking to demonstrate the difference?

It does help. Depends on the people involved.

Why does every network need a separate pixel? Is the value sell the third-party tracking across domains or something? I don't understand why you can't just have one pixel and have everything fan out to multiple services server side.

You can, but it’s not universal and it requires more dev effort. Also many of these services provide different ways of covering their own unique metric.

> Why do people think AMP is faster? Pre-caching by Google.

This is a huge part of it. It is not unusual for an HTML page to load faster than an AMP version when loaded directly by a browser ( render blocking on the 3rd party amp JS bits can result in it taking longer to start rendering ).

The part that often allows AMP to win is that Google caches it to their own CDN and Chrome will pre-fetch it from there. What is interesting about that is that none of that has anything directly to do with format/spec of AMP pages.

The reason prefetching is particularly difficult to do for regular pages is the privacy implications. The act of preloading the page is a network event that is observable by the server serving that page.

If the server is the same as the linking page, for example Google search result -> Google Cache, there is no new information transmitted. That server already knows the user did query X and it knows that the page was going to fetch cache page Y, since the query page X instructs the browser to do so.

If the server is distinct from the linking page, for example Google search result -> https://healthsite.example/, then the browser will make a request to the healthsite server without the user having clicked the result. The healthsite server will learn the IP of the user, and some information about the query from which page is loaded, all without the user ever "visiting" that site. This is a major privacy violation.

AMP Pages solve this by a) being loaded from Google's cache and b) Guaranteeing no off-cache subresources will be loaded before the page is navigated to. (a) requires Google's cache to serve the page. (b) requires that the document author gives up some control over scheduling resource loading in the prefetch.

Until recently, AMP was the only game in town that could achieve this. Chrome recently shipped with Signed Exchanges, which is a network-level technology that could allow prefetching arbitrary content from a cache. This would still involve a Google cache, but does not require coordination with the document loading. Google AMP now supports this (https://webmasters.googleblog.com/2019/04/instant-loading-am...), but it would also work with non-AMP pages.

That's not really true. Anytime anyone makes claims like this, I ask for you to design a system that meets 3 requirements:

1. Can serve dynamic content

2. Doesn't leak any user data or metadata to a third party before they explicitly consent (in other words, executing a search on Google shouldn't ping cnn.com, this makes things like link rel=preload not work).

3. Allows caching pages client side for "instant" loading

I've challenged a few users this way, and they always construct something virtually equivalent to amp.

> The whole marketing aspect behind AMP is that its fast. This is the narrative that has sucked most publishers in. It is also not true (to the degree you think).

I think what has sucked most publishers in is the belief that if they don't play ball and implement AMP, they'll suffer in Google's rankings.

Google has said over and over that AMP is not a ranking factor. If someone could definitively prove that it's not, I think publishers would be less likely to bow down to AMP. If someone could definitively prove that it _is_, then we'd have evidence of Google both lying and promoting their own technology.

Of course the "Top Stories" carousel _is_ an unfair advantage for those who use AMP -- more people just need to call out Google on this. It should either be renamed "Top AMP stories" or they should not prevent non-AMP stories from appearing in it.

You can't securley pre-cache regular pages while still doing analytics and ads, which I understand publishers feel are important.

> The thing is Google (IMHO) could pre-cache regular web pages too. They don't.

AMP is a defense against the increasing noise about copyright violation by including snippets and caching. It lets them say "But, Your Honor, they provided an AMP version knowing that it's intended specifically for this purpose."

Reply on news.ycombinator.com