That sounds a pretty bad. I could not think of any idea why Blink does not use a cached resource in this case.

I am now in vacation.

Adding Blink>Loader. They might know something about it.

hiroshige-san: Could you look into this?

The bootstrap.min.css is not served by MemoryCache but is still served by disk cache.

This is primarily because the bootstrap.min.css has Vary response header.
Currently Blink's MemoryCache do not reuse responses with Vary response header, as a conservative handling of Vary response header.
https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?sq=package:chromium&l=934
This is not custom element-specific issue, and if we want to fix this we should make MemoryCache to support Vary response header.

Also, the Resource for bootstrap.min.css was frequently evicted from MemoryCache and causing new Resource loading (that hits disk cache).
There might be another issue (not yet investigated though).

As I commented in Comment #5, this looks not related to ShadowDOM and the resource is served by Disk Cache, not fetched from the network.

ericbidelman@ and hayato@, can we close this as WontFix, or do we still need MemoryCache to handle responses with Vary response header?

Perhaps this is  devtools bug then showing the extra requests? Regardless, it would be nice to fix this somewhere. It's confusing to developers.

Can I check my understanding about the test code?
Everytime createInstance() is called,
- MyEl's constructor() is called,
- therefore shadowRoot.innerHTML is set,
- therefore a new <link> tag is created,
- therefore a new request _can_ happen (when e.g. max-age expires we must send a new request).

+DevTools team,

I think showing the requests that were served by disk cache in DevTools is expected behavior. Is this right?

It's worth noting that I have "Disable cache" checked in the network panel. When I uncheck that, DevTools shows a request for each click, but served from the disk cache. 

So this may be working as intended? 

That said, I think the Safari behavior is more obvious to me. After the first request, the tools NEVER show another duplicate request in the network panel. If users aren't showing the Size column, they'd never know the request is from disk.

Perhaps, we should make it more obvious that request was served from cache?