Benefits of omitting closing body and html tags?

Question

Are there any benefits to omitting the closing body and html tags?

Why is the google.com homepage missing the closing body and html tags?

• edit - with regards to bandwidth, it's an extremely small amount, really. Say 10 million hits @ roughly 10 bytes saved ~ 100 mb only... Are there reasons other than bandwidth?

• edit 2 - and nope, google (yahoo, microsoft, and others) are not w3-validator compliant... when it comes to bandwidth-saving en mass vs w3-compliance, I guess the latter's good for the sacrificing?

Answer 1

Think of how many times that page is served every day. Even small reductions in size can be significant at that volume of traffic.

(Although I work for Google, please don't treat this as an "official answer from Google" - it's a guess, but an educated one.)

Answer 2

Apart from a gain in bandwidth, there isn't.

Just because they do it you shouldn't.

Answer 3

You're thinking of that as a standalone thing. If they've done several different things that save bandwidth then it all adds up. Each one might not be significant on it's own but if they have 5 or 10 optimisations then it's significant in total.

Also, those ten bytes may well reduce the data size enough to make it take one less TCP/IP packet which will have significantly higher savings that simply reducing the size of one.

Answer 4

Take a look here : http://code.google.com/intl/fr-FR/speed/articles/optimizing-html.html

Answer 5

Adding to Jon Skeet's answer, this page shows there are 3 billion searches on Google per day. Don't know how accurate it is, but I would guess it's in the ball park.

</body></html> is 14 characters and at 3 billion searches per day, it amounts to approximately 39.12 GB of data per day ignoring compressions, or around 26 GB if we take gzipping into account.

However, Google might actually send the closing tags for body and html for older browsers by looking at their user agents. I cannot confirm or deny this, but looking at modern browsers - Safari, Firefox, and Chrome shows that all are missing the closing tags.

So if you think it works for you, then go for it :). There's no harm in implementing this which may or may not be a micro-optimization for you depending on the scale you're operating at.

Answer 6

I think JB is on the right track. Their home page is about 8750 bytes (for me), meaning that if they can get 1458 bytes per tcp segment, it will be six packets. The point is not so much to make it 8750 bytes rather than 8760 but to make it six packets rather than seven.

This would make a cute Google interview question. :-)

Why does the number of packets matter? Because for modern internet connections, it's the latency that matters, not the roundtrips. A full packet is barely any slower than a 1-byte packet. The value is especially important at the start of a connection when the TCP windows are still opening.

Furthermore, the more packets, the more chance one of them will be lost, perhaps causing a very long delay. The chance is not very high but if you're already as tightly-tuned as they are, it's worth it.

So should you do it? I would say generally not, unless you're confident that you really are already sending just a handful of packets for the page in question. (You should measure it from a realistic client location.) Knowing that the page validates is worthwhile.