探讨脚本注入 SC为何不及TM快

[cyfung1031]

  "content_scripts": [],
  "user_scripts": {
    "api_script": "content.js"
  },

1）TM 是全域注入 content.js, 而不是ScriptCat 用 API 注入 （虽然注入后都是一个全域脚本）
2）API 注入的全域比非API注入较慢
3）TM 不使用 inject.js, 而是在 content.js 绕过CSP注入一次性代码

因此在TM，它用最快的 content.js, 直接接入到 content 环境，然后把脚本以 <script> 绕过CSP 注入到网页环境

可是SC，首先 content.js 和 inject.js 都要注入，还要跟其他几百个脚本一起排队。
不是排最头的话，前面的小鸡就要等后面的母鸡和公鸡载入后才能正常运行。

因为TM用的是非API注入，所以用链结打开浏览器时必会执行。
而SC用的是API注入。在浏览器刚打开时，service_worker 还是非活跃状态。要等到Chrome API 事件触发后才唤醒。
唤醒后才去检查一下有没有未注册好的脚本，有的话就注册一下那些动作。

[CodFrm]

不知道你那边是什么情况和配置，我这里是 SC 比 TM 快的：

// ==UserScript==
// @name         New Userscript RVI3-1
// @namespace    https://docs.scriptcat.org/
// @version      0.1.0
// @description  try to take over the world!
// @author       You
// @match        https://docs.scriptcat.org/
// @icon         https://www.google.com/s2/favicons?sz=64&domain=docs.scriptcat.org
// @run-at       document-start
// ==/UserScript==

console.log("run SC");

[CodFrm]

另外说一下TM/SC的注入方式：

TM 有两种情况，一种是 UserScripts API，另外一种是UserScripts API Dynamic

首先是默认的配置：UserScripts API，他是只注入了 content.js ，然后类似SC一样，需要等待 SW 发送脚本信息到 content.js 然后使用 <script> 将脚本注入（需要包含脚本代码）。SC MV2的时候也是使用这种方式，现在的SC也是类似的方式，只是不再由content注入脚本代码，而是由 chrome.userScripts 去注入

UserScripts API Dynamic 是和 SC 的 @early-start 类似的方式，使用 chrome.userScripts API，将脚本需要的信息注入进去，有更新也会进行更新，然后直接运行起来

---

你文中的是 manifest.json 的内容？

  "content_scripts": [],
  "user_scripts": {
    "api_script": "content.js"
  },

我没有找到 user_scripts 这个字段（这就是你说的非API模式？）：https://developer.chrome.com/docs/extensions/reference/manifest/content-scripts?hl=zh-cn 而且我添加上，只得到了一个错误：

---

基于上述描述，我觉得你说的内容有问题

[cyfung1031]

你文中的是 manifest.json 的内容？

  "content_scripts": [],
  "user_scripts": {
    "api_script": "content.js"
  },

我没有找到 user_scripts 这个字段（这就是你说的非API模式？）：

呀我看错了。忘记了TM的FF版及Chrome版是不同manifest.json

[CodFrm]

我尝试在 edge://serviceworker-internals/?devtools 手动停掉 SW，这时候 SC会比TM慢，但是TM的SW我停掉后，马上又会恢复，无法验证

然后我又测试了一下冷启动（重启浏览器），TM甚至比SC的 document-end 还慢，可以看到 run TM 是在 SC 的 Immersive Translate - Translate Web & PDF 之后运行的（这时候我换了 https://example.com/ 这个地址，这个地址比较干净一点）

[Xia0xia0Xia0]

在 example.com 测加载速度完全无意义吧，站点本身毫无脚本加载，你甚至会发现document.addEventListener("readystatechange",...)在反复刷新时，都会出现事件错误，因为页面加载得太快了。

至少也是 content-security-policy.com 这种有网站自身脚本加载的站点来测试。

[CodFrm]

这里只是解释 TM 和 SC 的加载速度，和具体哪个网站没什么关系，反而干净一些的网站会更好一些

[cyfung1031]

这是指 document-start 的情况吗？
页面加载快慢会影响 document-start 的脚本载入？？