我有一个使用快速构建的nodejs站点，我们正在尝试优化。我们有一个带{{{body}}}标记的layout.html文件和其他几个html文件，它们在运行时通过快速渲染引擎合并到layout.html中。Node.js - 将HTML文件作为构建后步骤还是在运行时更好？
我们希望再缩小HTML文件作为构建后操作，但失败是因为我们在的layout.html无效的标记（标记是后有效{{{体}}}已被取代） 。
开发人员A：想解决这个标记，所以我们可以再压缩生成后，部分原因是因为它使得在未来的布局文件的工作更容易，部分是因为他们相信我们会得到更多的如果我们避免网络服务器CPU在运行时进行缩小的惩罚，性能上的好处。
开发者B：我们应该在运行时缩小版本而不是修正标记，并且我们不会因此而遭受惩罚。他们还认为，构建后构建会在运行时带来快速渲染引擎的问题。
我不知道技术水平足以知道谁是对的，并欢迎来自该领域专家的答案。
用令牌来完成缩小，并不难。
我的意见是两个开发商都错了，是不是一个好主意来缩小HTML。
我打算参考this的帖子，@Adrian Salazar的回答。
缩小HTML的唯一好处是可以去除空白，所以不推荐使用，如果您使用的是模板，可能会发现问题（正如我所看到的那样）。
我的建议是忘记缩小HTML，只关注CSS和JS缩小。如Adrian所说，如果您担心HTML的长度，您可以启用gzip压缩您的Web服务器中的静态文件。
所以，开发人员A是有原因的，他说，缩小在生成后，最好在未来与文件的工作，但他对表演的第二个原因可以用gzip压缩所要解决Web服务器。
开发人员B在我看来是错误的，express会提供一个静态文件，所以不会有任何问题，并且最好的做法是在构建中缩小文件（您必须提供所有代码对您的部署区域很好）。
总结：所以，我与开发人员A可言，我不同意的性能问题（我说），但他的意见是“的方式开发”，努力工作在开发者时间尽可能最好。
虽然我很欣赏有关HTML缩小的优点的争论，但这个问题并不是这样。我想要一个具有nodejs经验的人来表达并解释哪种方式更好，为什么。我知道你在帮助，但你还没有回答原来的问题。 – gilles27
实际上，你甚至没有真正看到缩小的废话，它只是为客户端浏览器... – azurinko
Minify的HTML是真的不必要的，例如，如果在你的代码中你正在管理HTML标签，并且使用'id'作为选择器，你想缩小这个ID吗？没有意义，只有性能问题，gzip就足够了 – Kalamarico
谢谢，但我希望对两种方法的批评而不是第三种方法。 – gilles27