views:

102

answers:

7

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?

+11  A: 

No.

If you want smaller download sizes, configure your web-server automatically to gzip-compress all text/html responses.

Justice
COMPRESSION : )
GnrlBzik
+2  A: 

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.

David Dorward
I completely agree, though I would point out that JSON is replacing XML, which is analogous to what Cap is suggesting.
Suppressingfire
JSON is replacing XML for *some* things, and the reasons for it have little to do with the size. JSON (unlike XML) is very specific about the basic data type of a bit of data (so a generic parser can tell the difference between, for example, an array of data with one item in it and a single items) and it can be easily parsed very quickly in JavaScript. XML still has advantages (namespaces, semantics, etc) and is better for some tasks.
David Dorward
A: 

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.

Mike Clark
+1  A: 

In general, HTML markup is not the limiting factor as far as bandwidth is concerned. Two main reasons:

  1. HTML is text, which means it is highly compressible using HTTP compression.
  2. The bandwidth used by HTML is extremely small compared to the bandwidth used by graphics/video.
William Brendel
A: 

HTML is not efficient, and every indication suggests it will become less efficient.

Take a look at the following example:

<b>some bold text</b>

vs

<span class="boldText">some bold text</span>
.boldText {font-weight:bold;}

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?

JL
+1  A: 

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.

Matt Caldwell
A: 

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

Tim Sylvester
Did you read that article? If you omit something that is **optional** then you **do** conform to standards.
David Dorward
@David I meant conform to XHTML as opposed to HTML, but I wasn't clear.
Tim Sylvester