关于 “划词翻译” Chrome 扩展拖慢网站速度的问题

一会试试，谢谢分享

不知道是不是心理作用，好像真的快了。尤其是测试 cubox 网页。

@hadwin 有数据支撑，打开开发者工具可以看到加载时长

具体是哪个翻译插件？ Google 自家的？

@Spoter https://chrome.google.com/webstore/detail/%E5%88%92%E8%AF%8D%E7%BF%BB%E8%AF%91/ikhdkkncnoglghljlkmcimlnlhkeamad

谢谢了，看了下，没有安装。

@Spoter 我安装了。。。

自己试了下, 确实开关插件之后的加载时间有明显的不同

chrome 不是自带划词翻译了么，为什么还要安装插件啊

@DOMO #9 自带的划词翻译是啥样的？

https://chrome.google.com/webstore/detail/aapbdbdomjkkjkaonfhkkikfgjllcleb
试了下官方的翻译插件搭配快捷键 chrome://extensions/shortcuts 实现了手动的划词翻译 目前感觉还行

EDGE 的右键 '将所选的内容翻译为 简体中文' 够用了。

@Lentin 选中了按右键点击翻译到中文不就行了

划词翻译这个插件我用了挺久的，最近也逐渐觉得越来越"重"，翻译速度越来越慢之类的，看到 OP 发文，刚才直接换了 deepl 官方的和基于 OpenAI 的，再持续观察一下

另外经过我长期使用和对比，deepl 的翻译比谷歌翻译的质量要好很多

@DOMO #13 看了下 chrome 自带的没有针对选中文本翻译的选项，装了扩展才有那个谷歌翻译的功能

@Lentin #15 搜了一下，找到地方打开了 /t/914926

还支持翻译图片里面的文字 chrome://flags/#enable-lens-image-translate

把这个插件一关，确实感觉变快了。这个插件我记得是去年某个 V 友开发的吧，当时尝鲜装了一下，后续从来没用过，没想到被坑了

member/milkleeeeee

划词翻译的作者。

延迟数值是对的，对加载体验的影响夸大了，这就是一个普通扩展正常的性能表现

我是划词翻译的作者……

由于 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 左右”看起来不成立。

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

@Lentin #15 DeepL 插件也可以

测试了下，Chrome 打开开发者工具，打开禁用缓存，打开百度首页多次取平均值

开启划词翻译 720ms 左右
关闭划词翻译 650ms 左右
无痕模式 240ms 左右

看起来启用扩展确实会对页面打开有一定的影响，不单单是划词翻译，扩展装多了也不好。。。

@milkleeeeee 我明白，我测的确实只能代表我本机的环境

https://streamable.com/s1vj8c

我录了一个视频，百度首页的，可以看到，禁用扩展时，平均时间在 400ms 左右，启用扩展后达到 700ms 左右

卧槽，真的假的，用了大概一年多了！

@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 事件，从而就有了今天你发的帖子……

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

@milkleeeeee 好的 确实不影响网页的正常使用

这种超高频工具还是用系统级的方便

哎呀， @错了，LZ 不好意思~
@milkleeeeee

@lqzhgood

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

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

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

我选择后者

@milkleeeeee
我没表达准确， 重说一下~ // 我以为右键翻译的结果是在右上图标 popup 弹出页上显示

如果要在网页进行侵入式的显示（在网页内显示内容），为了用户体验，我是赞同您说的优先载入资源的

我的意思是，如果关闭右键、快捷键等在网页内显示翻译的方式，只手动点击右上角 popup 弹出页进行手动翻译，或者独立窗口翻译，是不是不用载入这些资源

我现在就是这样手动使用的，因为需要翻译的网页可能不到 10%，但是每个页面都需要载入资源却是实实在在的。
比如 127.0.0.1 本地开发的页面一天可能因为热更新的缘故刷新上千次，也实实在在执行了这 4 条 css 上千次
想给笔记本多扣一点电出来~

看了作者的回复，又默默地用回来了




已经用习惯了，确实好用

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

@milkleeeeee 谢谢大佬， 大佬发财。 ;)

@milkleeeeee 我觉得划词翻译确实有些问题。关掉了就不慢了 很明显

@milkleeeeee 那 4 个 CSS 文件加进 manifest.json 吗？我前端开发，每次打开浏览器控制台调试页面，都会加载这 4 个 CSS 文件，有点干扰视线。