Giters

ampproject / amp-sw

A drop in service worker library to help your AMP pages gain network resiliency in 1 line

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AMP HTML documents handled via NetworkFirst strategy

gilbertococchi opened this issue · comments

commented

Hi amp-sw community, I've noticed that the current logic of amp-sw might cause a FCP regression on AMP sites using HTTP caching on HTML documents but also using amp-sw "as is".

Below a screenshot for amp.dev showing that page refresh requests seems treated as Network First, always downloading the HTML document from Network.
unnamed

If this is triggered by the enablement of an offline page I would suggest to switch to a CacheFirst strategy instead, maybe with a customisable max-age as safe lock or just relying on the SW versioning for caching.

FCP should improve significantly on sites using amp-sw with this strategy change.

commented

hi @gilbertococchi!

@sebastianbenz - Happy to change this on amp.dev - are you wanting to change the default behavior for amp-sw? or document why such an option should be used? would be a pretty large breaking change, but certainly doable

commented

Changing the default would mean revisiting the decisions here: https://github.com/ampproject/amp-sw/tree/master/src/modules/document-caching

Considering the low usage of the module, this could be done with a major revision bump.

Would @sebastianbenz or @patrickkettner want to test this on AMP.dev?

commented

Followed up in-person (over VC) and we decided to first test using a CacheFirst strategy using an override on amp.dev before changing the default.

commented

Would it be possible to remove default AMP HTML document caching first and respect the HTTP Caching default behaviour?
I believe that would be the safest option and then developer can intentionally handle HTML documents via their preferred Caching strategy with an ad hoc regex rule as it's possible with WorkboxJS

commented

Just chiming in here from a service worker perspective:

  • The CacheFirst strategy in Workbox will not update the cache "in the background" if there is a cache hit. In order words, once an HTML document is cached locally, it's effectively cached for good. I'm assuming it's not what you want for a URL that isn't uniquely revisioned. Instead, StaleWhileRevalidate would give you "use the cache if possible, but also update the cache in the background" behavior, which would be much safer to use. You might also want to explore some of the options for writing custom strategies in Workbox v6 described in this article.

  • Workbox does honor standard Cache-Control headers when it goes to the network, either in the NetworkFirst strategy or during revalidation in StaleWhileRevalidate. So if those headers are being set, you should already see them take effect.

  • Whenever you're using a service worker and potentially require a network call in order to fulfill navigation requests, using navigation preload is a best practice from a performance perspective. (Unfortunately, it's only supported in Chrome.) If you're not already using it, workbox-navigation-preload makes it pretty easy to opt-in to using it.

  • Happy to follow up with any clarifications as needed!

commented

On these points:

  • Right now amp-sw is extended from v3 of workbox.
  • It utilizes navigation preload.
  • By default uses an extended version NetworkFirst for navigation requests to AMP documents.

We haven't upgraded to later versions of workbox due to people's availability.