划词翻译马上就要支持 Manifest V3 了。目前已经完成了 Manifest V3 的迁移，正在测试当中

虽然但是碰碰运气

@lqzhgood 这倒是可以，也许以后我会加个“省电模式”来覆盖你这种场景

@lqzhgood

可以是可以，相当于把初次加载延迟到被其它功能（如右键翻译、快捷键、截图翻译等）呼出之后才加载，但这样做也有问题：

- 首次呼出会明显感觉到延迟了约半秒钟，毕竟资源插入进网页之后，初始化也是需要时间的
- 逻辑上有点复杂，怎么准确判断资源插入进网页的时间点？毕竟能触发插入时机的场景（右键翻译、快捷键等）太多了

所以这就是个取舍：是为了追求精益求精增加更多复杂的代码，还是保持逻辑简单但增加约 120 毫秒的总资源加载时间。而且前面也解释过了，这个时间仅仅只是增加了个数字，并没有阻碍浏览器加载你的网页。

我选择后者

总结一下，为了确保划词翻译能尽快生效、又为了确保隔离划词翻译跟宿主网页的样式使之相互之间不受影响，最后我选择的方案虽然看上去增加了约 120 毫秒的总资源加载时间，但其实并不影响网页的正常使用。

@yoa1q7y 原来你指的是所有资源的总加载时间，我之前测试的仅仅只是 baidu.com 首页 html 的加载时间。

如果是这样的话，那么划词翻译确实会增加这里的总加载时间，但并不会影响你的使用体验。

你可以在 Chrome 开发者工具网络面板的“过滤”输入框里输入 “ikhdkkncnoglghljlkmcimlnlhkeamad”，然后你就会看到划词翻译加载了 4 个 css 文件，这四个文件是从电脑本地加载的，加载时间在我这里分别是 10, 37, 37, 36 ，一共 120 毫秒，而这部分时间是计算进了所有资源的总加载时间的。

这确实可能会导致标签页左侧多出一段时间的转圈圈动画，但实际上并不影响你正常使用网页。划词翻译是在 DOMContentLoaded 事件之后才加入的这些 CSS ，而此时网页已经可以正常互动了。DOMContentLoaded 事件指的是网站的 HTML 已经解析完毕且基本上 css 、script 脚本也已加载完毕，所以网站已经可以正常操作，但其它一些资源如图片、iframe 可能还没加载完的状态，详细说明可以参考 https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event

事实上，扩展程序是可以做到（并且官方也推荐）不在 Network 里显示这些 CSS 文件的，只需改为在 manifest.json 里声明这些 CSS 文件就可以了（不过我也不确定这样做是不是就不会增加总加载时间了），但是，划词翻译使用了 Shadow DOM 来隔离划词翻译与宿主网页之间的样式，让它们两个互相不被影响，所以才使用了 link herf="..." 的方式加载了这些划词翻译的 CSS 资源。

我以前是在 load 事件之后（即网站自己的所有图像、iframe 都加载完）再加载这些 CSS 文件，这样就不会有转圈圈动画、也不会增加总加载时间了，但是经常有用户反馈，有的网站它嵌入的 iframe 页面（比如 google adsense 的广告）迟迟加载不完，导致 load 事件迟迟没有触发，所以划词翻译也就迟迟没有生效，而此时其实 DOMContentLoaded 事件已经好了，网页实际上已经可以正常操作了，鉴于此，我才将划词翻译的插入时机由 load 事件改为了 DOMContentLoaded 事件，从而就有了今天你发的帖子……

我是划词翻译的作者……

由于 V2EX 的访问速度会受到梯子的影响，所以我关了梯子、在 Chrome 开发者工具里勾选了“停用缓存”，然后在 baidu.com 试了一下。

P.S. 不知道怎么在 v2 发图片，所以我就用文字来记录测试数据了

在禁用划词翻译后，刷新了 11 次百度首页，加载时间分别是（单位毫秒）：

199, 192, 146, 139, 167, 193, 152, 136, 131, 179, 180

然后我启用了划词翻译，再次刷新了 11 次百度首页，加载时间分别是（单位毫秒）：

171, 179, 165, 166, 189, 182, 149, 151, 167, 185, 158

从这组简单的数据对比来看，“启用划词翻译会将所有网站的 load 时间拖慢 300ms 左右”看起来不成立。

当然，这不意味着我不相信你的情况。你的情况确实有可能出现，但也可能是因为受到了其它因素（比如梯子）的影响，不然应该是可以稳定重现的才对。

@guzzhao #9 感谢回复，不过这个方法已经在今天失效了

@XIU2 #2 请问具体是什么 IP 还能继续使用，或者是否有找到可以用的 IP 的办法？

选我选我选我

@DOLLOR #14 感谢，这下我更清楚了……不过我看了下 node-ffi-napi ，它也是好几年没人维护了，且从 issues 来看，不支持 macOS 的 arm64 版本，看起来没法满足我的需求

@statumer #2 感谢，这也是个方法

@ysc3839 #5 Win32 是指 32 位的操作系统没法调用这俩接口？不过对于我的需求而言，不支持 Win32 也没有关系

@MasterMonkey #9 虽然文档上说不用写 C/C++ 就能调，但是看了下教程……完全整不明白，好像还是需要有 C/C++ 的技术背景才知道怎么用？

啊这，我 5 个月前买的，现在健康度只有 93% 了……循环计数 72

用美国虚拟信用卡申请的账号，据说用一段时间就会被 DeepL 封号，有遇到过的吗

面包多 pay

同意 15 楼的说法。我自己开发的软件之前也不写单元测试，后来改之前写过的代码的时候总是出 bug ，所以之后的代码我都会写单元测试。另外，单元测试能帮助我将代码进行拆分，以前我总是把大段大段代码写在一块，后来从单元测试的角度来思考之后，就会下意识的把一个功能分解成很多小的功能

总的来说我觉得虽然花的时间多了，但有了安全感、代码之间的松耦合度更低，更容易复用了，我觉得是值得的

在评论里看到了自己的影子……😭

@njzy 好像是 11.6