4 ms·

If you're interested in analysing CertSimple performance, removing the artificial 8s delay on the CertSimple blog might be another line of inquiry. animati

If you're interested in analysing CertSimple performance, removing the artificial 8s delay on the CertSimple blog might be another line of inquiry. animation:-amp-start 8s steps(1,end) 0s 1 normal both

nailer 8y ago
Blog performance is also decent - on all platforms (including desktop), you're viewing an AMP page, so the only js is AMP itself. I don't know specifically what amp.js is doing there with the animation but since the entire purpose of AMP is performance, I'm sure there's a solid motivation behind it.
- detaro 8y ago
  It's so users don't get to see the horror that's the non-JS-ified view of the page before the AMP scripts kick in. Pretty bad reasoning for something so annoying in my book.
- lucideer 8y ago
  > 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.
  - nailer 8y ago
    > 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).
    - lucideer 8y ago
      > No, the inline CSS is added by amp.js. 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-brotli 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.

nailer 8y ago

Blog performance is also decent - on all platforms (including desktop), you're viewing an AMP page, so the only js is AMP itself. I don't know specifically what amp.js is doing there with the animation but since the entire purpose of AMP is performance, I'm sure there's a solid motivation behind it.

detaro 8y ago
It's so users don't get to see the horror that's the non-JS-ified view of the page before the AMP scripts kick in. Pretty bad reasoning for something so annoying in my book.
lucideer 8y ago
> 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.
- nailer 8y ago
  > 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).
  - lucideer 8y ago
    > No, the inline CSS is added by amp.js. 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-brotli 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.