最佳 JavaScript 压缩器

IT技术 javascript compression
2021-01-13 04:22:16

什么是最好的 JavaScript 压缩器?我正在寻找一种工具:

  • 易于使用
  • 具有高压缩率
  • 产生可靠的最终结果(不会弄乱代码)
6个回答

我最近发布了UglifyJS,这是一个用 JavaScript 编写的 JavaScript 压缩器(在 NodeJS Node.js平台上运行,但它可以很容易地修改为在任何 JavaScript 引擎上运行,因为它不需要任何Node.js内部结构)。它比YUI CompressorGoogle Closure快得多在我测试过的所有脚本上它的压缩效果都比YUI,而且比 Closure 更安全(知道处理“eval”或“with”)。

除了去除空格之外,UglifyJS 还执行以下操作:

  • 更改局部变量名称(通常为单个字符)
  • 连接连续的 var 声明
  • 避免插入任何不需要的括号、括号和分号
  • 优化 IF(在检测到不需要时删除“else”,将 IF 转换为 &&、|| 或 ?/: 运算符等)。
  • 在可能的情况下转化foo["bar"]foo.bar
  • 在可能的情况下,从对象文字中的键中删除引号
  • 当这导致更小的代码时解析简单的表达式 (1+3*4 ==> 13)

PS:哦,它也可以“美化”。;-)

最近 Uglify 丢弃了 API 调用
2021-03-25 04:22:16
你能和 node 上的 jsmin 进行比较吗?
2021-03-27 04:22:16
我们在企业级应用程序中使用 uglify。它做得很好。
2021-04-02 04:22:16
@mishoo 嘿,我喜欢你的 Uglify JS2。这些天我的网络工作不正常...我想在 Windows 上使用它。一些解决方案?:o)
2021-04-03 04:22:16
@mishoo 我显示了 git 链接,但不知道如何使用它
2021-04-08 04:22:16

几年后重新审视这个问题,UglifyJS似乎是目前最好的选择。

如下所述,它在 NodeJS 平台上运行,但可以轻松修改以在任何 JavaScript 引擎上运行。

---下面的旧答案---

Google 发布了Closure Compiler,它似乎生成了迄今为止所见的最小文件herehere

在此之前,各种选项如下

基本上Packer在初始压缩方面做得更好,但是如果您要在通过网络发送之前对文件进行 gzip(您应该这样做),YUI Compressor会获得最小的最终大小。

顺便说一句,测试是在 jQuery 代码上完成的。

  • 原始 jQuery 库 62,885 字节,gzip 后 19,758 字节
  • jQuery 用 JSMin 缩小 36,391 字节,gzip 后 11,541 字节
  • jQuery 使用 Packer 缩小 21,557 字节,gzip 后 11,119 字节
  • jQuery 使用 YUI 压缩器缩小 31,822 字节,gzip 后 10,818 字节

@ daniel james在评论中提到了compressorrater显示Packer 在最佳压缩中领先,所以我猜是ymmv

另外,如果您不相信我,请尝试压缩机评级员.thruhere.net。
2021-03-18 04:22:16
ClosureCompiler 输出对我不起作用。jscompress.com有效
2021-04-01 04:22:16
不要忘记封隔器的缺点——减压时间。
2021-04-04 04:22:16
Packer 可以选择关闭“base62 编码”——对于 jQuery,它在 gzip 后压缩得比 yui 小。这是因为 jquery 使用 'eval' 和 'with' 来防止“安全”压缩器进行某些压缩,但打包器会忽略它们。通常不安全,但 jQuery 已针对 Packer 进行了测试。
2021-04-06 04:22:16
注意,谷歌闭包有时可能是最糟糕的压缩器(输出甚至比原来的还要大)——它\uxxxx默认将字符串中的非 ascii 字符转换为文字……使用 eg --charset UTF-8(如果你确定你让浏览器知道它)
2021-04-12 04:22:16

YUI Compressor是必经之路。它具有很高的压缩率,经过充分测试并在许多顶级站点中使用,而且,我个人推荐。

我已经将它用于我的项目,没有一个 JavaScript 错误或打嗝。它有很好的文档。

我从未使用过它的 CSS 压缩功能,但它们也存在。CSS 压缩也同样有效。

注意:虽然 Dean Edwards 的 / packer / 实现了比 YUI Compressor 更好的压缩率,但我在使用它时遇到了一些 JavaScript 错误。

2021-03-21 04:22:16
Packer 在文件大小方面看起来不错,但事实证明,打开包装所花费的时间通常超过通过管传输较小文件所花费的时间。我见过的大多数实际浏览器基准测试在浏览器中执行的时间方面都比使用 gzip 提供的原始未压缩文件慢。
2021-04-01 04:22:16
除非您检查 Base62 编码选项(您不应该这样做,因为它是外行的 gzip - 我相信大多数现代服务器都支持 gzip),否则不需要解压缩使用 packer 压缩的脚本。对 base62 编码文件进行 gzip 压缩毫无意义,因为没有剩余可利用的冗余。最新版本的打包器(最终版本)不会引入错误,没有解包开销(只要您不使用 base62 编码),并且仍然实现了最大的压缩。现在还有一个命令行版本的打包程序。刚开始使用NPM安装如下:npm install packer(=D
2021-04-04 04:22:16
这是压缩器的在线版本,以防您不想处理让 java 运行的问题:refresh-sf.com/yui
2021-04-05 04:22:16

我使用了 Dojo 项目中的ShrinkSafe——它很特别,因为它实际上使用了一个 JavaScript 解释器 ( Rhino ) 来处理在代码中查找符号并理解它们的范围等。这有助于确保代码在出现时能够正常工作另一方面,与许多使用正则表达式执行相同操作的压缩工具相反(这并不可靠)。

我实际上在我当前的 Visual Studio 解决方案Web 部署项目有一个 MSBuild 任务,该任务运行一个脚本,该脚本反过来在我们部署之前通过 ShrinkSafe 运行解决方案的所有 JS 文件,并且运行良好。

编辑:顺便说一句,“最佳”是有争议的,因为“最佳”的标准将根据项目的需要而有所不同。就我个人而言,我认为 ShrinkSafe 是一个很好的平衡;对于一些认为最小尺寸 == 最好的人来说,这将是不够的。

编辑:值得注意的是,YUI 压缩器也使用 Rhino。

尝试JSMin,获得 C#、Java、C 和其他端口,也很容易获得。

C# 端口是否已移动/删除?
2021-03-28 04:22:16