w3c / w3c/ServiceWorker

Consider mechanisms to bypass the service worker for things that we know won't be in it's cache

Open
#1,026 18 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

apr-2017-f2f
Dominant language
Bikeshed
Stars
3.6k
Forks
324
Avg merge
14d 22h
Merged PRs (30d)
1

Description

The Problem

There will always be some number of resources that we cannot cache in the Service Worker. Perhaps this is segments of a 360 VR video or something like a profile picture that just changed. In many case it's possible that the client will know in advance that the Service Worker does not have this resource cached yet the request for it still need to go through the Service Worker.

Right now the process of sending a request from the main thread to a Service Worker can take a few milliseconds in many implementations. Then we have to wait on the event loop in the Service Worker (which we always have to do even in the best case scenario). Facebook tends to send large bursts of resource requests as the page loads. If we send 40 or so requests from the window at once, while the first few may be quick, the other events get tacked onto the end of the Service Worker event loop and end up getting delayed quite a bit before they can hit the network. Even though the Service Worker won't call respondWith for these events they still get delayed by the busy Service Worker event queue.

Proposed Solution

The window will generally know it has a resources that there's no way the Service Worker has in cache. It'd be nice if there was a way for the service worker to be totally bypassed when this resource is requested. Perhaps this is an API on the service worker registration that lets you mark URLs as bypassable, perhaps we add this as a fetch option and let you add fetch options to html tags, perhaps we come up with some url scheme that let's you bypass the sw. I'm not sure what the right solution is, but I'd like to start thinking about what one could be :)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by reviewing the service worker request path and the proposed bypass mechanisms described here, then use the comment discussion to determine whether there is agreement. Done would be a decided API or specification direction for bypassing the service worker, not merely another proposal.

Written by the indexing model from the issue text.

Assessment

Domain
api, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.