Define a preaching strategy about ioweb2015 HOT 4 CLOSED

My current thinking, after experimenting a bit in the https://github.com/jeffposnick/gulp-sw-precache project:

• Define groups of resources:
  • Generally, use glob patterns based on file extensions.
  • Within the set of files that match a certain pattern, identify "volatile" files that are most likely to change and create a distinct group for those. E.g. all the bower_components/**.js files are unlikely to change, while the scripts/**.js files are much more likely to.
• Each group of resources will be stored in an individual service worker Cache object. The Cache will be named/versioned based on a combination of the group identifier + a hash of each file's contents. If any of the files that make up a group change, the entire Cache gets invalidated and all of the files in that Cache will be refetched.
• To prevent accidentally pulling down, e.g., 10MB of image data in the install handler when a user first visits a page, impose an upper limit on the size of each cache (likely: 1MB) as well as a limit on the number of files in each (likely: 100 files). This is more of a sanity check than anything else.

shed doesn't offer flexibility with regard to naming and versioning individual caches, so we're going to have to go bare-metal service worker for the implementation.

from ioweb2015.

Is 1MB too small though? A few of the site's images alone will fill that up.

from ioweb2015.

I've been talking to some of the service worker eng. folks about this, and they confirmed that there's no technical reason why we can't maintain distinct, named caches for each individual resource. There might be a marginal slowdown when it comes to looking up entries, but we'd get the benefit of only expiring resources that change, without incurring the penalty of refetching unchanged resources that happened to be grouped together in the same cache.

I'm going to go with that approach, which is conceptually the same thing as what I implemented in https://github.com/jeffposnick/gulp-sw-precache, except that the group size would always be 1.

from ioweb2015.

FYI, I just added support for using a dedicated cache for each resource URL (GoogleChromeLabs/sw-precache@e7f91e7) and support for versioning server-generated resources based on all the component template files (GoogleChromeLabs/sw-precache@1e4aa51) into the gulp-sw-precache project.

It seems to work there, and accomplishes everything we need (I think), so I'm now going to port it all into this project.

from ioweb2015.