AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics.
And if a user ever loads the page with JS disabled (which all my sites are designed to support), AMP breaks and just shows nothing at all for over 8 seconds.
> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
Basically this. AMP sets a hard upper bound for how fast your webpage can be. Have a purely static HTML+CSS blog but want to get the page rank boost from AMP? Just add reams of unnecessary Google Javascript to what should be a very simple site.
> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.
> uses tons of unnecessary JS,
Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
> now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore
Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
> And if a user ever loads the page with JS disabled
In that case, it's the SERP's fault for showing the AMP page instead of the non-AMP page. In the normal JavaScript-enabled scenario, the SERP would be stupid to show your non-AMP page.
> On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.
My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP even and especially while on a train — if you've ever tried using O2 on the intercity train between Hamburg and Münster you know that every third world country has better internet than, I've seen 8kbps with 13 seconds latency there)
> Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
AMP uses megabytes of JS for that purpose, I do the same in under 1kiB (even including an intersection observer polyfill). And my CSS is much much smaller as well. Part of why I get a 100/100 in all pagespeed and lighthouse tests, including when simulating mobile connections, while AMP pages get only 60/100.
> Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
I want JS-free analytics that do not require tracking or any consent (GDPR allows collecting some information without consent, same with the yet unreleased ePrivacy directive with which AMP is not compliant anyway).
What? Where are you pulling these numbers? Also, what do you mean by hot cache? I'm starting to suspect that you don't even understand that the AMP page (the JavaScript for sure, and often the entire HTML and above-the-fold images as well) is already on the user's device, while your page is not.
If the AMP version takes longer to load than the time between the search results loading and the user clicking on it, then the AMP version will still have a visible load time.
Obviously, this part is affected by the AMP js being in cache or not.
Still, often my own page can load faster than just this user-visible part of loading the AMP version.
AMP works best when the user visits almost only AMP pages (so the resources stay in cache), and the user has a high-latency high-bandwidth connection.
But that's almost nowhere in the world true, in reality most people have relatively low latency with low bandwidth.
Your claims disagree with the facts on the ground, where latency is the main factor affecting page load time. This is the driving force behind CDNs, HTTP2, QUIC, and pretty much every speed optimization that people have been working on in the past few years. https://www.afasterweb.com/2015/05/17/the-latency-effect/
Your claim that your page loads faster also reeks of wishful thinking. Pretty much every AMP page I have loaded from a SERP loads instantly, not just fast. For someone on a worse connection, the page will have started loading before the user clicks on the link from near caches versus have not started loading at all from a far server. In the rare case where the AMP JS is not in the browser cache, it will be after loading the first result.
As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times. That's the "facts on the ground".
If you say pretty much every AMP page you've loaded has been instant, please post the specs of the devices and network you've been using for testing.
Additionally, if the latency between the device and the nearest server is over two seconds, the latency to a far server as well as the click latency don't even come into play anymore at all, instead the number of connections needed becomes much more important, and bandwidth also becomes a much larger factor.
Your claim that HTTP/2 would have worked towards better latency on lower connections is also false, on bad mobile connections HTTP/2 actually increases latency, which was a major reason for QUIC aka HTTP/3 in the first place.
> As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times.
And as I've mentioned, you've been testing the wrong thing by not understanding the whole point of AMP (safe preloading).
> instead the number of connections needed becomes much more important
A page preloaded from an AMP cache needs at most one TCP connection, usually zero if it uses QUIC.
> and bandwidth also becomes a much larger factor.
Which also works in AMP's favor because the device doesn't need to load your custom JavaScript or potentially unoptimized images, just the tiny HTML and optimized images above the fold. The weight of this (and the associated gain) is tiny, which is why bandwidth is a relatively unimportant factor.
> On bad mobile connections HTTP/2 actually increases latency
You're mixing up dropped packets with high latency. That's neither here nor there because Google's and Cloudflare's AMP caches both use QUIC — my point was that latency is the key factor that all modern web speed technology has attacked, including AMP.
