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