News for hackers. Stuff that matters.
Re:Improving URLs for AMP Pages by keeperofdakeys on Wednesday January 10, 2018 @04:54AM (#16113729)
The web package definitely originates at the origin, but is it up-to-date? While I assume the web packages have expiry dates that the CDN servers would respect, this doesn't give the full control that Cache-Control headers do.

And in terms of functionality, does the AMP web version have all the functionality of the normal site? Often this is something I see missing on AMP sites. A top-bar gives you the ability to get back to the full site.

Re:Improving URLs for AMP Pages by geofft on Wednesday January 10, 2018 @11:02AM (#16115893)
> The web package definitely originates at the origin, but is it up-to-date? While I assume the web packages have expiry dates that the CDN servers would respect, this doesn't give the full control that Cache-Control headers do.

I think it's the other way around - webpackages include Expires: headers for each resource that are signed by the origin, so the browser decides whether to trust it or not, or maybe to render it anyway but show a staleness indicator. But if you're using a CDN, the CDN implements caching on its own (hopefully following the origin server's instructions or the customer's instructions in a control panel, but no guarantee) and all headers are entirely controlled by the CDN.

> And in terms of functionality, does the AMP web version have all the functionality of the normal site?

On the technical side, this is now the origin's decision, not Google's - they can include whatever functionality they want or whatever links they want in the webpackage. It's not really different from having a mobile site that has a "View full site" link, or worse, doesn't have one and also misdetects your browser.

I think I agree that in practice it matters a lot what people choose to do, and whether Google adds restrictions for what sorts of webpackages count as "AMP" for the purpsoe of special treatment on the search results page.