HTML and Performance: Leave Out Optional Tags and Quotes
Post from January 29, 2019 (↻ October 19, 2022), filed under Web Development (feed).
Let’s start right with the (simplified) central argument.
- The smaller the HTML load of a website, the sooner the website will be displayed.
- The sooner a website is displayed, the faster it will be (appear).
- Leaving out optional tags and quotes makes HTML load smaller.
- Therefore, leaving out optional tags and quotes makes a website faster.
This is an old argument (I’ve argued this way since 2008).
Contesting the Argument
The argument is at times contested through doubting premise 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):
- 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
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
Optional tags are already and quite consistently left out for tables, as the
tbodyelement may demonstrate the nicest: It’s almost always left out even though it’s put back in by the browser just as those optional
bodyand 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.
I’m sure to have overlooked data and tools—please share anything major, if you’d be so kind (Steve, Ilja, perhaps Harry?). 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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: What Happened on Google+, the Philosophy Archives
- Previous: Google Lighthouse and PWA
- More under Web Development, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.