Chrome shows high cache storage use

问题:

I have been analyzing the cache storage use of complex application, when I realized that the stored image or script with certain content-length N actually takes 5N-10N space in the cache storage.

Consider this sample: I am requesting image from OpenStreetMap via service worker and storing it in cache. There is only one image stored in cache. The Chrome version is the latest one (Version 65.0.3325.146 (Official Build) (64-bit)).

This is the view of cache storage after refresh:

This is the view of clear cache tab:

So, the problem is that the image which has the size of 6.4KB actually takes 13.8MB of cache storage. Am I missing something?

The live example can be seen at https://googlechrome.github.io/samples/service-worker/basic/ - less than 10KB of scripts occupy almost 50KB of cache storage.

So, the question is: how comes that when files are cached via service workers the space that they occupy significantly increases? I agree that the actual request weights more that actual response, but not 10 times more.

Links that might be useful:

1. Chrome dev tools showing high cache storage utilisation
2. Service Worker issues
3. https://bugs.chromium.org/p/chromium/issues/detail?id=795134

回答1:

In the case of OSM tiles, the high cache usage comes from opaque requests.

When you cache something from another domain, you are only allowed to cache it and not see the contents in any way. This makes the request opaque. You cannot fiddle with the contents in your code, only cache it, it's a black box. To avoid information leakage browsers implement padding when they cache the resource. For this reason an image of 100kb is reported to take 7mb of your cache, and the actual reported size differs from browser to browser.

This only means you will be able to cache a lot less opaque requests in the SW logic before a quota exceeded exception will be thrown. All of the cached requests – even if very small actually – take lots of (padded) space in the cache to avoid information leakage.

In the second case I think it's a bug.