3 ms·

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,

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.

geofft 9y ago
> 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.

3 ms·

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,

by keeperofdakeys 9y ago

geofft 9y ago
> 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.