闪烁内存缓存中存储什么？

Question

除了浏览器缓存外，还有其他几种方法可以浏览器缓存数据。对于Chrome，渲染引擎Blink中还有另一个缓存，用于将图像，样式，脚本和字体（可能更多）存储在内存中。

此缓存用于网站上的连续导航。从“闪烁”缓存中传递的资源在“网络”标签中标有(from memory cache)。浏览器缓存中提供的资源用(from disk cache)标记。

现在我的问题是，哪些资源存储在此非常快的缓存中并从中提供？从我的测试来看，变化很大：

• 对于直接位于HTML中的图像和脚本标记，它非常有效。
• 有时它可以直接用于HTML中的样式（链接）标签。有时，它不起作用（在具有相同会话的同一浏览器中）。
• 对于以编程方式插入HTML的脚本标记，它几乎永远不会起作用。有时虽然可以。

磁盘缓存命中和内存缓存命中之间的巨大差异与Service Worker结合使用时显而易见。在Service Worker中无法观察到内存中缓存所服务的请求（因为该缓存位于Service Worker之前）。磁盘缓存服务的请求通过Service Worker传递（因为Browser Cache位于Service Worker之后）。

为了显示所解释的行为，我构建了一个测试页面，其中包含所有资源类型：https://dm-clone-optimized.app.baqend.com/

您可以使用顶部的链接浏览网站，并在“网络”标签和控制台中观察请求的行为。每个页面加载相同的资源。

经过一些导航（Chrome 70.0.3538.67），大多数时候我都得到了以下行为：

• 从网络获取HTML
• 脚本标签scripts.js和scripts2.js来自内存中的缓存
• 图像标签logo.png也来自内存中
• 样式链接标签styles.css来自磁盘缓存：（
• 以编程方式添加的脚本标签scripts2.js?id=1也来自磁盘缓存：（

有时候，我真的很幸运，并且所有内容都是通过内存缓存提供的：

我很想了解Blink内存缓存的工作原理，以及如何调整我的站点以将其用于具有适当cache control标头的所有资源。

----编辑----

最让我担心的是：为什么动态添加的脚本根本不被缓存？这对scripts.js之类的框架有明显的影响，因为它们将所有依赖项作为动态添加的脚本标签插入

Answer 1

闪烁内存缓存有效

闪烁具有四个内存分配器 PartitionAlloc，Oilpan，tcmalloc和system allocator

因此，Chrome Blink团队已从Blink中删除了tcmalloc和system allocators

Blink（PartitionAlloc + Oilpan）是渲染器内存的第二大消耗者，在典型情况下消耗10％到20％的内存，并且在Discardable，CC和V8中保留了部分内存

在Blink内部，主要的内存使用者是：

• 大StringImpls（由JavaScript源代码使用）
• 共享缓冲区（由资源使用）
• 向量和哈希表

建议是：“ 识别对Blink的总内存有影响的缓存，并仅对它们实施purgeMemory()。”

• 减小（DOM对象）的大小不会产生影响
• 在大多数情况下，丢弃缓存不会影响

他们正在努力摆脱“ DiscardableMemory”项目，这将有助于执行诸如强行分离所有布局对象之类的事情，这反过来将释放由布局树保留的内存。

Answer 2

我相信这是chrome优化的结果，它们使您变得冗长。

文件始终进入磁盘缓存。而且它们还进入内存，并很快被刷新。

Chrome足够聪明，可以在运行过程中询问在磁盘上查找之前，它们是否仍在内存中加载了它们的副本。 该步骤具有较高的命中率，因为这些图像/ js正在积极地用于某些事情。

您将无法控制chrome如何管理它们的TTL /内存容量可用于保持Blob发热。 Chrome开发人员团队根据实际的硬件容量和系统负载在动态调整方面做了大量工作。

P.S。如果您要求将您的APP保留在内存中。您无法采用Sun / Adob​​e的邪恶方式：通过内存图标（通过任务栏图标/服务）使他们的应用DLL在内存中变热，并拖慢其他所有人的速度。

P.P.S。如果最终用户可能想要使用该应用程序，请使用electronic并遵循Whatsapp / Slack / etc来构建始终运行的应用程序。