答案是也许。
让我们看看关闭团队是怎么说的。
From the FAQ:
编译器是否在我的应用程序的执行速度和下载代码大小之间进行权衡？
是的。任何优化编译器都会做出权衡。 一些尺寸优化确实会引入少量的速度开销。但是，Closure Compiler 的开发人员一直小心翼翼地不引入显着的额外运行时。 某些编译器的优化甚至会缩短运行时间（请参阅下一个问题）。
编译器是否针对速度进行了优化？
在大多数情况下，较小的代码是更快的代码，因为下载时间通常是 Web 应用程序中最重要的速度因素。减少冗余的优化也加快了代码的运行时间。
我断然挑战他们在这里所做的第一个假设。使用的变量名称的大小不会直接影响各种 JavaScript 引擎如何处理代码——事实上，JS 引擎并不关心你是否将变量称为 supercalifragilisticexpialidocious 或 x（但我作为程序员肯定会这样做） .如果您担心交付，下载时间是最重要的部分 - 运行缓慢的脚本可能是由数以百万计的事情引起的，我怀疑该工具根本无法解决这些问题。
要如实理解您的问题是什么，您首先需要问的是“是什么让 JavaScript 变快或变慢？”
然后我们当然会遇到问题，“我们在谈论什么 JavaScript 引擎？”
我们有：
- 卡拉坎（歌剧）
- 脉轮 (IE9+)
- SpiderMonkey (Mozilla/FireFox)
- SquirrelFish（Apple 的 webkit）
- V8（铬）
- Futhark（歌剧）
- JScript（9 之前的所有 IE 版本）
- JavaScriptCore（Konqueror、Safari）
-
I've skipped out on a few。
这里有人真的认为他们的工作方式都一样吗？尤其是 JScript 和 V8？见鬼！
同样，当 google 闭包编译代码时，它是为哪个引擎构建东西的？你觉得幸运吗？
好的，因为我们永远不会涵盖所有这些基础，所以让我们试着在这里更笼统地看一下“旧”与“新”代码。
这是来自one of the best presentations on JS Engines I've ever seen 的此特定部分的快速摘要。
较旧的 JS 引擎
- 代码被直接解释和编译成字节码
- 没有优化：你得到你得到的
- 由于语言类型松散，代码难以快速运行
新的 JS 引擎
- 引入即时 (JIT) 编译器以实现快速执行
- 为真正快速的代码引入类型优化 JIT 编译器（考虑接近 C 代码速度）
这里的主要区别在于新引擎引入了 JIT 编译器。
从本质上讲，JIT 会优化您的代码执行，使其运行得更快，但如果发生它不喜欢的事情，它会转身再次变慢。
你可以通过这样的两个函数来做这样的事情：
var FunctionForIntegersOnly = function(int1, int2){
return int1 + int2;
}
var FunctionForStringsOnly = function(str1, str2){
return str1 + str2;
}
alert(FunctionForIntegersOnly(1, 2) + FunctionForStringsOnly("a", "b"));
通过 google 闭包运行它实际上将整个代码简化为：
alert("3ab");
从书中的每一个指标来看，这都要快得多。这里真正发生的是它简化了我非常简单的示例，因为它做了一些部分执行。但是，这是您需要小心的地方。
Lets say we have a y-combinator in our code，编译器会变成这样：
(function(a) {
return function(b) {
return a(a)(b)
}
})(function(a) {
return function(b) {
if(b > 0) {
return console.log(b), a(a)(b - 1)
}
}
})(5);
不是真的更快，只是缩小了代码。
JIT 通常会看到，在实践中，您的代码只需要向该函数输入两个字符串，并返回一个字符串（或第一个函数的整数），这会将其放入特定于类型的 JIT，这使得它真正快的。现在，如果 google 闭包做了一些奇怪的事情，比如将具有几乎相同签名的两个函数转换为一个函数（对于非平凡的代码），如果编译器做了 JIT 不喜欢的事情，你可能会失去 JIT 速度。
那么，我们学到了什么？
- 您可能有经过 JIT 优化的代码，但编译器会将您的代码重新组织成其他内容
- 旧版浏览器没有 JIT，但仍然可以运行您的代码
- 闭包编译的 JS 通过部分执行简单函数的代码来调用更少的函数。
那你怎么办？
- 编写小而中肯的函数，编译器将能够更好地处理它们
- 如果您对 JIT 有非常深入的了解、手动优化代码并使用了这些知识，那么闭包编译器可能不值得使用。
- 如果您希望代码在旧版浏览器上运行得更快一些，它是一个很好的工具
- 权衡取舍通常是值得的，但请仔细检查，不要一直盲目相信它。
一般来说，您的代码更快。您可能会引入各种 JIT 编译器不喜欢的东西，但如果您的代码使用较小的函数和正确的原型面向对象设计，它们将很少见。如果您考虑编译器正在执行的全部范围（更短的下载和更快的执行），那么像var i = true, m = null, r = false; 这样的奇怪事情可能是编译器做出的值得权衡的代价，即使它们运行速度较慢，总寿命更快。
值得一提的是，Web 应用程序执行中最常见的瓶颈是文档对象模型，如果你的代码很慢，我建议你在这方面付出更多的努力。