Hi Greg, Thanks for your response here. I think we'll just have to agree to disagree on a number of points, but there's a few I would like to comment on:

Hi Greg, Thanks for your response here. I think we'll just have to agree to disagree on a number of points, but there's a few I would like to comment on: If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration. As per the screenshot, Google Pagespeed appears to disagree. Looking at the headers via curl, I see "expires" with the current date and time (ie, it's already expired), a max-age tag of 50 minutes. I'm not seeing one year anywhere. If the 30 day stale-while-revalidate really invalidates those two headers, and I'm not knee-deep in browser support enough to really know, can someone at Pagespeed please consider this a bug? The issue has come up a number of times on various forums over the years in relation to the vanilla analytics.js, and the answer that's usually accepted is "just self host the Javascript". I'm calling it now - people will start doing this with AMP scripts if Pagespeed doesn't change the warning, regardless of the consequences. trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. Thanks for explaining that. It makes sense in a way I don't see another way of doing it - but the AMP website[0] suggests this should "just work". If it in fact only works "in certain CORS environments", what I'm hearing is that most people testing these AMP sites just have those environments and assume everyone else does. Which may be concerning from a security point of view. [0] https://www.ampproject.org/docs/tutorials/create/preview_and_validate https://www.ampproject.org/docs/tutorials/create/preview_and...