I will add since I forgot to mention; problem is visible on chrome for android too. And in fact I have discovered this issue by experiencing it one of my PWA projects. It is working many times slower offline than online.

It's because you're using ignoreSearch = true. Chrome's CacheStorage has terrible performance with ignoreSearch because it searches linearly through the keys. This is an unfortunate but known issue.

Leaving the issue open as something we should eventually address.

While it is really unfortunate, I was able to come up with a very convenient workaround.

I check whether if the request url service worker currently handling has a query parameter, and set 'ignoreSearch' to 'true' only if it is.

// check if query has query parameters
var hasQuery = event.request.url.indexOf('?') != -1;
...
// then set the option dynamically
ignoreSearch: hasQuery

I have also posted this solution to stackoverflow: http://stackoverflow.com/questions/41758252/service-worker-slow-response-times

FWIW in gecko we store "url without query" as a separate column to avoid the linear search.

But this sort of thing is why we have in general pushed back on requests for general substring matching in the Cache API.  Its hard to implement without triggering this behavior.

Here's another reduced test-case for this: https://rawgit.com/jakearchibald/23bc89cf49d81c77015f0ef81a1ded75/raw/dcdaa3eb7e9841f689f2f87156affbeaaad7c55d/

Open in Canary with the console open.
Click "Cache stuff" - this caches 200 items.
Click "Fetch from cache via SW" - this fetches the 200 items using caches.match.
Click "Fetch from cache via SW ignoring search" - this fetches the 200 items using caches.match with ignoreSearch.

On my machine, the difference is 330ms vs 13000ms.

Wow, that's incredibly bad. I'll look into this.

Ah yes, I remember why we didn't address this in the first place. CacheStorage's backend (simple cache) doesn't keep the urls in its index, it only keeps a hash of the url in its index. This keeps the index fairly small.

To get the url we have to iterate over each entry, open it, and parse the metadata. Hence the ridiculously long times.

This would be an easy fix if we had a more flexible backend such as sqlite. Instead we're left w/ implementing optionally storing urls in the backend index or storing them on behalf of the backed in the CacheStorage metadata and dealing with synchronization issues.

As this isn't a quick fix and I don't have much time on my hands for this I'm marking it as available.

I have tested changing the name (so the order(at least the order visible to dev tools)) of a particular item in cache to see if that will help. E.g. if placing an item 1st or last place still would require to process all items in the cache. It looks like it does. Seems match does not occur as it iterates over each cache entry but first all items' metadata taken to a temp array, and only then match occur. Statistically speaking, if feasible, it will improve match speed considerably if it match each item against the request as it retrieves the metadata and stop the process if a match is got.

Secondly, are "ignoreVary" and "ignoreMethod" parameters also subject to this problem? Have there been a test for that?

And thridly, @Jake have you tested my workaround given above for this problem and/or come up with an other (perhaps a more efficient one if this one is not) workaround? 
Also, I have spent couple days on this and found nothing written about it anywhere on the internet. Now we have this issue entry and a SO question about it. Would those be enough to guide people out of this problem in the future or would it be necessary and appropriate to place some warnings on Google and MDN docs about this problem?

There is a hacky fix that I can do while we work out what to do with backend indexing. On the first use of ignore-vary we can memoize the keys in the cache, and keep it updated (with future puts/deletes) and use the memoized keys for future ignore-vary calls. So the first will still be slow but the remaining ones will be fast. Jake's example will perform nicely.

Chrome doesn't support multiple vary entries in the same cache, so ignoreVary isn't a performance issue. Same goes for ignoreMethod. Yay more brokenness.

I think it's time we took a serious look at switching to sqllite so that we can get atomic operations and support for more indexes. I don't want to spend more time on hacking around our backend.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is there any progress on this issue?

No progress. If anyone on the storage team wants to take it, we'd likely need to keep a set of stored urls in the CacheStorageCache index. I worry about this set getting out of sync with the backend. I also worry about the size of this in memory. URLs can be quite long. But if we had it, the slow path of QueryCache would be gone which would be amazing.

> I also worry about the size of this in memory. URLs can be quite long.

FWIW you can index a hash of the URL to reduce the footprint of the index.  We do this in the Cache API implementation in gecko.

A list of hashed URLS is what we use for our backend index. The problem is that the "list" function (and ignore query) requires the full urls, so we open each entry and extract the URL which is super slow.