Best Cheap Web Hosting

Every AMP HTML document must at the very least contain the following script tag that is loading AMP's JavaScript from the AMP CDN:

There has been some critique of this design decision so I wanted to take the time to explain the reasoning behind it and lay out how to do better in the future.

The most obvious consequence of centrally hosting the JavaScript is that every AMP page on the internet is always on the latest release. A pull request to AMP's GitHub that makes AMP faster is typically deployed to all AMP pages on the internet within 2 weeks, making all AMP pages faster at once. No page is left behind.

Another big benefit of loading the very same JS URLs on every page is that this leads to much, much better utilization and hit rate of the browser cache. If you've been to an AMP page on publisher X, going to another AMP page on publisher Y will now be faster and cost less bandwidth. AMP is currently in the process of shipping a foreign-fetch ServiceWorker that will make this even more impactful.

Finally, having all AMP pages use explicitly shared JavaScript opens up the possibility of additional optimization by the AMP Caches. While there are a set of requirements for AMP Caches, they don't actually need to use AMP's own JavaScript URLs. Knowing what version (the latest) of AMP a page is compatible with, they can then go and perform additional optimizations using similar techniques to an optimizing compiler. This would be infeasible if they'd need to support what would effectively be all AMP releases ever.

There are, of course, some valid reasons why using centrally hosted JS might not be such a great idea. We do mitigate some of them:

AMP is designed to gracefully deal with the JS failing to load.

AMP is rolled out slowly across pages to catch and fix errors before the full release.

Developers can opt into the "AMP Dev Channel" to test their site with a new release before it is pushed to users.

The JS is loaded from a domain that doesn't have cookies (avoiding the possibility of tracking through them).

Caching (especially with the foreign-fetch ServiceWorker active) leads to the JS being downloaded rarely (further avoiding possibly correlation of IP addresses and referrers).

AMP is 100% open source. Everybody can check that the JS being served from the CDN is exactly what is in the open source repo.

Decentralized hosting of JavaScript files

Having said this, the AMP Project is very interested in supporting decentralized hosting of its JavaScript files.

"Build a decentralized cross-internet 3P script repository with semver semantics."

Our idea is to build a decentralized cross-internet 3P script repository with semver semantics (Think NPM, but with first class support in the web platform and with multiple providers). That could achieve many of the same goals that I outlined above (AMP would mandate wildcarding the patch level in the semver version). Many of us had hopes that subresource integrity could bring some of the cross site caching benefits, but unfortunately that comes with privacy problems (it allows finding out which sites a user has been to) and thus cannot be taken advantage of in web browsers. By limiting such a feature to well known repositories that can be controlled by the user, one could get the clear benefits in a privacy friendly way.

Here is how this would look like:

With this a page author can say:

I'd like to load this library.

Dear browser: Check if the user has a version of it from a set of hosts the client trusts.

If that is not available, load the library from a given location (that may be local).

I think such a mechanism would be a great benefit to most web applications and would likely save users from downloading many petabytes of data every day.

Source: Decentralized hosting of AMP's JavaScript & NPM for the web