在 chrome 扩展 chrome.storage 与后台脚本中缓存答案

【问题标题】：Caching in chrome extension chrome.storage vs background script在 chrome 扩展 chrome.storage 与后台脚本中缓存
【发布时间】：2016-10-28 02:11:32
【问题描述】：

我正在修改我的 google chrome 扩展程序并研究一种缓存数据的方法。该扩展显示 2 种类型的内容，它们都可以被视为对象数组（总共小于 5kb），例如来自 RSS 提要的新闻列表和食谱列表。

首先为了节省加载时间，我可以使用chrome.storage.sync 存储一次数据并每隔一段时间检查一次缓存寿命，并在需要时进行更新。

但不同的是，它是一个新标签类型的扩展，所以每次用户打开一个新标签时都会加载它——因此用户界面的数据加载速度更加关键。所以我正在考虑使用额外的后台页面或后台脚本 (https://developer.chrome.com/extensions/background_pages) 将这些数据作为简单的对象存储在内存中。

后台脚本是否可以被视为一种可行的方法，或者新标签脚本和后台之间的访问（或访问速度）或数据传输有任何限制？

我也检查了那个问题，但这并没有帮助How do I cache data in Chrome Extension?

【问题讨论】：

我将评论 NTP 加载速度。根据我的研究，持久背景页面是确保近乎瞬时 NTP 加载的唯一方法，否则在内容出现在空选项卡。据我所知，大多数 NTP 扩展都表现出滞后性并且仍然很受欢迎，所以我想它不会太打扰人们。
当你说“新标签类型扩展”时，你的意思是你的扩展覆盖了新标签页吗？如果是这样，据我所知，内容脚本无法注入到 overrided 新标签页中，那么如何从后台页面传输数据？通过中间件服务器？
@HibaraAi “你的意思是你的扩展覆盖了新标签页” - 是的。 “据我所知，内容脚本无法注入被覆盖的新标签页” - 我不知道。非常感谢，我会深入探讨这个问题
@shershen，我真傻...你可以使用 chrome.runtime.sendMessage 在覆盖的新标签页和背景页面之间交换数据
我知道这个线程已经很老了，但是随着 manifest v3 的发布，你对快速 NTP 加载有什么建议吗@wOxxOm？我发现从 chrome 存储加载大约需要 100 毫秒，这就是我存储初始页面数据的地方。我认为 indexeddb 可能会快一点。还考虑切换到 preact 以加快加载时间...

标签： caching google-chrome-extension local-storage

【解决方案1】：

是的，后台脚本也可以考虑。

你可以

后台页面提前加载存储，
那么每次打开被覆盖的新标签时，你就可以通过chrome.runtime.sendMessage开始消息传递，
然后一旦后台页面收到它，打包所有需要的信息并通过sendResponse发送，
终于可以在新页面中通过response获取缓存信息了。

示例代码：Injecting Javascript into Newly Created Tab in Chrome Extension

【讨论】：

在这种情况下，是否有任何实际证据表明sendMessage-sendResponse dance 比storage API 加载更快？我的意思是，两者都相对“慢”。需要仔细衡量，看看节省的 JSON 解析是否超过涉及另一段非本地代码。
@Xan 根据我的原始测试用例值得做！ “sendMessage-sendResponse dance”在 0.01 毫秒内完成，而不是 chrome.history 查找需要 300-500 毫秒