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

我真的不喜欢页面中的代码写在一行中，当我浪费大量时间试图理解其中的内容时，真的值得在页面中编写压缩代码吗？根据编程的原则，代码应该是可读的，其他程序员也会来维护它

顺便说一下，HTML注释可以减少页面加载时间吗？因为它们对其他人是可见的

<!-- comment goes here -->

但是java评论呢？其他人看不见它们

<%-- comment goes here --%>

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

可能是

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

这就是为什么缩小是作为构建过程的一部分进行的。开发人员使用它可以获得合理的格式化代码

顺便说一下，HTML注释可以减少页面加载时间吗？但是java评论呢？其他人看不见它们

<%-- comment goes here --%>

---

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

HTML在生产中使用时，不应该被其他人阅读。通常，原始代码是可读的，HTML和JavaScript之类的东西通常被缩小以减少加载时间

---

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

有些人故意这样做是为了不鼓励检查他们的代码，尽管经过一些努力，代码可以很好地格式化并再次可读。这有点像Java中的代码混淆。

我认为您在这里混淆了许多概念

页面压缩可以在不同级别进行。您可以在web或web应用程序服务器上使用mod_gzip和mod_deflate或类似模块来压缩web/应用程序服务器提供的原始字节。这通常会节省大量带宽，并且通常不会给web开发人员带来问题，因为浏览器会在呈现页面内容或在视图源上下文中显示源之前解压缩页面内容

用一行书写的页面不是压缩页面。技术术语是缩小或模糊化。这通常是针对JavaScript完成的，以减少所服务的JavaScript文件的大小；这可以大幅度减小文件大小，另外还有一个好处，就是很难被人类读者解析。使用JavaScript缩微器的Web开发人员通常足够聪明，可以使用源代码的非缩微版本，因此调试不是问题

我曾经工作过的一个客户站点，在在线上使用GZIP压缩时表现出高达40%的性能提升，而在使用缩小的JavaScript文件部署时，表现出5-10%的性能提升，有数千个这样的文件。但同样，使用这些技术时，您的里程数可能会有所不同

---

最后，HTML注释确实会影响性能，因为为带有注释的页面提供服务比为没有注释的页面提供服务需要更多的时间。对呈现的影响可能可以忽略不计，因为词法分析器通常会删除注释。对于HTML解析器首先解析的内联脚本标记中的JavaScript注释，情况并非如此。第二种类型的注释从不由应用程序服务器提供，因为它是一种JSP样式的注释，JSP编译器通常会忽略这些注释，因此不会在生成的HTML内容中生成任何注释。

是的，这通常是针对JavaScript的，但我已经遇到过许多针对HTML的网站，例如，这不是缩小；即仅剥离CR和LF字符即可节省带宽；想想谷歌可以节省的带宽。同样，使用原始源代码或使用web调试代理将内容格式化为可读格式也很有帮助。有时在我尝试将其解压缩（如可读格式）后，会出现许多错误，有时用JavaScript完成的操作不再有效。这取决于几个因素。将内容重新格式化为原始形式通常是有效的；错误可能已经是内容的一部分，这可能会触发浏览器中的怪癖模式。此外，从本地计算机上的文件运行的Javascript可能与服务文件的行为不同。