对于快速网络来说，HTML 文本是否过多？
有谁知道 HTML 作为传输标记语言的效率吗？在我看来，使用结束标签而不仅仅是结束花括号（或只是 ）会向文件添加大量文本。带宽是一种宝贵的资源，当数十亿（数万亿？）的 HTML 文件不断在世界各地传输时，这些结束标签就会不断增加。
我的问题是，它们加起来是否足以产生重大影响。使用更简短的结束标签，页面加载速度会明显提高吗？
Does anyone know anything about the efficiency of HTML as a transmitted markup language? It seems to me that having closing tags rather than merely a closing curly brace (or just </>) adds a lot of text to a file. Bandwidth is a valuable resource, and when billions (trillions?) of HTML files are continually being transmitted around the world, those closing tags add up.
My question is whether they add up enough to make a serious difference. With a briefer closing tag, would there be a noticeable increase in the speed of page loads?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
不需要。
如果您想要较小的下载大小，请自动将您的网络服务器配置为
gzip压缩所有text/html响应。No.
If you want smaller download sizes, configure your web-server automatically to
gzip-compress alltext/htmlresponses.不。相对于图像（和视频！）HTML 仍然很小。再加上压缩，情况会变得更糟（特别是当重复的字符串（例如标签名称）压缩得很好时。
维护成本的增加将远远抵消带宽节省。
No. Relative to images (and video!) HTML is still tiny. Throw in compression and it becomes more so (especially as repeated strings (such as tag names) compress well.
The increase in maintenance costs would more than offset the bandwidth savings.
HTML 效率不高，而且所有迹象都表明它的效率将会降低。
看看下面的例子：
vs
Ok - 这是一个小例子，但它确实说明了我的观点。
早在 56k 调制解调器的时代，我曾经在客户端编写 Javascript 函数，然后使用 Ajax（在称为 ajax 之前）仅传递值（而不是描述），然后使用客户端在中构建元素DOM，事实证明这大约提高了 20% 的效率，但让我思考是否有人会发明 HTML 速记法。没有人这样做，相反，我们只是升级了我们的连接，你是对的 - 我们扔掉了大量不需要的东西。
但谁在乎呢？
HTML is not efficient, and every indication suggests it will become less efficient.
Take a look at the following example:
vs
Ok - its a small example, but it does illustrate my point.
Back in the days of 56k modems, I used to write Javascript functions client side, and then used Ajax (before it was called ajax) to pass down just the values (not the description) and then use the client side to build up elements in the DOM, this proved about 20% more efficient, but left me thinking if anyone would invent HTML shorthand. No one did, and instead we've just upgraded our connections, and you're right - we're throwing around tons of bits, that don't need to be there.
But who cares?
你的观点是有道理的，但与音频、视频、图像等富媒体相比，“浪费的空间”可以忽略不计。
HTML 作为一种标记语言，很冗长；但如果你去掉一些冗长的内容，它会突然变得更难处理。
Your point is valid, but compared to rich media such as audio, video, and images, the "wasted space" is negligible.
HTML, being a markup language, is verbose; but if you take away some of that verbosity, it will suddenly become much more difficult to work with.
一般来说，就带宽而言，HTML 标记并不是限制因素。两个主要原因：
In general, HTML markup is not the limiting factor as far as bandwidth is concerned. Two main reasons:
虽然从技术上讲，结束标签会增加 HTML 文件大小的一定比例，但从网络上所有数据的总体情况来看，它仍然是无限小的。
如果您真的很担心，您可以随时设置您的网络服务器，以便在提供 html 内容时对其进行压缩。
While technically the closing tags adds a certain percentage to the file size of HTML, it is still infinitesimally small in the grand scheme of all the data flying around the web.
If you are really concerned about it, you can always set up your web-sever to apply compression to html content when it is being served.
谷歌省略了其网页上的结束标签，但压缩后节省的空间很小。大多数人更喜欢遵守标准并能够验证他们的页面。
http://code.google.com/speed/articles/optimizing-html。 html
Google omits the closing tags on its web pages, but after compression the savings is minimal. Most people prefer to conform to standards and be able to validate their pages.
http://code.google.com/speed/articles/optimizing-html.html