我一直在试图弄清楚为什么我正在处理的用户脚本在 Firefox 中速度很慢，但在 Chrome 和 Safari 中却非常火爆。我已经确定的一个原因（尽管可能不是唯一的原因）是用户脚本的大文件大小会产生很大的影响。该脚本中有十个书本长度的字符串，文件大小为 3.8 MB。如果我删除字符串，脚本会再次变快——基本上浏览器中的所有内容都会在文件加载时停止（就在典型的用户输入交互时）。
所以我认为它可能有助于预压缩字符串，然后在运行期间根据需要解压缩。任何人都有在用户脚本中执行此操作的策略吗？
问问题
341 次
1 回答
3
以下是一些未经测试的想法：
从 Greasemonkey 切换到 Scriptish。Scriptish 通常表现更好。
a) 将文本拆分为单独的文本文件。
b) 将这些文件放在您安装脚本的位置。无需压缩。
c) 用@resource指令指向每个文件；每个文件一个。
d) 在您的代码中，当您需要时，使用GM_getResourceText()Doc来获取您想要的文本。将文本拆分为文件，将它们托管在您自己的启用 gzip 的服务器（可能是您的本地计算机）上，并用于
GM_xmlhttpRequest按需获取文件。
服务器可以自动压缩文件，或者您可以预压缩它们以节省几毫秒。
至于在您的用户脚本中存储压缩字符串；很难看出这将如何提高性能。
压缩文本可能会减少 70% 的字节数，但用户脚本中不能包含二进制文件。您必须对其进行 base64 编码，并且您的脚本突然不再短了。
然后，您必须对它进行 base64 解码，并在每次使用时使用 js 解压缩数据。这两个操作都会消耗 JS 的时间和内存。
维护脚本和/或更改文本将相当乏味。
似乎为可能的负收益做了大量工作。
于 2013-09-30T22:57:15.777 回答