> I don't know specifically what amp.js is doing there with the animation
The snippet I posted is a small bit of inline CSS at the top of your page that hides all page content for 8s. There is no JS involved, and the mechanism is quite clear if you know CSS.
> the entire purpose of AMP is performance
I'm afraid you are sorely mistaken. (See the comments on any AMP-related HN submission if this is news to you).
> I'm sure there's a solid motivation behind it.
What makes you so sure? The motivation is to artificially degrade the experience for any users that choose to block 3rd-party AMP tracking scripts. There is no other reason behind it.
> I don't know specifically what amp.js is doing
Normally, one can overlook people throwing random 3rd-party scripts into their blog with no clue what they do, but for someone blogging about using brotli and commenting about applying discify, this kind of wilful ignorance is a little ironic. Particularly after someone points out that there is an 8s delay in your page load.
> The snippet I posted is a small bit of inline CSS at the top of your page that hides all page content for 8s. There is no JS involved
No, the inline CSS is added by amp.js.
> > the entire purpose of AMP is performance
> I'm afraid you are sorely mistaken (See the comments on any AMP-related HN submission if this is news to you).
I wrote a bunch of those comments. Now Malte is allowing people to host AMP content on their own domains I trust it a little more.
> The motivation is to artificially degrade the experience for any users that choose to block 3rd-party AMP tracking scripts.
AFAIK amp.js doesn't do any tracking on it's own - you need an analytics module to do that. Do you know differently?
> > I don't know specifically what amp.js is doing
> this kind of wilful ignorance is a little ironic
Not really. Do you know your CPU microcode well or would you consider yourself wilfully ignorant? Perhaps rather than being wilfully ignorant, I choose to focus my time on what matters to my customers (with a side of arguing on Hacker News).
It definitely isn't. It's in the raw source, sans-JS. Whomever developed the blog theme placed it there explicitly. (it is a snippet given to you to copy paste while implement amp, but it serves no purpose other than to degrade performance for non-amp users).
> Malte is allowing people to host AMP content on their own domains I trust it a little more.
That's not how "AMP cache" hosting works. AMP is a system whereby the site source is crawled and rehosted on the server of an indexer. You can host it on your own domain to make yourself feel a little better, but the only people who see that copy will be those to whom you give that direct link (e.g. HN readers). Indexers are free to rehost your AMP content on their own "AMP cache". i.e. it's still going to be served from https://www.google.com/amp/s/certsimple.com/blog/nginx-brotl... for any mobile search traffic coming from Google (note the link is referer-dependent).
> AFAIK amp.js doesn't do any tracking on it's own - you need an analytics module to do that. Do you know differently?
You need an analytics module to avail of an analytics service to do your own tracking. There's nothing to indicate that Google do no internal tracking of their own.
> Do you know your CPU microcode well or would you consider yourself wilfully ignorant?
The intent of my comment was to point out that being aware of this issue involves a relatively low level of knowledge/investigation/interest. So low in fact that in my very first comment, I posted the entire 53 character sourcecode of the issue. Also, CPU microcode changes aren't causing 8s page load delays for me.
From that: AMP HTML documents must contain the following boilerplate in their head tag.
> That's not how "AMP cache" hosting works.
With prefetching my understanding (from what's been written publically) is that content will be allowed to be hosted on your own domain. Ie, your domain in the address bar. Are you saying otherwise?
> There's nothing to indicate that Google do no internal tracking of their own.
OK so you just disagree on where the burden of proof lies.
> The intent of my comment was to point out that being aware of this issue involves a relatively low level of knowledge/investigation/interest.
You think it causes an 8 second delay. It doesn't. The page loads unbrowsercached in less than a second. The low level of knowledge/investigation/interest still seems to be above your own.
> With prefetching my understanding (from what's been written publically) is that content will be allowed to be hosted on your own domain. Ie, your domain in the address bar. Are you saying otherwise?
No. As I said, you can host it where you want. You can visit that domain and see your content. But Google are still going to rehost your content on their own server and direct their users to their copy, on their domain.
> You think it causes an 8 second delay. It doesn't.
Apologies, I assumed you'd have some understanding of frontend technologies when I posted the code above, so I'll explain how it works:
- you have an inline CSS snippet that hides all page content for 8s (there is no reason for this). This is executed immediately.
- you then have your amp.js file, pulled from Google's server, which should download and parse relatively fast (especially if you've put the script tag in the document head, as is recommended)
- once amp.js is loaded and is parsed, it enables some further inline CSS which overrides the first inline CSS snippet, unhiding all page content instantaneously
As I said above, the 8s delay is for non-AMP users; anyone not loading the amp.js resource from Google's servers, or anyone for whom the resource fails to load for any reason.
> Google are still going to rehost your content on their own server and direct their users to their copy, on their domain.
As long as my domain is in the address bar, and the content isn't modified - which I understand will be the case - I don't care.
> As I said above, the 8s delay is for non-AMP users;
No, that's not what you 'said' (wrote) above.
You wrote:
>> removing the artificial 8s delay on the CertSimple blog might be another line of inquiry.
You wrote:
>> The snippet I posted is a small bit of inline CSS at the top of your page that hides all page content for 8s.
Implying there was an 8 second delay that normal users would see.
Even now you're jumping through hoops to say 'non AMP users' where in reality you mean a tiny niche of users with broken network connectivity or who deliberate disable JavaScript, etc.
Thanks for wasting my time. If you'd have said what you honestly knew "I dislike this as it won't show the site if users can't load the JavaScript" I would have said "fine I don't care". Instead you pretended something was actually wrong and I wasted time communicating with you and being insulted.
Please do not communicate with me again. This is why HN needs a block button.
The snippet I posted is a small bit of inline CSS at the top of your page that hides all page content for 8s. There is no JS involved, and the mechanism is quite clear if you know CSS.
> the entire purpose of AMP is performance
I'm afraid you are sorely mistaken. (See the comments on any AMP-related HN submission if this is news to you).
> I'm sure there's a solid motivation behind it.
What makes you so sure? The motivation is to artificially degrade the experience for any users that choose to block 3rd-party AMP tracking scripts. There is no other reason behind it.
> I don't know specifically what amp.js is doing
Normally, one can overlook people throwing random 3rd-party scripts into their blog with no clue what they do, but for someone blogging about using brotli and commenting about applying discify, this kind of wilful ignorance is a little ironic. Particularly after someone points out that there is an 8s delay in your page load.