最佳JavaScript压缩器

171

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

  • 易于使用
  • 压缩率高
  • 产生可靠的最终结果（不会弄乱代码）
javascript  compression 
— 罗恩·哈列夫
source
14
有人知道2011年的情况吗？
— 丹
4
现在是2012年，我认为UglifyJS和Closure是赢家，我使用UglifyJS，通常会击败其他一切。
— mkoistinen'4
我将htmlcompressor.com/compressor.html用于我的jQuery Mobile多页面应用程序。它使用带有<script>标记的HTML文件并压缩HTML，JavaScript和CSS。奇迹般有效。
— 安德斯2012年
是2017年-最新消息是什么？
— Abhinav Singi
现在是2020年。使用默认的“安全”配置，UglifyJS会略胜一筹，因为它更“安全”。对于高级电源使用，Closure Compiler会将UglifyJS的组件交给自己。带有ADVANCDED_OPTIMIZATIONS的Closure编译器可以执行各种技巧，可帮助您同时优化工作流程和代码。请参见stackoverflow.com/a/50355530/5601591，以了解Closure Compiler令人敬畏的示例（免责声明：我在其他地方找不到合适的博客文章，因此我不得不把您引到我写的文章中）。
— 杰克·吉芬

Answers:

149

我最近发布了UglifyJS，这是一个用JavaScript编写的JavaScript压缩器（可在NodeJS Node.js平台上运行，但可以轻松修改以在任何JavaScript引擎上运行，因为它不需要任何Node.js内部组件）。它比YUI Compressor和Google Closure都快很多，在我测试过的所有脚本上，它的压缩效果都比YUI更好，并且比Closure更安全（知道处理“ eval”或“ with”）。

除了去除空格之外，UglifyJS还执行以下操作：

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

PS：哦，它也可以“美化”。;-)

— 错hoo
source
17
我们在企业级应用程序中使用uglify。做得很好。
— gyorgyabraham 2012年
您能否与Node上的jsmin进行比较？
— Gringo Suave 2012年
最近，Uglify放弃了API调用
— Gadelkareem 2012年
@mishoo嘿，我爱您的Uglify JS2。这些天我的网络无法正常运行...我想在Windows上使用它。有解决办法吗？：o）
— Hydroper
@mishoo我显示了git链接，但不知道如何使用它
— Sachin Sarola，
124

几年后，UglifyJS再次讨论这个问题，似乎是目前最好的选择。

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

-下面的旧答案-

Google发布了Closure Compiler，该文件似乎在这里和这里都可以生成最小的文件

在此之前，各种选项如下

基本上，Packer在初始压缩时做得更好，但是如果要在在线发送之前对文件进行gzip处理（应该这样做），YUI Compressor将获得最小的最终大小。

测试是在jQuery代码btw上完成的。

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

@ daniel james在注释Compressorrater中提到，它显示Packer在最佳压缩率方面领先于图表，因此我猜是ymmv

— 拍
source
Packer可以选择“ base62编码”关闭-对于jQuery，gzip后的压缩比yui小。这是因为jquery使用'eval'和'with'来防止'safe'压缩器执行某些压缩，但packer忽略它们。通常不安全，但是jQuery已针对Packer进行了测试。
— Daniel James
另外，如果您不相信我，请尝试compressorrater.thruhere.net。
— Daniel James
9
不要忘记打包程序的缺点-减压时间。
— Nosredna
1
注意，谷歌关闭有时是最坏的压缩机（输出甚至比原来大） -它在字符串非ASCII字符转换\uxxxx默认文字..使用例如--charset UTF-8（如果你确定你让浏览器知道它在某种程度上）
— mykhal
ClosureCompiler输出对我不起作用。jscompress.com作品
— codenamezero
43

YUI Compressor是必经之路。它具有很高的压缩率，经过了良好的测试，并在许多顶级站点中得到使用，并且，我个人建议这样做。

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

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

注意：尽管Dean Edwards的/ packer /的压缩率比YUI Compressor更好，但是在使用它时遇到了一些JavaScript错误。

— 假面
source
5
Packer在文件大小方面看起来不错，但是事实证明，解压缩所花费的时间通常超过了通过管传输较小文件所花费的时间。在浏览器中执行时间方面，我见过的大多数实际浏览器基准测试都比gzip提供的原始未压缩文件要慢。
— 庞斯上校10年
— Sponsz上校
如果您不想让Java运行，请使用下面的压缩器在线版本：refresh-sf.com/yui
— Bryan Legend
除非您选中Base62编码选项（因为它是外行的gzip，所以您不应该这样做），否则不需要解压缩使用packer压缩的脚本-我敢肯定，大多数现代服务器都支持gzip。用gzip压缩base62编码的文件没有意义，因为没有多余的漏洞可利用。Packer的最新版本（最终版本）没有引入错误，也没有拆包开销（只要您不进行base62编码），并且仍然可以实现最大的压缩率。现在还有一个打包程序的命令行版本。只需使用npm进行安装，如下所示：npm install packer。（= D
— Aadit M Shah 2012年
8

我在Dojo项目中使用了ShrinkSafe-这是个例外，因为它实际上使用JavaScript解释器（Rhino）处理代码中的符号并理解其范围等，这有助于确保代码在出现时能正常工作。另一端，与许多使用regex进行压缩的压缩工具相反（不那么可靠）。

实际上，在我当前的Visual Studio解决方案的Web部署项目中，我实际上有一个MSBuild任务，该任务运行一个脚本，该脚本又会在部署之前通过ShrinkSafe运行该解决方案的所有JS文件，并且效果很好。

编辑：顺便说一下，“最佳”是有争议的，因为“最佳”的标准将根据项目的需求而变化。我个人认为ShrinkSafe是一个很好的平衡点。对于某些认为最小尺寸==最佳的人来说，这将是不够的。

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

— 杰森邦廷
source
4

如果您使用Packer，则只需选择“缩小变量”选项并gzip压缩结果代码即可。仅当服务器无法发送压缩文件时，base62选项才适用。具有“收缩变量”的Packer可以更好地压缩YUI，但是如果您在某处跳过了分号，则可能会引入错误。

base62基本上是一个穷人的gzip，这就是为什么用gzip压缩base62版的代码比gzip压缩收缩版代码的文件更大的原因。

— 杰科兰
source
1

这是一个YUI压缩器脚本（Byuic），该脚本查找所有js并沿路径进行css并压缩/（可选）对它们进行模糊处理。很高兴集成到构建过程中。

— 吉姆
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.