Why does code after </html> tag get moved to before </body>? Is there a performance gain?

Question

Reading other Stack Overflow posts like this SO question lead me to this odd Google recommendation on CSS optimization. "Odd" being their recommendation for deferring CSS loading ended like this:

        <div class="blue">Hello, world!</div>
    </body>
</html>
<noscript><link rel="stylesheet" href="small.css"></noscript>

Aside from seeming excessive, confusing, having invalid HTML, and stating "The application order of CSS rules is maintained... through javascript." even though there is no javascript shown... my question is this:

When testing their example and inspecting the result, all the code that occurs after the </html> is moved to just before </body>. So my question is... WHY?

1. Why was it moved? It seems like all major browsers try to account for code after </html> by moving it to before </body>. I searched for a bit and couldn't find any docs/standards on this.

2. Why would Google even recommend this? As in, is there any actual practical benefit to doing this? Because I would think putting it before the </body> to begin with would suffice. (and regarding BoltClock's good subjective explanation, is there any hard evidence that there is in fact a performance gain?)

This occurred in IE11, Firefox 26, Chrome 32.x, and Windows Safari 5.1.7. Inspected HTML was:

        <div class="blue">Hello, world!</div>
        <noscript><link rel="stylesheet" href="small.css"></noscript>
    </body>
</html>

Adding more code after the </html> had the same result.

This reminds me of other odd error-correcting, like how browsers will render <image> tags as <img> (ref)...

UPDATE: For testing, I setup this URL for NOT deferred CSS and also this URL for deferred CSS (well, what I expect that article meant)...

Answer 1

Now that is odd. You aren't allowed to have any elements after the </html> end tag because html is the root element of an HTML document.

1. But this is HTML, not XHTML. Instead of failing outright (as it would with XHTML), the browser just takes whatever appears at the end of a document (other than comments and I believe whitespace) and moves it to the end of the document body and pretends everything is fine.

   Prior to HTML5, there were no standards for error handling in such cases simply because it's not valid to have any elements after the root element. In HTML5, virtually all error handling is accounted for in section 8.2.5. In particular, it states that in the "after body" or "after after body" insertion modes, if there's an unexpected token that isn't a DOCTYPE, comment or </html> end tag, then the parser should switch the insertion mode to "in body" to process the token, which means whatever is encountered there should be inserted into the body instead. As implied by the names of insertion modes, this means the content gets added to the end of the body.

2. I have no objective answer as to why Google would recommend it, but I do believe Google prioritizes performance over standards compliance, especially in cases where invalid markup is known not to cause serious issues. They're risk-takers like that (see also: Google Chrome), but I digress.

   You mention putting the noscript and link elements just before the </body> end tag, which as you've seen is what ends up happening according to browsers and the HTML5 spec anyway. Keep in mind however that it's not actually valid to have a link element in a noscript element anywhere outside of the page head in the first place. But again, this is probably a case of performance over standards compliance.