2

众所周知，缩小 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;}

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

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

如果需要任何更新：

  • 发展
  • 格式化最后一个缩小的代码
  • 测试
  • 缩小
  • 再次测试

有没有什么技巧可以在格式化/缩小代码之间自动往返？

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

2 回答 2

2

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

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

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

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

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

更高级的缩小器

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

但是你不应该真的为 minifier 编写代码——它应该是一个可以帮助你的工具。检查与更宽松的压缩器（ gzip 压缩后）相比节省的字节数，并确定它们是否真的值得增加的精神开销 - 对于您以及现在和将来从事该项目的任何其他人。

线路上更少的字节并不是与您的项目相关的唯一测量。

于 2013-08-21T13:10:38.227 回答
2

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

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

我建议有一个暂存环境，在收到代码时会对其进行最小化。例如，在 git 中使用 post-receive 挂钩，或者在服务器上使用 shell 脚本来更新代码。一旦您在那里对其进行了测试，您的主服务器就可以将生产文件作为 shell 脚本中的简单 scp（安全副本）接收。

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

于 2013-08-21T13:18:04.923 回答