且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

为什么< / html>之后的代码标签已移至< / body>之前有性能增益吗?

更新时间:2022-11-30 11:18:36

不允许 c> html 是HTML文档的根元素。


  1. 但这是HTML,而不是XHTML。而不是彻底失败(就像用XHTML一样),浏览器只需要在文档结尾处显示任何内容(除了注释,我相信空格),并将其移动到文档正文的末尾,并假装一切正常。 / p>

    在HTML5之前,在这种情况下,没有任何错误处理标准,因为在根元素后面没有任何元素是无效的。在HTML5中,几乎所有错误处理在第8.2.5节一>。特别地,它指出在身体后身后插入模式,如果存在不是DOCTYPE,注释或< / html> 结束标记的意外令牌,则解析器应将插入模式切换到在身体处理令牌,这意味着任何遇到的应该插入身体而不是。如插入模式的名称所暗示的,这意味着内容将被添加到正文的末尾。


  2. 我没有客观的答案,为什么Google会推荐它,但我确实相信Google将性能优先于标准合规性,特别是在知道无效标记不会导致严重问题的情况下。他们是这样的冒险者(另请参阅:Google Chrome),但我离题。



    您提到将 noscript 链接元素恰好在< / body> 结束标记之前,您已经看到根据浏览器和HTML5规格,最终会发生什么。但是请记住,在$ code> noscript 元素之外的页面头之外的某个链接元素之间实际上并不是有效的首先。但再次,这可能是符合标准的业绩表现。



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)...

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.