Generate alternative AMP JS URLs

[ithinkihaveacat]

For performance reasons, it's helpful to be able to generate either AMP JS URLs that are either self-hosted (e.g. https://example.com/v0.js; avoids additional host lookup and HTTPS negotiation), or on "versioned" URLs (e.g. https://cdn.ampproject.org/rtv/011905021827420/v0.js; better chance of browser cache re-use).

This parallels the ampRuntimeVersion and ampUrlPrefix configurations of https://github.com/ampproject/amp-toolbox/tree/master/packages/optimizer.

(A corresponding change to the validator is also required.)

/cc @sebastianbenz

[honeybadgerdontcare]

AMP caches will also need to make a change.

[twifkak]

This is an interesting idea to pursue, though only if doing so produces valid AMP.

[twifkak]

The validator/cache change for unsigned AMP is the most interesting, as it enables the performance benefits on origin that you mention. The bug for that should live outside of amppackager.

Publishers aren't expected to serve SXGs directly to users, so the change to amppackager here doesn't make sense. I can see one reason it'd be beneficial here, which is to alleviate some (but not all) of the need for the AMP-Cache-Transform header.

[ithinkihaveacat]

@twifkak Re "bug should live outside amppackager"--where would be a better place? I was thinking adding this feature would involve modifications the transformer library which is (at least currently) part of amppackager--? I think I'm misunderstanding something.

[twifkak]

Sorry, I think I understand now (correct me if I'm wrong). There's several pieces to this:

• update validator & cache to support alternative JS URLs
• update amppackager to consume these alternative URLs
• update transformer library to produce these alternative URLs, disabled by default

The first two are tracked in b/132124544 and b/132120260. The last bug could live externally or internally. We can make this bug that.

[honeybadgerdontcare]

IMO the order of these are

• transformer that lives in AMP caches that takes documents marked as transformed=self and rewrites their script src to their own AMP cache hosted version of the AMP runtime and extensions (generally cdn.ampproject.org).
• create a test suite that verifies this
• allows for transformed=self to have script src be anything in the validator

I don't see amppackager doing anything here, except maybe not taking as input a document that has already been transformed (perhaps a doc with transformed=google is okay). Regardless the validator will verify that the transformations that happen are allowed.

[honeybadgerdontcare]

I don't think we need to do anything here so closing, but open to being wrong and feel free to reopen.

[ithinkihaveacat]

@honeybadgerdontcare I think this should still be open--?

My thinking around this matches https://github.com/ampproject/amppackager/issues/298#issuecomment-491125632: being able to perform this transformation is one of the (many!) things necessary to allow publishers to step away from paired AMP for purely performance reasons, and right now amp-toolbox-optimizer is the only way to generate these transformations.

[honeybadgerdontcare]

You're right we should support this in amppackager (it should accept any valid AMP including valid transformed AMP). However, publishers could still publish both transformed AMP as canonical and transformed AMP as SXG. Both of these things are possible regardless of this issue.