5 ms·

I sadly have to code AMP for work. The reason you see a white page is that the boilerplate code required for any AMP page to be valid includes : webkit-anima

I sadly have to code AMP for work. The reason you see a white page is that the boilerplate code required for any AMP page to be valid includes : webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both; With visibility set to hidden for every element on the page. This is used to minimize page rendering artifacts for the end user, which is one of AMP's main goals, content should be fixed. The problem however here is that this animation is usually triggered before the 8s, as soon as the AMP javascript has been served from the CDN. Your adblocker of something of the sort is blocking it which results in you having to wait for the hard coded 8s fallback to see the page no matter if the content is already loaded. AMP is beautiful.

SimeVidas 8y ago
8 seconds? I thought it was 3. That being said, this is most likely the culprit. If OP is blocking AMP CDN, the inlined CSS code will hide the content until the CSS animation completes after whatever the timeout is nowadays.
- gregable 8y ago
  This CSS animation is just the backup in case the javascript doesn't load at all, really. After 8 seconds, the page gives up trying to prevent the flash of unstyled content and just renders, regardless of how bad the styling is. It also includes a <noscript> block that renders the page immediately if javascript is disabled. The 8s thing is for network issues. Graceful degradation. Lots of documents (amp or not) use the same "hide the screen until layout is done" trick to avoid multiple relayouts as the initial javascript is running and CSS is being fetched. More often than ideal, they don't have a fallback if the javascript doesn't load at all. AMP mandates it with this CSS animation, which is far better than nothing. Also when served from the AMP Cache (https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk/how_5840711_test-electrical-outlet-digital-multimeter.html https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk... for the example shown), the layout algorithm that javascript runs is applied by the AMP Cache instead and the 8-second timeout code is removed completely (view source and take a look). This doesn't work on all pages - there are some features that require a client-side context, but it does work on this one. Websites can run the same server-side layout algorithm on their origin using a node library (https://www.npmjs.com/package/amp-toolbox-optimizer https://www.npmjs.com/package/amp-toolbox-optimizer). There is also work being done to improve all of this (server side layout on more documents, and making the system easier to run on your own site). The 3s observation from the original post is interesting. It may just have been an estimation of the 8s, or it could have something to do with how the document is configured. Looking at this document, there are some <amp-font> tags that the document author has added with a 3000ms timeout. These are tags that instruct the AMP javascript to change the document CSS class depending on the success of failure of loading of a particular font. By default (not amp specific), if a document loads a webfont for a particular text, the browser will not display the text until the font is loaded. <amp-font> provides a CSS hook by which the author can do stuff like "hide the text for up to 3s, or when the font has loaded, whichever comes first". This page has some <amp-font> tags with a 3s timeout referencing fonts that have not been added to the document, which seems like a mistake from the document author, unsure. I was not able to reproduce the 3s experience though, so this may be incorrect speculation as to what happened.
  - NeedMoreTea 8y ago
    > Lots of documents (amp or not) use the same ... trick Perhaps luck, but I have never encountered one that is so hostile about it with nearly 10s wait outside of AMP. I've rarely encountered a second or so's delay, but two or three sites including a large one that have the massively excessive AMP delay. So to call it the same trick seems like a stretch from a user annoyance point of view.
    - y4mi 8y ago
      but why should they improve your experience, who has ad-block enabled and as such not creating any value to the website owner? It annoyed me as well before, though I realized as I stopped going there that this is for the best... for both my sanity and the websites bottom line.
      - NeedMoreTea 8y ago
        Sometimes it's that simple, often it's not. There's still plenty of sites available without such hassles so it's not yet a problem finding alternatives. On the other hand an ad blocking user is not necessarily producing no value for the site. I've had subs to newspaper sites, all of which I viewed with blocking on, and Independent will never now be one of them. If Guardian did likewise, and added AMP, I'd cancel my current sub and look elsewhere, which would be a definite loss of value for them. I'm not so wedded to the views of any one outlet that I'd subscribe with this in place, or turn off blocking to subscribe, or feel I must subscribe to the same one indefinitely. If it's a site I wouldn't have considered a sub or donation to, you're right, nothing is lost.
      - jacquesm 8y ago
        Accessibility.
        y4mi 8y ago
        That claim is pretty shallow. The content is there, it's just hidden through css. If anything, a screen reader has access to the content earlier than the unimpaired people.
lucb1e 8y ago
> code required for any AMP page to be valid includes: [sleep 8 to avoid rendering artifacts] That sounds awfully convenient for whoever cooked this up.
justinph 8y ago
I, too, sadly have to code on AMP bullshit for work. To be a valid AMP page (at least, according to the Google overlords) you _must_ use the CDN'd AMP scripts. This is the very antithesis of what the world wide web is supposed to be about. IMHO, it's not at all unreasonable to block stuff from domains you don't trust, especially domains controlled by large surveillance corporations. The web should be more resilient. AMP makes it brittle.
- gtf21 8y ago
  > IMHO, it's not at all unreasonable to block stuff from domains you don't trust, especially domains controlled by large surveillance corporations. The web should be more resilient. AMP makes it brittle. My thoughts exactly, this is what makes me nervous about AMP, it feels like it's pushing the web in a direction that is alien to its original ideas.
NeedMoreTea 8y ago
Thanks for the enlightenment, this explains why I no longer visit The Independent's website. I naively assumed, to begin with, that they'd pushed out something broken. Except it never got resolved, which surprised considering the length of delay. So I resolved it by pretending they no longer exist. I'll likely never know if they ever do resolve it.
black-tea 8y ago
8 seconds! I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. It was often imperceptible. Oh how we've regressed.
- SquareWheel 8y ago
  >I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. That has to be rose-tinted glasses. Networks used to be excruciatingly slow. I would walk away waiting for page loads during the dial-up era. Our expectations have simply been adjusted over time.
  - jefftk 8y ago
    If black-tea had a good connection at a time when the rest of us were on dial-up, and all the sites were coded expecting dial-up, they may well have seen excellent load times! (But yeah, I remember the internet being super slow. JPEGs coming down scanline-by-scanline.)
- gtf21 8y ago
  I don't remember it being milliseconds, but it definitely didn't take _this_ long, especially not if I had had the same connection speed I have now.
EvilTerran 8y ago
From my reading of https://www.ampproject.org/docs/fundamentals/spec https://www.ampproject.org/docs/fundamentals/spec, it looks like you could override this behaviour in uBlock Origin with a style cosmetic filter. Something like... ##html[amp] body,html[\26A1] body:style(animation:none!important) (I can't test it in my current browser, unfortunately, but I think that's right.) [edit] Update: I got to a browser I could test it on. Unfortunately, it turns out uBO doesn't let you apply :style() rules to all pages indiscriminately, you have to specify a domain name pattern - which is pretty annoying, because the principle is evidently sound; this does work on the link in OP: ehow.co.uk##html[amp] body,html[\26A1] body:style(animation:none!important) Hrmph. Alternatively, you could use a CSS injection addon (or userContent.css, in Firefox) to add the rule to all pages: html[amp] body, html[\26A1] body { animation: none !important; } Or do it with a userscript (ie via Greasemonkey or similar). [edit 2] It appears uBO is aware of a need for something like this - they provide an injectable "scriptlet" that adds the necessary CSS: https://github.com/gorhill/uBlock/wiki/Resources-Library#ampprojectorgv0js- https://github.com/gorhill/uBlock/wiki/Resources-Library#amp... Unfortunately, scriptlet injection also can't be applied to every page indiscriminately. :/ ! works on OP's link ehow.co.uk##script:inject(ampproject.org/v0.js) ! doesn't work at all ##script:inject(ampproject.org/v0.js) So I'm just mentioning it here for completeness' sake.
- fixermark 8y ago
  And if uBlock needs to be modified to make your Amp-adjacent experience better, it's probably a bug uBlock's team should be notified about.
  - cramforce 8y ago
    Has it been figured out which adblock list accidentally blocked AMP? We'd like to contact them. This is clearly a bug, since blocking AMP is not related to blocking ads (all the normal ad blocking rules should do the job just fine).
    - gtf21 8y ago

SimeVidas 8y ago

8 seconds? I thought it was 3. That being said, this is most likely the culprit. If OP is blocking AMP CDN, the inlined CSS code will hide the content until the CSS animation completes after whatever the timeout is nowadays.

gregable 8y ago
This CSS animation is just the backup in case the javascript doesn't load at all, really. After 8 seconds, the page gives up trying to prevent the flash of unstyled content and just renders, regardless of how bad the styling is. It also includes a <noscript> block that renders the page immediately if javascript is disabled. The 8s thing is for network issues. Graceful degradation. Lots of documents (amp or not) use the same "hide the screen until layout is done" trick to avoid multiple relayouts as the initial javascript is running and CSS is being fetched. More often than ideal, they don't have a fallback if the javascript doesn't load at all. AMP mandates it with this CSS animation, which is far better than nothing. Also when served from the AMP Cache (https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk/how_5840711_test-electrical-outlet-digital-multimeter.html https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk... for the example shown), the layout algorithm that javascript runs is applied by the AMP Cache instead and the 8-second timeout code is removed completely (view source and take a look). This doesn't work on all pages - there are some features that require a client-side context, but it does work on this one. Websites can run the same server-side layout algorithm on their origin using a node library (https://www.npmjs.com/package/amp-toolbox-optimizer https://www.npmjs.com/package/amp-toolbox-optimizer). There is also work being done to improve all of this (server side layout on more documents, and making the system easier to run on your own site). The 3s observation from the original post is interesting. It may just have been an estimation of the 8s, or it could have something to do with how the document is configured. Looking at this document, there are some <amp-font> tags that the document author has added with a 3000ms timeout. These are tags that instruct the AMP javascript to change the document CSS class depending on the success of failure of loading of a particular font. By default (not amp specific), if a document loads a webfont for a particular text, the browser will not display the text until the font is loaded. <amp-font> provides a CSS hook by which the author can do stuff like "hide the text for up to 3s, or when the font has loaded, whichever comes first". This page has some <amp-font> tags with a 3s timeout referencing fonts that have not been added to the document, which seems like a mistake from the document author, unsure. I was not able to reproduce the 3s experience though, so this may be incorrect speculation as to what happened.
- NeedMoreTea 8y ago
  > Lots of documents (amp or not) use the same ... trick Perhaps luck, but I have never encountered one that is so hostile about it with nearly 10s wait outside of AMP. I've rarely encountered a second or so's delay, but two or three sites including a large one that have the massively excessive AMP delay. So to call it the same trick seems like a stretch from a user annoyance point of view.
  - y4mi 8y ago
    but why should they improve your experience, who has ad-block enabled and as such not creating any value to the website owner? It annoyed me as well before, though I realized as I stopped going there that this is for the best... for both my sanity and the websites bottom line.
    - NeedMoreTea 8y ago
      Sometimes it's that simple, often it's not. There's still plenty of sites available without such hassles so it's not yet a problem finding alternatives. On the other hand an ad blocking user is not necessarily producing no value for the site. I've had subs to newspaper sites, all of which I viewed with blocking on, and Independent will never now be one of them. If Guardian did likewise, and added AMP, I'd cancel my current sub and look elsewhere, which would be a definite loss of value for them. I'm not so wedded to the views of any one outlet that I'd subscribe with this in place, or turn off blocking to subscribe, or feel I must subscribe to the same one indefinitely. If it's a site I wouldn't have considered a sub or donation to, you're right, nothing is lost.
    - jacquesm 8y ago
      Accessibility.
      - y4mi 8y ago
        That claim is pretty shallow. The content is there, it's just hidden through css. If anything, a screen reader has access to the content earlier than the unimpaired people.

lucb1e 8y ago

> code required for any AMP page to be valid includes: [sleep 8 to avoid rendering artifacts] That sounds awfully convenient for whoever cooked this up.

justinph 8y ago

I, too, sadly have to code on AMP bullshit for work. To be a valid AMP page (at least, according to the Google overlords) you _must_ use the CDN'd AMP scripts. This is the very antithesis of what the world wide web is supposed to be about. IMHO, it's not at all unreasonable to block stuff from domains you don't trust, especially domains controlled by large surveillance corporations. The web should be more resilient. AMP makes it brittle.

gtf21 8y ago
> IMHO, it's not at all unreasonable to block stuff from domains you don't trust, especially domains controlled by large surveillance corporations. The web should be more resilient. AMP makes it brittle. My thoughts exactly, this is what makes me nervous about AMP, it feels like it's pushing the web in a direction that is alien to its original ideas.

NeedMoreTea 8y ago

Thanks for the enlightenment, this explains why I no longer visit The Independent's website. I naively assumed, to begin with, that they'd pushed out something broken. Except it never got resolved, which surprised considering the length of delay. So I resolved it by pretending they no longer exist. I'll likely never know if they ever do resolve it.

black-tea 8y ago

8 seconds! I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. It was often imperceptible. Oh how we've regressed.

SquareWheel 8y ago
>I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. That has to be rose-tinted glasses. Networks used to be excruciatingly slow. I would walk away waiting for page loads during the dial-up era. Our expectations have simply been adjusted over time.
- jefftk 8y ago
  If black-tea had a good connection at a time when the rest of us were on dial-up, and all the sites were coded expecting dial-up, they may well have seen excellent load times! (But yeah, I remember the internet being super slow. JPEGs coming down scanline-by-scanline.)
gtf21 8y ago
I don't remember it being milliseconds, but it definitely didn't take _this_ long, especially not if I had had the same connection speed I have now.

EvilTerran 8y ago

From my reading of https://www.ampproject.org/docs/fundamentals/spec https://www.ampproject.org/docs/fundamentals/spec, it looks like you could override this behaviour in uBlock Origin with a style cosmetic filter. Something like... ##html[amp] body,html[\26A1] body:style(animation:none!important) (I can't test it in my current browser, unfortunately, but I think that's right.) [edit] Update: I got to a browser I could test it on. Unfortunately, it turns out uBO doesn't let you apply :style() rules to all pages indiscriminately, you have to specify a domain name pattern - which is pretty annoying, because the principle is evidently sound; this does work on the link in OP: ehow.co.uk##html[amp] body,html[\26A1] body:style(animation:none!important) Hrmph. Alternatively, you could use a CSS injection addon (or userContent.css, in Firefox) to add the rule to all pages: html[amp] body, html[\26A1] body { animation: none !important; } Or do it with a userscript (ie via Greasemonkey or similar). [edit 2] It appears uBO is aware of a need for something like this - they provide an injectable "scriptlet" that adds the necessary CSS: https://github.com/gorhill/uBlock/wiki/Resources-Library#ampprojectorgv0js- https://github.com/gorhill/uBlock/wiki/Resources-Library#amp... Unfortunately, scriptlet injection also can't be applied to every page indiscriminately. :/ ! works on OP's link ehow.co.uk##script:inject(ampproject.org/v0.js) ! doesn't work at all ##script:inject(ampproject.org/v0.js) So I'm just mentioning it here for completeness' sake.

fixermark 8y ago
And if uBlock needs to be modified to make your Amp-adjacent experience better, it's probably a bug uBlock's team should be notified about.
- cramforce 8y ago
  Has it been figured out which adblock list accidentally blocked AMP? We'd like to contact them. This is clearly a bug, since blocking AMP is not related to blocking ads (all the normal ad blocking rules should do the job just fine).
  - gtf21 8y ago