问页面代码压缩真的需要吗？

EN

我认为你在这里混淆了很多概念。

页面压缩可以在不同级别上完成。您可以在web或web应用程序服务器上使用mod_gzip和mod_deflate或类似的模块来压缩web/应用程序服务器提供的原始字节。这通常会节省很多带宽，而且通常不会给web开发人员带来问题，因为浏览器会在呈现页面内容之前对其进行解压缩(或者在“查看源代码”上下文中显示源代码)。

“写在一行中的页面”不是压缩。技术术语是最小化或混淆。这通常是针对JavaScript完成的，目的是减小所提供的JavaScript文件的大小；这可以极大地减小文件的大小，另外的好处是很难被人类阅读器解析。使用JavaScript微型器的Web开发人员通常足够聪明，可以获得源代码的非最小化版本，因此调试不是问题。

我曾经工作过的一个客户站点显示，在网络上使用GZIP压缩时，性能提高了40%，使用缩小的JavaScript文件(有数千个这样的文件)部署时，性能提高了5-10%。但是，在使用这些技术时，您的里程可能会有所不同。

最后，超文本标记语言注释(<!-- comment goes here -->)确实会影响性能，因为提供带有注释的页面要比没有注释的页面花费更多的时间。对呈现的影响可能可以忽略不计，因为注释通常会被词法分析器去掉。这不适用于内联脚本标记中的JavaScript注释，这些标记首先由HTML解析器解析。第二种类型的注释(<%-- comment goes here -->)从不由应用服务器提供，因为它是JSP样式的注释，并且JSP编译器通常会忽略这些注释，因此不会在生成的HTML内容中生成任何注释。

在生产环境中使用HTML时，它不会被其他人读取。通常情况下，原始代码将是可读的，并且像HTML和JavaScript这样的东西通常会被缩小以减少加载时间。

是的，你的浏览器必须下载的任何评论都会增加页面加载时间。

我真的不喜欢页面中的代码被写在一行中，当我浪费大量时间试图理解其中的内容时，在页面中编写的压缩代码真的值得吗？

它可以是

根据编程原则，代码应该是可读的，其他程序员也会来维护它。

这就是为什么缩减是作为构建过程的一部分来完成的。从事这项工作的开发人员会得到合理格式化的代码。

顺便说一句，

注释可以减少页面加载时间吗？但是java注释呢？其他人看不到它们

如果它被传送到客户端，那么它会占用一些带宽。这可能是也可能不是大量的带宽，这取决于上下文。