<story><title>Write HTML Right</title><url>http://lofi.limo/blog/write-html-right</url></story><parent_chain><item><author>shakna</author><text>Whilst the spec certainly allows you to ignore closing of a whole range of elements, it&amp;#x27;s not necessarily the wisest of choices to make. The parser does actually get slower when you fail to close your tags in my experience.&lt;p&gt;Unscientific stats from a recent project where I noticed it:&lt;p&gt;+ Document is about 50,000 words in size. About 150 words to a paragraph element, on average.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render.&lt;p&gt;+ The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words.&lt;p&gt;+ Curiously, Quirks Mode also increased the load times by about 250ms on Firefox and 150ms on Chrome. (Tried it just because I was surprised at the massive overhead of removing&amp;#x2F;adding the tag endings.)&lt;p&gt;The most common place this was going to be opened was Chrome on Android, and a whopping half-second slower to first render is going to be noticeable to the end user. For some prettier mark up.&lt;p&gt;Whilst you can debate whether that increased latency actually affects the user, a decreased latency will always make people smile more. So including the end tags is a no-brainer. Feel free to write it without them - but you _might_ consider whether your target is appropriate for you to generate them before you serve up the content.</text></item></parent_chain><comment><author>niconii</author><text>I can&amp;#x27;t verify your numbers. As far as I can tell, loading a ~900,000 word document with no other differences than including or excluding &amp;lt;&amp;#x2F;p&amp;gt; has about the same load time, though there&amp;#x27;s too much variance from load to load for me to really give definitive numbers.&lt;p&gt;Are you sure you converted it properly? I&amp;#x27;d expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it&amp;#x27;s &lt;i&gt;not&lt;/i&gt; valid to do so), but I don&amp;#x27;t see why leaving out &amp;lt;&amp;#x2F;p&amp;gt; should be so slow.&lt;p&gt;Try these two pages:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;niconii.github.io&amp;#x2F;lorem-unclosed.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;niconii.github.io&amp;#x2F;lorem-unclosed.html&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;niconii.github.io&amp;#x2F;lorem-closed.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;niconii.github.io&amp;#x2F;lorem-closed.html&lt;/a&gt;</text></comment>
<story><title>Write HTML Right</title><url>http://lofi.limo/blog/write-html-right</url></story><parent_chain><item><author>shakna</author><text>Whilst the spec certainly allows you to ignore closing of a whole range of elements, it&amp;#x27;s not necessarily the wisest of choices to make. The parser does actually get slower when you fail to close your tags in my experience.&lt;p&gt;Unscientific stats from a recent project where I noticed it:&lt;p&gt;+ Document is about 50,000 words in size. About 150 words to a paragraph element, on average.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render.&lt;p&gt;+ Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render.&lt;p&gt;+ The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words.&lt;p&gt;+ Curiously, Quirks Mode also increased the load times by about 250ms on Firefox and 150ms on Chrome. (Tried it just because I was surprised at the massive overhead of removing&amp;#x2F;adding the tag endings.)&lt;p&gt;The most common place this was going to be opened was Chrome on Android, and a whopping half-second slower to first render is going to be noticeable to the end user. For some prettier mark up.&lt;p&gt;Whilst you can debate whether that increased latency actually affects the user, a decreased latency will always make people smile more. So including the end tags is a no-brainer. Feel free to write it without them - but you _might_ consider whether your target is appropriate for you to generate them before you serve up the content.</text></item></parent_chain><comment><author>myfonj</author><text>Well this sounds like really interesting observation.  May I ask where exactly were the original closing tags located and how the stripped source looked like?  I can imagine there _might_ be some differences among differently formatted code: e.g. I&amp;#x27;d expect&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;Content&amp;lt;p&amp;gt;Content[EOF fig1]
&lt;/code&gt;&lt;/pre&gt;
to be (slightly) slower, than&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;Content&amp;lt;&amp;#x2F;p&amp;gt;&amp;lt;p&amp;gt;Content&amp;lt;&amp;#x2F;p&amp;gt;[EOF fig2]
&lt;/code&gt;&lt;/pre&gt;
(most likely because of some &amp;quot;backtracking&amp;quot; when hitting `&amp;lt;p[&amp;gt;]`), or&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;Content&amp;lt;&amp;#x2F;p&amp;gt;
    &amp;lt;p&amp;gt;Content&amp;lt;&amp;#x2F;p&amp;gt;[EOF fig3]
&lt;/code&gt;&lt;/pre&gt;
(with that that small insignificant `\n` text node between paragraph nodes), what should be possibly faster than &amp;quot;the worst scenarios&amp;quot;:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;Content
    &amp;lt;p&amp;gt;Content[EOF fig4a]
&lt;/code&gt;&lt;/pre&gt;
or even&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;
    Content
    &amp;lt;p&amp;gt;
    Content
    [EOF fig4b]
&lt;/code&gt;&lt;/pre&gt;
with paragraph text nodes `[&amp;quot;Content\n&amp;quot;,&amp;quot;Content]&amp;quot;` &amp;#x2F; `[&amp;quot;\nContent\n&amp;quot;,&amp;quot;\nContent\n]&amp;quot;`, where the &amp;quot;\n&amp;quot; must be also preserved in the DOM but due white-space collapsing rules not present in the render tree (if not overridden by some non-default CSS) but still with backtracking, that&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;Content
    &amp;lt;&amp;#x2F;p&amp;gt;
    &amp;lt;p&amp;gt;Content
    &amp;lt;&amp;#x2F;p&amp;gt;[EOF fig5]
&lt;/code&gt;&lt;/pre&gt;
should eliminate (again, similarly to fig2 vs fig1).&lt;p&gt;(Sorry for wildly biased guesswork, worthless without measurements.)</text></comment>