Most likely, you've heard of Cache storage API and Service worker which might be used for caching resources and serving them later from the cache. One use case for that is prefetching resources before users need them.
I've been working on a project which implements the described use case. A few weeks ago, Stefan created a task where he described an observation that the speed of delivering assets from Cache storage is low in some cases. So, I decided to verify that.
I created demo to compare Cache storage and Disk cache. The index.html
needs to display N images. There is an option to precache them then embed into the page. The sw.js
looks into the cache, if resources are there, they get served from the cache, otherwise, they get normally downloaded.
Conditions of tests
Tests were only performed in Chrome. If there is enough interest, I might perform them in Firefox too. All images had identical size but different names to make the browser request them again and again. Below you will see the best results of 10 tries.
Chrome Dev tools provides timing for every resource.
Information about all loaded resources can be downloaded as a HAR file. Then any language/tool can be used to analyze the extracted information. In every try I was looking at time of loading all images. So, when you meet min
, max
or mean
, I refer to the time when all images were loaded.
Test #1: 100 big images
For this test the image size was 1.5 Mb. In general, it is unlikely there are sites which load that many heavy images. It was more about curiosity.
Cache storage
Mostly, the browser spent time on downloading images. There is no clear pattern how the browser started to handle requests.
As I mentioned 10 tries were performed, so here is statistics about them:
- min: 514.93 ms (represented in the above chart)
- mean: 755.43 ms
- max: 1031.07 ms
Disk cache
In this case, the download operation didn't take that much time, but images waited to be queued. We can even see how the browser took images for processing (approximately 6 images in one batch).
Statistics about 10 tries:
- min: 646.73 ms (represented in the above chart)
- mean: 1050.81 ms
- max: 1450.36 ms
Cache storage is a clear winner in this test.
Test #2: 30 small images
For this test the image size was 31.3 Kb. This scenario has higher probability to be real than the previous one. I used images for tests, but it might be different assets (javascript files, fonts, images, css files etc), so some sites might load 30 assets on a page.
Cache storage
The download wasn't a problem any more but the waiting was.
Statistics about 10 tries:
- min: 26.22 ms (represented in the above chart)
- mean: 34.1 ms
- max: 40.84 ms
Disk cache
Again, the queueing operation took more time than any other operation.
Statistics about 10 tries:
- min: 15.3 ms (represented in the above chart)
- mean: 22.89 ms
- max: 28.97 ms
Now, Disk cache is a winner.
Test #3: 100 small images
Again, it is almost unreal case, but I was curios why Cache storage was faster in the first test. It might have been a number of images or the image size. So, I took the image from the previous test and loaded it 100 times.
Cache storage
Again, the waiting operation dominated here.
- min: 65.5 ms (represented in the above chart)
- mean: 78.54 ms
- max: 90.51 ms
Disk cache
Again, the chart shows that the browser took the batch of 5-6 images and loaded them in parallel then took another batch.
- min: 55.44 ms (represented in the above chart)
- mean: 101.84 ms
- max: 142.45 ms
By comparing the mean Cache storage is a winner again. So, I assume it is more about an ability to serve requests in parallel.
Wrap up
Even tests were performed on localhost results differ between tries. Disk cache was slightly better in delivering a small number of assets, Cache storage was better in delivering lots of assets. At some point, it is a little bit unfair to compare Cache storage and Disk cache, the first one has more wide use and developers have access to API to control it. Anyway, Cache storage isn't slow as it might have looked when the task was opened.
Top comments (0)