HTML and Performance: Leave Out Optional Tags and Quotes

Published on January 29, 2019 (↻ September 21, 2024), filed under Development (RSS feed for all categories).

Let’s start right with the (simplified) central argument.

P.1: The smaller the HTML load of a website, the sooner the website will be displayed.
P.2: The sooner a website is displayed, the faster it will be (appear).
P.3: Leaving out optional tags and quotes makes HTML load smaller.
C: Therefore, leaving out optional tags and quotes makes a website faster.

This is an old argument (personally, I’ve argued like this since 2008).

Contesting the Argument

The argument is at times contested through doubting premise P.1:

P.1: The smaller the HTML load of a website, the sooner the website will be displayed if compression (like GZIP or Brotli) doesn’t happen to work more effectively with the larger load.

It can also be contested through attacking the conclusion C (really P.1 as well, but let’s keep things simple):

C: Therefore, leaving out optional tags and quotes makes a website faster unless inserting back the omitted DOM nodes takes more time than is saved through the decreased load.

I’ve usually dismissed the concern around P.1, because in various tests at Google, I had observed about 10–20% markup savings and nothing in compression to outweigh these. I actually haven’t heard anyone raise the one around C, but even though minor, per se it looks like a legitimate concern.

Saving the Argument

There are two, incidentally the same, problems with both attacks:

They’re conditional and don’t hold in all cases: if compression is more effective in reducing the load, and if node re-insertion is slower than the wins made through load savings.
They lack data: Both cases are, to my knowledge, barely researched.

The second problem is on the one making the case, here me, to deal with effectively. We who are researching HTML performance will need to gather and publish more data on the effects of the different ways of writing HTML.

The first problem with the attacks, however, is grave in that there are websites that don’t employ any compression (many sites, in fact: as of January, 2019, 22.6% of all websites), and then sites (theory: most of them) that will not be slower than before through node re-insertion.

Although we’re still left with a lack of more data, the central argument appears to be cogent. (My view, disassemble it.)

Leave Out Optional Tags and Quotes

With this said, the argument suggests one course: At a minimum, in our production markup we should leave out all optional tags and quotes in order to reduce load and thus make respective sites faster.

What HTML tags are optional is well-documented, and always described for each element (see e.g. the html or p element).

For quotes, the HTML spec is clear: As a rule of thumb, unless an attribute value contains a space or an equal sign, the quotes should be safe to be omitted.

Leaving Out Optional Markup in Practice

Some people have an inclination to refuse to omit optional tags and quotes, out of hand. I’m not here to judge, but this is interesting (if not ironic):

Omitting optional tags makes markup more readable. There’s no shorter valid document than <!DOCTYPE html><title>␣</title> (gist), and nothing more readable and understandable once the first contents go in. (I’d love to see a cogent argument how including everything optional made HTML more readable and understandable. We omit and simplify, for good reason, in a great many other languages—although a bit different, JavaScript’s ternary operator looks like a nice example. It’s obscure AF and yet it represents an absolute minimum, just like markup stripped of optional tags and quotes.)
Optional tags are already and quite consistently left out for tables, as the tbody element may demonstrate well: It’s almost always left out even though it’s put back in by the browser just as those optional html and body and many other start and end tags would.

Although personally a fan of web developers being capable of writing (nearly) production-ready code by hand, I don’t want to be too pushy here to all adjust our individual development practices.

Our best bet may be something else: If we choose not to write efficient and fast code by hand, as with leaving out optional code, we absolutely need to generate that code. As barely any tooling so far leaves out optional markup (anything solid other than HTMLMinifier?), what we should rather emphasize and prioritize is to improve our tooling.

Put another way, as experts (and unless there’s strong reason to do differently), I believe we should know what code is optional and leave it out. At the same time, our production systems should do a better job assisting us with that. After all the years of neglecting basic HTML optimization, let’s think about taking the next step and not ship optional HTML markup.

Controlling his fiery pride [Val] sets about his duties with a will.

Figure: What in a craft is duty? (Copyright King Features Syndicate, Inc., distr. Bulls.)

I’m sure to have overlooked data and tools—please share anything major, if you’d be so kind (Steve, Ilja?). When it comes to walking my own talk, as I intentionally make my developer life difficult I run several projects that make use of the practices recommended here: see e.g. entirely static UITest.com, or statically generated HH Kaffee and its source (this very site is, in parts, a documented exception). Just like using declarations just once in CSS, it works.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)