Hacker News Reader

Comment by elliotec | Hacker News Reader

    Where is the performance improvement coming from? 
    The largest performance benefits comes from a drastic reduction in the number of various objects loaded in AMP

For the millionth time, you don't need AMP to improve your website performance. The reason there is "better performance" in the AMP vs non-AMP pages according to this article, is that there are fewer assets and objects to load in the AMP pages due to some of the restrictions AMP imposes.

In other words, load fewer assets, write less code, and you'll have better performance.

AMP is still bad, and it does not itself make the web faster.

View on HN

But publishers weren't doing that before AMP came out. What AMP does is provide a tangible thing devs can sell to higher ups in order to be allowed (or just given the time) to write less code and load fewer assets. AMP also helps search engines (not just Google) be able to preload websites without violating user's privacy, which seems like a good thing, no?

I honestly don't get all the hate AMP gets around here. From a consumer standpoint AMP provides nothing but benefits compared to what we had before.

A thought experiment: Google could, in a proverbial heartbeat, unilaterally make and publicize a change to its search rankings that amounted to "achieve AMP-like performance with your site, OR ELSE". AMP as a technology is irrelevant to this end.

Instead, AMP is about control and disintermediation – eliminating the need for users to ever actually visit the sites of content producers. The economic impacts of that redirection be damned.

The objection to AMP is thus not about the performance. It's about Google's proprietary end-run on the web platform, and its (ab)use of monopoly power to achieve that end.

Google would face the exact same criticisms if it tried to strongarm publishers into caring about performance.

> Google would face the exact same criticisms if it tried to strongarm publishers into caring about performance.

