Currently the cache_storage backend uses a SequenceTaskRunner with TaskPriority::BEST_EFFORT:

https://cs.chromium.org/chromium/src/content/browser/cache_storage/cache_storage_context_impl.cc?l=37-40&rcl=1ad8e3411d765440af317eda4f5715d232b00317

If I'm reading the TaskScheduler code correctly that schedules cache query operations at the lowest priority.  In addition, the total number of threads across the browser permitted for this priority seems to be 1 or 2.  Also, I believe that if there are many higher priority tasks then BEST_EFFORT tasks may be arbitrarily delayed.

In contrast, other storage APIs like IndexedDB pass TaskPriority::USER_VISIBLE:

https://cs.chromium.org/chromium/src/content/browser/indexed_db/indexed_db_context_impl.cc?l=116-119&rcl=abc915422e0d17fd1f8dda95b42d18b75b4159e0

Also, perhaps more importantly, reading Blob data uses USER_VISIBLE as well:

https://cs.chromium.org/chromium/src/storage/browser/blob/blob_reader.cc?l=76-77&rcl=abc915422e0d17fd1f8dda95b42d18b75b4159e0

This is potentially bad news for sites using service workers to offline their content.  If the SW goes to Cache API for many requests in a short period you could end up with early response body reading starving out later cache.match() calls.  Given that service workers must round trip the cache.match() result to the script before the body can start to be read this may add significant delay to the overall loading process.

Of course, that is all theory and I need to investigate the impact of changing the priority.