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 - wit

Answer 1

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 2

According to W3C, body and html tags are optional and can be omitted

An html element's end tag may be omitted if the html element is not immediately followed by a comment.

A body element's end tag may be omitted if the body element is not immediately followed by a comment.

If W3C Recommendation says it is ok now, then it should be totally valid. So there is no reason not to do it, unless you don't like not closed tags

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

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.

Answer 5

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 6

As for me, My ISP is injecting ads into my websites, they insert the script just before </body></html> , so i remove that to avoid their detection.