You state this as a fact, but Google seems to use, and to have long used, load time as a ranking metric (see https://backlinko.com/google-ranking-factors #22, for example), and I've never heard any serious complaints about it.

it would face less criticism (even though it does use site speed as a signal - they ve said that many times)

> I honestly don't get all the hate AMP gets around here. From a consumer standpoint AMP provides nothing but benefits compared to what we had before.

Two main reasons:

1. The obfuscation of AMP source URLs in Google search results is usually the biggest reason for the hate.

2. The "AMP Carousel" in Google search results is designed to keep people on Google and makes it much less likely people will leave to explore other pages on the publisher site (I can't find the article now but I recall reading a report from one publisher that showed a HUGE dropoff in users viewing an article and then going to view other articles on the site).

So it's less about the technology of AMP per se and more that, the way it's currently implemented, is about Google dictating more and more the way the web works.

#1 is being fixed for supporting browsers (Chrome so far). https://webmasters.googleblog.com/2019/04/instant-loading-am...

You can see it for a number of sites already. For example, search for an AMP result from collins dictionary.

So essentially yet another standard pushed out by google via Chrome with 0 feedback from other browser vendors.

No, the other vendors gave feedback and objected to it: https://www.theregister.co.uk/2019/05/30/mozilla_web_packagi...

That sound even more like Google's modus operandi when it comes to browser development!

> ... showed a HUGE dropoff in users viewing an article and then going to view other articles on the site ...

Just speaking from personal experience, lots of AMP pages are totally broken for me aside from the actual content. I have encountered pages multiple times where visiting links to other content was broken. I would (personally) take findings like this with a grain of salt.

If you encounter this again in the future, I'd love to take your bug report with the specific page in question. You can email me directly. My email is pretty easy to find from my profile.

- fundamentally changes the way the web works. Websites suddely became second citizens, essentially making google search the primary citizen who serves other people's content as if it s their own.

- It splits each webpage in two.

- Hiding the real domain means fake sites and phishing are possible

- Prerendering downloads on average 1.4 MB of data with every search results page that the user may not even want or ever choose to see (it might even become a huge secuyrity hole). This probably renders server-side analytics useless too. only google now knows the truth about your traffic

- single point of failure for a government to shut down / censor articles / delete specific information from all news websites

- obvious google's control of your content / and manipulatively ranking higher the content they render - I expect this to cause an anti-trust fine very soon

- Replacing HTML with an abomination , which WILL be abused in a few months, the same way that html is currently abused in news sites.

i m curious how they manage to preserve privacy if they route api requests through their servers

See https://webmasters.googleblog.com/2019/04/instant-loading-am... which addresses the concern about the URL. You can see it for a number of sites already. For example, search for an AMP result from collins dictionary.

As reported in the paper, prerendering only affects amp pages in the first viewport of the search results, which is reported as 10% of the results in their sample. Prerendering does not have any security issues. AMP guarantees that all resources in preload are served by the AMP cache, and custom javascript is prevented by your browser via CSP.

Javascript based analytics works fine, with support for all major vendors and custom setups.

That "standard" is an abomination. What's next, we 'll upload our SSL certs to google so they can masquerade more efficiently? IETF should not back standards introduced by and benefiting only google.

> Prerendering does not have any security issues.

Currently. Are you saying it is impossible that someone will hide a hack in an amp page that steals data or sth without the user ever visiting that amp page?

> AMP guarantees that all resources in preload are served by the AMP cache,

What about privacy? are user data sent through google's servers?

> Javascript based analytics works fine, with support for all major vendors and custom setups.

How do those analytics handle prerendering?

AMP documents are delivered with a Content-Security-Policy which instructs the browser not to load javascript resources outside the AMP origin, including inline scripts. The AMP Cache ensures no remote images or other remote resources can be loaded in preload.

When using signed exchanges, the preload does not even parse the document until navigation, as per the signed exchange spec.

Analytics loading is deferred until after user navigation, which makes sense as the user has yet to navigate to the document.

The AMP Cache serves publicly cached HTML documents, and the static fonts/images within those documents. If a document wants to render user specific data, it can load that directly from the publisher's origin upon navigation (not routed via the AMP Cache). See, for example https://amp.dev/documentation/components/amp-list/. Analytics, ads, etc are all fetched directly from the vendor or publisher origin and the AMP Cache will neither proxy nor otherwise see this data.

Thats not really loading it from the remote site is it, its more the url bar lying to the end user? What happens if you copy the url or enter it directly?

Yes and no. The browser is making an HTTPS request to the AMP Cache for the document. The document's integrity is ensured by the cryptographic signature of the publisher's origin which the browser verifies. As far as the integrity of the document, this is the same conceptually as the fact that your wifi router is actually serving the document to your browser. The AMP Cache cannot modify the document, and the publisher may choose what to sign or not sign.

Entering the URL directly will make an HTTPS request to the URL's origin server, as it always has. There will be no AMP Cache involved in that request, but it will work just the same.

That seems like a gross mischaracterization of the article. Their measurements show a huge effect from the AMP cache (average load time from 3.1s to 1.2s).

And that's a feature that's just not possible to support for arbitrary HTML. Just because you've repeated something that's not true a million times does not magically make it true. Cross-origin prefetching is not viable (privacy leaks, flaky browser support). And on the flip-side, same-origin serving can't be done securely with arbitrary HTML + JS.

I get that this won't make you hate AMP any less. But maybe the hate could be rooted in facts? It'd make it a lot easier to have a rational discussion about the subject.

Is the AMP cache any different from any other CDN caching assets other than that it is owned and prioritized by Google? Does that fact alone make it faster? If so, are we as a community okay with this imperialist strategy by Google?

And prerendering is absolutely viable and in practice all over the place apart from AMP. Here's Chrome's own docs on it: https://www.chromium.org/developers/design-documents/prerend...

Is the AMP-specific prerendering another abuse of Google's position despite them using the technology elsewhere?

It just seems like this is not technology specific, but prioritization of tech created by a giant company that owns nearly everything and must own more.

>Is the AMP cache any different from any other CDN caching assets

I'm not an expert but Google AMP is not a simple CDN cache. The Google-owned servers also proxies API calls to whitelisted urls like approved ad networks and Google Analytics. (Expand all the triangles in the list: https://amp.dev/support/faq/platform-and-vendor-partners/)

A cache service like Cloudflare CDN doesn't do that. (Although there's an example of somebody trying Cloudflare's new "Workers" functionality to proxy an api call on the server side instead of the browser side: https://community.cloudflare.com/t/google-analytics-proxy-wo...)

For publishers that use ad networks, Google's AMP is a different value proposition from a typical CDN. Because Google's AMP has a different technical architecture, it solves a different problem than a CDN.

Yes, Cloudflare could conceivably add more functionality to their service to proxy ad network api calls like Google AMP but it wouldn't buy them as much of a speed boost because Cloudflare doesn't own/control the "google.com" domain that serves search results. It's "www.google.com" that has Google's trusted javascript code to preload AMP data that is executed on the user's web browser.

This is a misunderstanding. Browser requests to ad and analytics networks are never proxied by the AMP Cache. They are made directly from your browser to the vendors listed. You can verify this in network tools. The AMP Cache proxies: AMP Pages, images, fonts. That's pretty much it, since those are all that's needed for prerendering.

> Is the AMP cache any different from any other CDN caching assets other than that it is owned and prioritized by Google?

Yes, it's substantially different, since the purpose of Google's AMP cache is to serve pages linked to from a Google origin. Google has to know which search query you entered to render the results page, so prefetching some of the actual results doesn't leak any information. If you prefetch from arbitrary domains, you leak information about people making a search to those domains, even if they don't click through.

(And likewise for other entities that are running their own AMP caches, for links hosted on their own origins.)

That's very clearly the actual technical problem being solved; if you set out to solve the problem of privacy-preserving prefetching of search results with the tech from 5 years ago, you'll inevitably end up with something like AMP.

> Does that fact alone make it faster? If so, are we as a community okay with this imperialist strategy by Google?

Irrelevant, since you're basing both of these questions on inaccurate assumptions.

Doesn't Google share information with site owners about the searches that include that site anyway?

> hat seems like a gross mischaracterization of the article.

I mean the article itself says that the other improvement are much less significant than the overall 2.5 speedup of the amphtml page. Whether the user will have to do 1-2 more seconds is immaterial , when you have typical newspaper websites that take 10-30 seconds to load.And you don't implicate google's caches (which will at some point refuse to render you if your page is against their politics) in any step.

Regardless, i believe amp will fail equally to how html pages fail now: newspaper marketers will keep adding more and more stuff to their amphtml webpages (and amp makes it easier to add extra components), and no matter how fast it loads, they will become heavy as hell and your phone will again start to smoke. We just dont see that yet because it's early days - but newspaper sites were also bare html 20 years ago. AMP is an evil bandaid with significant sideeffects

> which will at some point refuse to render you if your page is against their politics

Say what now? Citation needed.

didnt they censor a bunch of nutrition sites today?

i cant bring u a citation from the future. it's speculation

There's a 2.5x improvement from serving AMP rather than HTML. There's also a 2.5x improvement from prefetching. The part that the article dismisses is the change from just the AMP cache but without prefetching.

I think there's a pretty big difference between a few seconds and instant. Maybe you think the difference doesn't matter to the UX, and there's at least a discussion. But just going lalala and denying that the difference exists?

It's also worth noting that the cache is necessary for prefetching. Without the cache, the prefetch would leak user's query intent to an origin that the user has yet to decide to visit. This would violate the user's privacy, therefore a cache is necessary to achieve prefetch.

AMP provides the incentives to load fewer assets. Publishers wont do it otherwise.

Google could provide exactly the same incentives to normal HTML pages that refrain from loading so much extra crap

Reply on news.ycombinator.com