Using a CDN isn't the problem on it's own; the problem is the (unfortunately common) shoddy programming practice of assuming error never happen. Good programming almost always involves checking for and properly handling errors. Using the returned value from fopen(3) without checking if it was NULL probably results in the program crashing when displaying a simple "file not found" error message would have been more appropriate.
This principle is also true when writing web pages; if you load an external resource, you need to check for and handle the case where that resource might not be available. Failing to load a resource can happen for many different reasons, not just someone blocking it with their client. Proper handling the error depends on what the resource is: display the content that is already available (perhaps in a less than ideal state), or if that isn't possible displaying an appropriate error message. This includes cases where the Javascript itself isn't available (for any reason).
Networks are not reliable or universally available. Quality programming understand that and does the best it can when failures happen.
I agree with you. However understand that AMP actually does have a failsafe here, and it's exactly what the OP is complaining about. After a timeout (to allow for shoddy network conditions as you described) it will load the content as best it can.
All three cases are actually covered (full-script support, partial-script support, and noscript support). That's more resilient than most apps.
Agree. To put it another way in hope of driving this home:
It is sad when the brightest minds in the world decide that the fix for "flash of unstyled content" is to show no content at all for close to 10 seconds.
Seriously: 8 seconds mandatory waiting would have been considered slow even 10 years ago and the only reason it passes now is because Google got a stranglehold on most of the web.
If you turn off all scripts AMP has a <noscript> block that disables the 8s timeout. The OP is blocking only external scripts, which not surprisingly looks a lot like a very bad network connection.
(Disclosure: I work at Google on making ads be AMP)
> Why 8s though? That’s well into “give up on loading this page, close the tab and try somewhere else” territory.
That 8s timeout is for loading the AMP JS from the CDN. You want a time limit that separates "you're on a slow connection, keep waiting" and "just give up, it's not worth it". I suspect it was set by looking at network graphs, but I don't know.
What the OP is doing, blocking JS and also ignoring <noscript>, is bizarre, and something you should expect to break sites.
> Perhaps a better option is finding ways to prevent content jumping around so much while assets are loading.
AMP does that very well, but only by taking control of the process of rendering, which requires JS.
No, the page loads perfectly fine if Javascript disabled. It's only if you go out of your way to break the page in the most difficult way possible that the script will fallback to having a delay.
This principle is also true when writing web pages; if you load an external resource, you need to check for and handle the case where that resource might not be available. Failing to load a resource can happen for many different reasons, not just someone blocking it with their client. Proper handling the error depends on what the resource is: display the content that is already available (perhaps in a less than ideal state), or if that isn't possible displaying an appropriate error message. This includes cases where the Javascript itself isn't available (for any reason).
Networks are not reliable or universally available. Quality programming understand that and does the best it can when failures happen.