[gregable]

You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):

  <style>
    body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
    @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
  </style>
  <noscript>
    <style amp-boilerplate>
      body{animation:none}
    </style>
  </noscript>

See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. When the AMP Javascript loads (a single js file, one request, typically already in the users cache), the javascript displays the page immediately. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.

The only two cases where the 8s is relevant are: the network connection is so bad that the javascript file fails to load within 8s and the useragent has explicitly blocked the one javascript file on the page, without blocking javascript overall.

[JoshMnem]

The 8-second delay is there to punish users who block JavaScript that is loaded from Google's servers (with ad-blockers) but still have JavaScript enabled.

[esrauch]

I think that's a bit unnecessarily tin-foil-hat. If they didn't put in the 8 second css rule it would just show blank for those users right? So adding that rule is making it work at all instead which doesn't sound like "there to punish them".

[squiggleblaz]

Why is there an eight second delay instead of, say, an 0.8 second delay? Or no delay at all?

I mean, if the goal is to make the page display only once it's fully loaded, and the point of amp is to make pages load quickly, eight seconds seems gratuitous. Even slow sites load within eight seconds.

(I don't deliberately use any Google products, so I'm completely unfamiliar with amp.)

[gregable]

Reasonable question.

Until the javascript has loaded (a single cacheable javascript file: https://cdn.ampproject.org/v0.js ), the browser can't lay out the resources on the page (images for example).

If the browser rendered the page before layout, it would likely look pretty bad. Then when the javascript arrived, the document would layout again moving elements around. This is typically referred to as the "Flash of Unstyled Content" (https://en.wikipedia.org/wiki/Flash_of_unstyled_content) and is considered by some to be a negative user experience. Many web pages outside AMP take a similar approach to hiding the content until the layout has completed.

The 8 second CSS animation is only present as an "escape hatch" in case the javascript never loads. The specific value was chosen as a time that probably indicates the javascript will never load. Note that if javascript is disabled entirely, the page is rendered immediately via the <noscript> tag. There has been a discussion around changing the 8 second time to something shorter ( https://github.com/ampproject/amphtml/issues/22543 ), though it could probably be renewed.

[JoshMnem]

It's the other way around -- AMP pages show a blank page for 8 seconds for people with ad-blockers because of that CSS rule.

[gregable]

The behavior you describe occurs if the useragent blocks the URL https://cdn.ampproject.org/v0.js which does not have anything to do with ads or analytics.

Certainly an ad blocker can be used to block any URL, but I don't know of any that block this one by default. If there are any, let me know and I'm happy to file issues to get that fixed!

If a user chooses to block this particular resource which the page needs to load, then the page still loads after 8s.

Similarly, if the site owner chooses, they can run the AMP Toolbox optimizer (https://www.npmjs.com/package/@ampproject/toolbox-optimizer) which lays out the page server-side and removes this CSS flash for most documents. Some documents can't be laid out until the viewport size is known.

[JoshMnem]

People who block JS by default but who don't want to completely turn off JavaScript encounter that 8-second delay. (I'm using "ad-blocker" loosely -- it refers to any kind of tool that blocks ads and tracking. On my computer, it's blocked at the hosts level in addition to an add-on.)

Some people don't want to load resources from Google's servers, and they shouldn't be punished for it. That JS file isn't needed for AMP pages to load. People don't need to load JS to read text and view images. I don't think there is any reasonable argument to have any users hit an 8-second delay.

[gregable]

Without the Javascript file, the images will not load. AMP loads images using a custom element <amp-img> which has performance benefits such as lazy loading of images until they are close to the visible viewport and guaranteeing a stable layout that will not cause the elements on the page to jump around. The downside is that until Javascript is loaded, these images are not available to the browser.

[lillecarl]

Couldn't this be solved by the adblockers by injecting some JS to change this?

[stjohnswarts]

there's a good reason for that because if you don't google can track you everywhere by IP, or at least have a reasonable guess that it's you or someone in your house.

[stephenr]

The AmpProject is without question controlled by Google, so I reject your claim that it "does not have anything to do with ads or analytics".

The company is an advertising company. If 90+% of your revenue comes from one thing, that's what you are. Anything else is a gimmick.

That tech fanboys continue to ignore or refute this fact about Google just shows how much Kool aid they've consumed, I assume by skipping the drinking part and going straight to Kool Aid baths and Kool aid enemas.

Blocking third party resources on a site is not a "bug" that needs to be "fixed".

[munk-a]

This will hit a lot of people on the web today that have given up on a blanket block on JS (because a lot of pure text content simply fails to render without JS, yaaaaay) but do have a blanket blacklist on JS assets and whitelist requests on a need basis.

[4ntonius8lock]

As intended. We desperately need some anticompetitive scrutiny on google.

Unfortunately... https://www.opensecrets.org/orgs/summary.php?id=d000067823