我真的不喜欢页面中的代码写在一行中，当我浪费大量时间试图理解其中的内容时，真的在页面中编写压缩代码值得吗？根据编程原则，代码应该对其他将要维护它的程序员来说是可读的。
顺便说一句，HTML cmets 可以减少页面加载时间吗？因为它们对其他人可见。
<!-- comment goes here -->
但是java cmets？其他人看不到它们
<%-- comment goes here --%>
【问题讨论】：
标签： java html compression comments
我认为您在这里混淆了许多概念。
页面压缩可以在不同级别进行。您可以在 Web 或 Web 应用程序服务器上使用 mod_gzip 和 mod_deflate 或类似模块来压缩由 Web/应用程序服务器提供的原始字节。这通常会节省大量带宽，并且通常不会给 Web 开发人员带来问题，因为浏览器会在呈现页面内容之前对其进行解压缩（或在“查看源代码”上下文中显示源代码）。
“一行写一页”不是压缩。技术术语是缩小或混淆。它通常针对 JavaScript 完成，以减小所提供的 JavaScript 文件的大小；这可以大大减少文件大小，并具有难以被人类阅读者解析的额外好处。使用 JavaScript 缩小器的 Web 开发人员通常足够聪明，可以提供源代码的非缩小版本，因此调试不是问题。
我曾经工作过的一个以前的客户网站证明，当在线上采用 GZIP 压缩时，性能提升高达 40%，而在使用缩小的 JavaScript 文件（有数千个这样的文件）进行部署时，性能提升了 5-10%文件）。但同样，使用这些技术时，您的里程可能会有所不同。
最后，HTML cmets (<!-- comment goes here -->) 确实会影响性能，因为与没有 cmets 的页面相比，提供带有 cmets 的页面需要更多时间。对渲染的影响可能可以忽略不计，因为 cmets 经常被词法分析器剥离。对于 HTML 解析器首先解析的内联脚本标记中的 JavaScript cmets，情况并非如此。第二种类型的 cmets (<%-- comment goes here -->) 永远不会由应用服务器提供，因为它是 JSP 样式的注释，并且 JSP 编译器通常会忽略这些 cmets，因此不会在生成的 HTML 内容中生成任何 cmets。
【讨论】：
在生产环境中使用 HTML 时，它并不打算被其他人阅读。通常，原始代码将是可读的，并且 HTML 和 JavaScript 之类的内容通常会被缩小以减少加载时间。
是的，您的浏览器必须下载的任何评论都会增加页面加载时间。
【讨论】：
我真的不喜欢页面中的代码写在一行中，当我浪费大量时间试图理解其中的内容时，真的在页面中编写压缩代码值得吗？
可以
根据编程原则，代码应该对其他将要维护它的程序员来说是可读的。
这就是为什么将缩小作为构建过程的一部分进行的原因。致力于它的开发人员会得到格式合理的代码。
顺便说一句，HTML cmets 可以减少页面加载时间吗？但是java cmets？其他人看不到它们
如果它被交付给客户端，那么它会占用一些带宽。这可能是也可能不是大量的带宽，具体取决于上下文。
【讨论】：
有些人这样做是为了阻止对其代码的检查，尽管通过一些努力，它可以格式化并再次可读。这有点像 Java 中的代码混淆。
【讨论】：