Consider a web page with several thousand
<div> elements, each with
an opening and closing tag. The HTML file could be considerably
smaller if the tag name had a single letter rather than three.
It turns out that gzip-style string-table compression means there’s
really no difference in transmission data.
For browser memory, the DOM is so vast that a two-character difference
For disk storage uncompressed on a server, a single image file would
dwarf any savings you could make.
A document with, say, ten thousand div elements, would save four octets
(in start and end tags) for each of them, so 40,000 bytes - but a
document with only a single paragraph of text per div would be tens of
megabytes in size. I have such a document in fact: a 32-volume
encyclopedia of biography, and it’s about 50 MBytes in XML; i use XSLT
to make a static Web site with one file, one Web resource, for each of
the approx. 10,000 entries, however . You shouldn’t normally be
serving up HTML files with 10,000 div elements in them.
This would be optimizing for an inappropriate use case.
I’d like to propose a new element,
<e>, which would be functionally
<div> but far better suited as a generic DOM node due
to its compactness.
Well, dotless i (ı) has fewer pixels, isn’t that even better
Less flippantly, it’d be a far bigger win to use server-side parsing
and parse-event streams , and existing Web pages could then benefit
simply by updating Web servers.
 https://www.w3.org/TR/2014/REC-exi-20140211/ (don’t be fooled by
the “XML” in the name of this compression technique; server-side
parsing works for pretty much anything)