Question

众所周知，缩小CSS和JavaScript会使页面加载速度更快。

在开发阶段，如果您需要“格式化”版本，在Eclipse IDE中使用 CTRL + Shift + F ）。它产生如下输出：

*.cssClass {
    background-color: #FFFFFF;
    color: #C4C0B9;
    border-width: 1px;
    border-style: solid;
    border-radius: 0px;
    padding: 1px;
}

在部署阶段，像yuicompressor这样的外部工具会生成缩小版本，例如：

*.cssClass{background-color:#FFFFFF;color:#C4C0B9;border-width:1px;border-style:solid;border-radius:0px;padding:1px;}

问题是开发周期会像这样运行：

开发（初始代码）
格式化
测试
缩减大小
再次测试
部署

如果需要更新：

开发
格式化最后缩小代码
测试
缩减大小
再次测试

是否有任何技巧可以在格式化/缩小的代码之间自动往返？

开发时：显示格式化代码
部署时：保存缩小的代码

Answer 1

你不应该在开发中缩小。缩小应该是部署的一部分，而不是开发。

因此，我建议在开发和实时部署之间迈出一步。一个“集成”测试阶段，如果你愿意，代码被缩小并以其他方式进行实时处理，并在那里进行测试以确保它在实际部署到实时服务器之前仍然有效。

每次在开发过程中编辑代码时，我都不建议测试缩小版的CSS和JavaScript。缩小应该是一个相对可靠的过程，能够采用任何有效的CSS / JS并使其变小而不改变其行为。

如果您的minifier不提供该服务，您应该切换到另一个minifier，或者改进您正在使用的minifier（通过编写打破它的测试用例，甚至可能帮助解决它）。 / p>

而且，正如评论中所提到的，理想情况下，某种构建脚本会部署到您的集成和实时环境中，因此您不会手动缩小。

更高级的缩小器

如果你有一个提供非常好的压缩的minifer，但是以某些代码构造窒息为代价，那么记录minifier不允许的代码结构，并唠叨你的团队以避免它们。

但你不应该真正为minifier编写代码 - 它本来是一个可以帮助你的工具。检查字节节省与更宽松的缩小器（在 gzipping之后）进行比较，并确定它们是否真的值得增加心理开销 - 为您以及现在正在处理该项目的任何其他人在将来。

线路上较少的字节数不是与项目相关的唯一测量值。

Answer 2

各种服务器可以根据请求处理缩减代码。他们将缓存结果以保持与初始代码几乎相同的性能（第一个请求可能需要几秒钟）。例如

nodejs的连接模块node-minify（内部使用YUI，可以轻松缓存）
回显压缩样式表的PHP脚本（使用服务器缓存）

我建议使用一个暂存环境，在该环境中，代码在收到时会缩小。例如，在服务器上使用post-receive hook in git或shell脚本来更新代码。在那里进行测试后，主服务器可以在shell脚本中将生产文件作为简单的scp（安全副本）接收。

缩小可能会导致问题，除非删除简单的空格（例如#fffff应压缩到#fff），因此最好在部署之前对其进行测试。这并不意味着您需要在工作站上担心它。

在格式化/缩小的CSS，JS代码之间有自动往返的技巧吗？

2 个答案:

更高级的缩小器