amp-fresh

[erwinmombay]

The cache operates on a stale-while-revalidate model. This means that a document when viewed by a user on the client could be stale as revalidation only happens in the background and effects subsequent page views. While this is acceptable for most content, some sections of a page are critical or sensitive enough that it warrants always having the latest piece of information such as item pricing and rating. A good example of this scenario is in e-commerce and long tail product pages which might not be visited often but should have the correct price or quantity remaining when viewed.

---

Will post design doc shortly.

[ericlindley-g]

@erwinmombay — Calling this "Current", but please update if that's not quite right. Thanks!

[jpettitt]

Is this essentially a one time amp-live-list?

[erwinmombay]

@jpettitt the mechanism is, but as far as usage this component is really for an edge case for long tail pages wherein a 1 behind copy from the cache would be bad (like a 1 year old e-commerce page being the user's first landing experience and has super stale quantity count). Will add more documentation soon

[Gregable]

Why not just use standard HTTP expiry headers for communicating this information to the AMP Cache, rather than an HTML tag?

[jpettitt]

Hmm, I knew the cache only took max-age as a hint. However you're saying it doesn't support stale-while-revalidate ? Is there some max ttl or could things theoretically persist forever?

Which error conditions cause the cache to invalidate? If it gets a 404 or 410 I know it drops the doc. What about 5xx codes?

[jridgewell]

Why not just use standard HTTP expiry headers for communicating this information to the AMP Cache, rather than an HTML tag?

Our stale-while-revalidate would cause bad data to be shown while we refetch.

[adelinamart]

What's the latest status here? Thanks.

[ericlindley-g]

Still very important—#7463 may address the primary use cases for this. Will definitely want to keep both top-of-mind.

[cramforce]

#7463 isn't really a replacement for amp-fresh, but #7907 would address the majority of use cases.

[jpettitt]

Any status update on this? We'd like to implement it for school closings / weather on pages where we can't use amp list.

[ericlindley-g]

Thanks for checking in, @jpettitt — Current thinking includes the feature described by @choumx in this issue: #9862 Can you say if that feature would fit your needs?

[erwinmombay]

i believe this has been replaced by amp-bind + amp-state mechanism right @ericlindley-g ? i believe features that amp-fresh would have provided have been covered by amp-bind + amp-state

[ericlindley-g]

That's right, in part: there are a few ways that we're working to address recency in AMP. One is the amp-bind + amp-state mechanism, where amp-state can pull in fresh data at load time. Another is the amp-fresh-like behavior described in #9862

[erwinmombay]

i'll remove the code for amp-fresh and its docs

[ericlindley-g]

Closing this based on features mentioned above that fill the need, but please chime in if your use case for fresh data in AMP pages isn't covered yet (/cc @lswang1618 )

[alankent]

What about seasonal themes? During Christmas, I make significant changes to the CSS and look of the site to make it feel more seasonal. The CSS is in the AMP page, not fetched via amp-bind/amp-state etc. To stop Christmas themed pages coming up for tail products later, I think it would be useful for a site to control the stale-while-revalidate timeout. E.g. a site might set it to a value like a few days so seasonal themes cannot last too long in the cache (or set it based on how many days before Christmas so they all time out exactly on Christmas eve).

[ericlindley-g]

That a good use case to cover — I think the solution would be to fix this directly in a given AMP Cache. My assumption is that the existing update-cache request for the Google AMP Cache would trigger a fetch on too many pages at once for some merchants to be practical (?)

@alf7 and @rudygalfi for thoughts

[cramforce]

The update cache API is the way to go. Merchants can throttle requests so it doesn't overwhelm themselves.

[alankent]

First, yes, if a ecomm site had 1M SKUs, that would be 1M update-cache requests.

But more importantly, you are assuming the Google AMP Cache is the only cache. A merchant should not have to know what caches have been implemented. Making the merchant responsible to set a stale-while-revalidate (or max-stale or whatever) timeout header is fine, but asking them to keep an up to date list of caches seems "wrong".

[cramforce]

The way use of the API is documented, it automatically picks up new caches. https://developers.google.com/amp/cache/update-cache It would definitely be good to hear from e.g. AliExpress how they are handling the problem. I'm open to thinking about changes, but this is a clear case where our main design rule comes into play: https://github.com/ampproject/amphtml/blob/master/contributing/DESIGN_PRINCIPLES.md#user-experience--developer-experience--ease-of-implementation The solution with the great DX (allowing short max-stale times) leads to undesirable UX, so we need to be more creative and we need to challenge the status quo. I've personally launched dozens of e-commerce sites and I know the "best practices"–they just aren't always good practices.

…

On Wed, Apr 11, 2018 at 4:05 PM, Alan Kent ***@***.***> wrote: First, yes, if a ecomm site had 1M SKUs, that would be 1M update-cache requests. But more importantly, you are assuming the Google AMP Cache is the only cache. A merchant should not have to know what caches have been implemented. Making the merchant responsible to set a stale-while-revalidate (or max-stale or whatever) timeout header is fine, but asking them to keep an up to date list of caches seems "wrong". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFeTw2Q8H8KvVEqFDlxru-uzB6fD8bJks5tnoxXgaJpZM4JUd81> .