Ytukyg

Besides the browser cache, there are a few other ways browser cache data. For Chrome, there is another cache in the rendering engine Blink that stores images, styles, scripts and fonts (maybe more) in memory.

This cache is used for consecutive navigations on a site. Resources delivered from the Blink cache are tagged with (from memory cache) in the network tab. Resources served from the browser cache are tagged with (from disk cache).

My question is now, which resources are stored in and delivered from this very fast cache? From my tests, it varies a lot:

• It works extremely well for images and script tag which are directly in the HTML.


• It works sometimes for style (link) tags which are directly in the HTML. Sometimes it does not work (in the same browser with the same session).


• It works almost never for script tags that are inserted into the HTML programmatically. Sometimes it works though.

One huge difference between disk cache hits and memory cache hits becomes visible in combination with Service Workers. Requests that are served by the in-memory cache cannot be observed in the Service Worker (because the cache comes before the Service Worker). Requests that are served by the disk cache pass through the Service Worker (since the Browser Cache lies behind Service Worker).

To show the explained behavior, I built a test page with all resource types: https://dm-clone-optimized.app.baqend.com/

You can navigate through the site with the links at the top and observe how the requests behave in the network tab and console. Every page loads the same resources.

After a bit of navigating (Chrome 70.0.3538.67), I get this behavior most of the time:

• HTML is fetched from network


• Script tags scripts.js and scripts2.js are from in-memory cache


• Image tag logo.png is from in-memory as well


• Style link tag styles.css is from disk cache :(


• Programatically added script tag scripts2.js?id=1 is from disk cache as well :(

Sometimes though, I get really lucky and everything is served from in-memory cache:

I would love to understand how the Blink in-memory cache works and how I can tune my site to use it for all resources with appropriate cache control header.

---- edit ----

What concerns me the most is: Why are dynamically added scripts not cached at all? This has a noticeable impact on frameworks like scripts.js since they insert all dependencies as dynamically added script tags.

Blink in-memory cache works

Blink has four memory allocators
PartitionAlloc, Oilpan, tcmalloc, and system allocator

So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink

Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8

Inside Blink, the primary memory consumers are:

• Large StringImpls (used by JavaScript source code)


• shared buffers (used by Resources)


• Vectors and HashTables

The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."

• Reducing the size of (DOM object) won’t have an impact


• Discarding caches won’t affect in most cases

They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.

I believe it is a result of optimization in chrome, and they make it verbose to you.

The files are always go into disk cache. And they also goes into memory, and flushed very soon.

Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
The step has a high hit rate, as those images/js are actively using for something.

You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.

P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.

P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.