DISQUS

ErrorHelp tools, news and anecdotes: The highest traffic site in the world doesn’t close its HTML tags

  • Oliver · 5 months ago
    HTML5 defines what an html parser should actually do (which hasn't really been done properly before), including how missing end tags are expected to be handled -- eg. should the element remain open or should it close when it hits a closing tag from a different element: eg. does <tag1> <tag2> </tag1> get turned into <tag1><tag2></tag2></tag1> or <tag1><tag2></tag1><tag2>
  • kl · 5 months ago
    I wouldn't take those guidelines seriously. The very same website contains PHP "optimisation" tips that suggest writing seriously insecure code, and most of them don't improve performance or make it *worse*, as pointed out by PHP core developers themselves.

    HTML has optional tags, true, but I don't think Google put that much thought into that. Their SERP code contains syntax errors and a few "wasteful" constructs (they close their table rows). Like every average developer, they seem to just throw whatever markup seems to work.
  • Jeff · 5 months ago
    > Only this “mistake” is really part of Google’s strategy of treating
    > their performance as a competitive advantage. All browsers work
    > well without the tags and the tags take up time, so they’re excited
    > to eliminate any millisecond they can for their visitors.

    Er, the reason they do this sort of optimization is primarily to reduce costs on their end. Remove one character from a page which is queried 100 million times per day and you've, saved close to 100 megabytes shipped out over the wire. Remove the body and html closure and you just freed up close to 1.5 gigs of bandwidth for the day.
  • Eoin · 5 months ago
    There is something your forgetting here. Google serves hundreds of thousands of pages per second, reducing the amount of content they send saves them a lot of money in bandwidth charges.
    Even if they are gaining miliseconds trasfer time in the pages, the client browsers are going to take slightly longer to parse the data recieved.
  • Not buying it · 5 months ago
    It's neat, but they could far better. It doesn't help nearly as much as them removing the majority of the script, reducing their logo size or using jpeg, and so on. But they have reasons they cannot do the more obvious things, and they need to shave every byte off their requests that they can. The rest of us, fortunately, don't need to rely on this kind of thing. It would be more practical for most sites, even in the top 100, to do more rudimentary optimizations before taking the time to test the effects this has across all supported devices.
  • Mazen Harake · 5 months ago
    Interesting coming from a company that makes its LIVING on spamming me with shit I don't want (adverts).
  • Peter Muys · 5 months ago
    This feels like using a unsupported os function. You know you should not use it and in the and it will catch you.
  • PineappleOrange · 5 months ago
    I agree with the other comments. This is only a bandwidth saver, and will not be useful to most other sites. There isn't any noticeable gain in spee.
  • xxx · 5 months ago
    lol he writes html and calls himself a developer ....
  • Chaz · 5 months ago
    I'm more inclined to believe it's a mistake than a strategy, or if it's a strategy it's some misguided attempt to make it difficult for html parsers to scrape results. The amount of time saved by omitting the closing tags would be immeasurably small, you've probably spent more time thinking about it than would have been saved in a billion requests. In fact it probably slows the page down more than anything, because the rendering engine has to create implied tags anyway.
  • Simon Hawkin · 5 months ago
    I agree. It's the bandwidth, not the processor time (milliseconds? Try microseconds.)
  • Rob · 5 months ago
    It's interesting when amateurs get a blog about technical topics and then see amateurs respond to it. It might be good for you hobbyists to read the HTML documentation before making fools of yourself by spouting something you read on a forum once or, just as bad, in a Dummies book.
  • Robin · 5 months ago
    Amateurs like Rob who doesn't have something good to add, just critisism.

    Watch him prove my point by returning and make this long comment about how he has 100 years of experience as a developer or that he used to code with Gates.
  • l · 5 months ago
    Handling errors is one of the biggest causes of slow-down in browsers. This is horrible advice.
  • Name · 5 months ago
    Except they won't feel it. Nobody cares about milliseconds except if you're a huge corporation serving billions of webpages each week. The end user won't give a fuck.

    This sounds like ricer nonsense.
  • Jim · 5 months ago
    If google were serious about saving bandwidth, they would be compressing their html. 14 bytes savings is nothing compared to over 50% (approximately 2K) they would save by just compressing their front page. OK, the CPU loads go up, but the enduser will see a noticable improvement in page load times, and the page can then be made standards compliant, something the google has been poor at since their inception.
  • jeremy · 5 months ago
    Google does compress their pages. As long as your browser accepts it they'll feed you gzipped resources.
  • jeremy · 5 months ago
    SEE:

    GET / HTTP/1.1
    Host: http://www.google.com
    Connection: close
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11
    Accept-Encoding: gzip
    Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7
    Cache-Control: no
    Accept-Language: en;q=0.7,en-us;q=0.3

    HTTP/1.1 200 OK
    Cache-Control: private, max-age=0
    Date: Sun, 28 Jun 2009 06:35:42 GMT
    Expires: -1
    Content-Type: text/html; charset=UTF-8
    Set-Cookie: PREF=ID=67585407028bb3b3:TM=1246170942:LM=1246170942:S=d8uvbTuf_YeJWxwq; expires=Tue, 28-Jun-2011 06:35:42 GMT; path=/; domain=.google.com
    Content-Encoding: gzip
    Server: gws
    Content-Length: 3272
    Connection: close
  • _ck_ · 5 months ago
    I wonder how many milliseconds sending 14 bytes takes vs the error handler for a browser to timeout while parsing and realize there is no closing end tag being sent, closing it by error vs proper formatting.
  • Jonathan Allen · 5 months ago
    None.

    Browsers don't look for the end-HTML tag to know when the request is complete. If they did, you couldn't send any non-html files.
  • fda · 5 months ago
    I find it funny that when viewing the source to this website it ends in </BODY></HTML>...a bit of irony I guess
  • New Orleans Web Design · 5 months ago
    That Rob guy is a douche. Added nothing this thread. I may be doing the same by adding this but I hate when know-it-alls, especially in this field of work, act like everyone else who owns a computer is soooooooo stupid.
  • Optimize · 5 months ago
    I also noticed that a lot of their html attribute tags do not have quotes. Another time-saver.
  • Richard Bradshaw · 5 months ago
    If you gzip your code, then this makes such a tiny difference that it's essentially pointless.

    If you don't gzip it, then you should.
  • Eso · 5 months ago
    Noiw I see, why some Google webs work quirky in my Opera.
  • Entertainment King · 5 months ago
    I just tried this tip and Ashton Kutcher came out saying that I got "Punk'd."
  • Entertainment King · 5 months ago
    System double posted. Delete please...
  • Ben · 5 months ago
    Google doesn't close their tags because they hate XHTML and have been psychopathically against it since it came out. They are big supporters of HTML5 -- which certainly started out as "fuck XHTML, we're going back to html (oh and it's all because of IE)" movement, but has gotten less so due to the involvement of people like the W3C and Elliotte Rusty Harold -- and even hired Mr Fuck-XHTML himself, Ian Hickson. Never, never, never view source on a page that came out of Google; it'll burn your eyes out.
  • Ian Hickson · 5 months ago
    I'm not against XHTML, I'm against XHTML-sent-as-text/html.
  • Ben · 5 months ago
    Yes Ian. And you've managed to alter the course of internet history because Microsoft's incompetence annoyed you.

    But come on... doesn't closing tags chafe you? Just a little?
  • Vincent · 5 months ago
    I would be surprised if handling an unclosed tag takesless time than interpreting well-formed HTML.
  • John Thomas · 5 months ago
    Well, seeing as Google will rule the world some day, Id say its alright!

    Riff
    www.complete-privacy.tk
  • Sriraj · 5 months ago
    What was a traditional web page structure of starting with <html><body> and closing with </body></html> is now becoming an age old fashion, citing speed.
    I'm not surprised at all when you said that the top 10 alexa websites doesn't use this trick.
    And where is Rob? The rock star :D
  • duck1123 · 5 months ago
    I'm sure they've gone over it now that they've added all the extra links to the home page, but I remember reading that Google had managed to make it so that their entire default home page would fit into a single packet.

    Personally, I would prefer that they show just one more ad and give me properly formatted (X)HTML.
  • foo · 5 months ago
    this is basically the reason I don't close unary tags, i.e.
    rather than
  • Antonio Tajuelo · 5 months ago
    Wow, did notice that Google output its code as 1 line html, but not the deal about the tags.
  • Arun Thomas · 5 months ago
    Google is setting bad examples.
  • Corbacho En Finlandia · 5 months ago
    Me parece una falta de consideración no terminar lo que se emp
  • flosk · 5 months ago
    For those of us who feel like the web is like magic, does not closing the tags in any way change the performance for ajax-technologies?