Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add importance: 'low' to precaching requests #1855

Closed
jeffposnick opened this issue Jan 22, 2019 · 8 comments · May be fixed by #3295
Closed

Add importance: 'low' to precaching requests #1855

jeffposnick opened this issue Jan 22, 2019 · 8 comments · May be fixed by #3295

Comments

@jeffposnick
Copy link
Contributor

jeffposnick commented Jan 22, 2019

Priority Hints is currently being experimented with in Chrome, and may come to other browsers in the future.

We can make use of them to mark the fetch() requests used for precaching as being low-priority, to reduce the chance that they will consume bandwidth needed for requests made from the window context.

CC: @addyosmani

@jeffposnick
Copy link
Contributor Author

Ditto for the revalidation request used in the staleWhileRevalidate strategy; see https://stackoverflow.com/questions/54305729

@philipwalton
Copy link
Member

@addyosmani do we know yet how priority will get exposed in FetchEvents? I'm assuming it'll end up being a property on Request, but it's not clear to me from looking at the draft.

@jeffposnick
Copy link
Contributor Author

The example from the spec for making requests is

<script>
 // Critical Fetch request for article content
 fetch('/api/articles.json', { importance: 'high' }).then(/*...*/)

 // Request for related content now reduced in priority
 // reducing the opportunity for contention
 fetch('/api/related.json', { importance: 'low' }).then(/*...*/)
</script>

i.e. it gets passed in as either FetchOptions when calling fetch(), or the underlying RequestInit when constructing a Request.

That would imply that it's exposed as event.request.importance inside of a fetch event, following the model for how the other properties used in RequestInit are exposed on the underlying Request.

@jeffposnick
Copy link
Contributor Author

CC: @khempenius, who expressed some interest in this.

@dtruffaut
Copy link

dtruffaut commented May 28, 2019

I approve this feature 👍

https://twitter.com/DenisTRUFFAUT/status/1133372511280869376

@daffinm
Copy link

daffinm commented Mar 10, 2020

I think this feature is needed to make precaching a truly progressive feature of any PWA.

Right now, and under certain circumstances (e.g. poor mobile data connection and a few megs of assets to precache), precaching initially worsens the user experience and must be compensated for -- e.g. delayed service worker registration & loading screen upon service worker registration that is closed upon activation.

It look forward to the days of smarter (it's already pretty good) precaching :-)

@jeffposnick
Copy link
Contributor Author

I've posted this elsewhere, but just to reflect the most recent status on this issue: Priority Hints went through the Origin Trial process in Chrome, and did not progress past that in their current incarnation.

So we're currently blocked on implemented anything in Workbox until at least one browser ships this feature.

Folks can check https://chromestatus.com/feature/5273474901737472 and ⭐️ https://bugs.chromium.org/p/chromium/issues/detail?id=821464 for updates.

@taozhou-glean
Copy link

should we revisit this given that now the Request.init#priority has been supported on multiple browsers:

image

https://caniuse.com/?search=request.init%20priority

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants