Open ebidel opened 8 years ago
I like it! And then we can continue serving the content cache-first once it actually gets requested from the network because it's used for the first time on a page.
(FWIW, this change to skip cache-busting when the developer indicates that they're properly versioning their resources will help cut down on the precache data transfer, too.)
Want me to take a stab? I need to get more familiar with the lib codebase. Pointers are appreciated!
On Tue, Jul 19, 2016, 7:07 AM Jeffrey Posnick notifications@github.com wrote:
I like it! And then we can continue serving the content cache-first once it actually gets requested from the network because it's used for the first time on a page.
(FWIW, this change https://github.com/GoogleChrome/sw-precache/commit/d06def1171704f2ecbbb29d2a4a902ac977ae66e to skip cache-busting when the developer indicates that they're properly versioning their resources will help cut down on the precache data transfer, too.)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/sw-precache/issues/145#issuecomment-233643822, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOigO-Fr13Fo9BeOKzJcJK4ST1DzTwIks5qXNn_gaJpZM4JPQJK .
If you want to dip your toes in, sure!
I'd imagine it would involve creating a new option and treating it in a similar fashion to staticFileGlobs
, except that instead of using its matches to populate precacheConfig
, you'd create something like a new optionalPrecacheConfig
, which you'd then pass into the template rendering function.
And then in the template, you'd need an insertion point for the new optionalPrecacheConfig
. Inside the install
handler you could check the value of Save-Data: on
header... but wait, that header is only set on incoming Request
s within a fetch
event, and isn't available within the install
handler, which is where all the precaching is done. 😦
Let me ask around a bit if there are ways to detect the same information supplied by Save-Data: on
before the first fetch
event is made.
See https://github.com/WICG/netinfo/issues/42, which tracks exposing the information that we'd need to make that determination inside the install
handler.
For content heavy sites (images, videos, etc.), precaching can introduce increased bandwidth consumption for slower connections.
sw-precache should have an option where the sw respects the
Save-Data: on
header if it is set by the client and precaches fewer resources. How this opt-in actually works is open for discussion. Perhaps users could mark critical resources. Other resources listed in the precache list are deemed optional.https://developers.google.com/web/updates/2016/02/save-data