Let’s Make The Web Faster

Published on June 24, 2009 (↻ February 5, 2024), filed under Web Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

This post is partially outdated.

Two weeks after my last outcry regarding slowness on the Web there’s a more proactive response: Google launched code.google.com/speed, subtitled “let’s make the Web faster,” because every millisecond counts.

Dennis Hwang, the head of the Webmaster Team (my team), wasn’t alone in pushing this initiative. I’m happy to add that Google webmasters made several contributions to code.google.com/speed, including the following articles and videos:

There’s even a video in which you can see Kevin “Lord of the Scripts” Khaw and me in action: Optional HTML tags.

For more information go to: code.google.com/speed 😊

About Me

Jens Oliver Meiert, on September 30, 2021.

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 close to W3C and WHATWG, 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 views and experiences.

If you’d like to do me a favor, interpret charitably (I speak three languages, and they do collide), yet be critical and give feedback for me to fix issues, learn, and improve. Thank you!

Comments (Closed)

On June 25, 2009, 0:06 CEST, Neovov said:
This is freakin’ nice!
I hope there is more tips to come 😊
On June 25, 2009, 0:16 CEST, Ivan said:
That’s a little bit extreme markup 😊 But in cases were it’s required to completely minimize the end code, this will come in handy.

Few more gains:

* from HTML 4.01—& is literal e.g. no need to escape it; so are < and > for that matter.
* from HTML5—any element @href; H-hierarchy, more elements.
* from characters: each new line is 2 bytes worth; tab indentation is better than more-than-one-space (interval) indentation by at least one byte; at the end we could as well strip white space and new lines (where applicable).
* from character encoding: depending on the character encoding of the file every non ASCII char in UTF-8 is worth more than 1 byte e.g. umlauts, accents, cyrillics—all worth 2 bytes.

Btw, not using end tags, kinda makes the code looks like mark-up haiku a.k.a HAML, don’t you think so?
On June 25, 2009, 0:33 CEST, Ivan said:
To clarify, I personally prefer to use UTF-8, as it never messes with my encoding, regardless of the editor / operating system I am using. Unlike ANSI, which totally messes things up when it comes to non latin characters, such as cyrillic.

If using UTF-8 encoding for files, be sure to check the “without BOM” option, since it can really, really mess things e.g. require / import in PHP goes “big bada boom”.

If the a certain page is one language only (besides english for the markup), it more or less “safe” to conclude that the page will look good in ANSI as well. However, the page must no longer have the UTF-8 charset, but the appropriate, say windows-1251 for cyrillic. And DO test afterwards 😉 UTF-8 -> ANSI converts sometimes strip (or convert to normal) the special characters.

And finally, if possible use code authoring / refactoring tools, that will do those optimization changes for you.
On June 25, 2009, 9:45 CEST, Neovov said:
I have a (great) question : Is it so relevant to ommit end tags despite we use gzip ? Have you some results (with end tags and no gzip, with end tags and gzip, no end tags and no gzip and end tags with gzip) ?
On June 25, 2009, 11:30 CEST, Ivan said:
If this page was to be converted in HTML 4.01 and then optimized and g-zipped (using g zip for windows), savings would vary from 30 bytes up to 100 bytes, depending how you optimize the page.

Imagine these bytes are the bytes you need removed so you would fit in one packet less 😉

A byte here, a byte there and at the end you get some real nice optimization. The only thing you need is some proper site activity to justify the optimization 😉
On June 25, 2009, 17:40 CEST, Neovov said:
In addition to my previous comment :
I think this could be bad to ommit ending tags.

This works if the document is in HTML and ONLY in HTML. If you want to switch to XHTML (for instance if you want to use some namespaces for SVG or RDFa) you’re completly screwd.

I think this doesn’t worth it, the major topic for speeding a page is to focus on external composants.
On June 28, 2009, 15:23 CEST, Thomas | Santhos Webdesign said:
Cool, not closing tags was something I already did in the early days! I actually started closing them when people told me I had to 😁

Interesting but isn’t speed more a server side thing? Like inefficient database queries?

I can imagine that leaving some tags behind will save a bit, but will that really be remarkable?
On July 1, 2009, 5:31 CEST, Jens Oliver Meiert said:
Nicolas, oh there might 😊

Ivan, I’m not just terribly late replying, but also keeping that reply terribly short: There are more optimization measures indeed, though my next favorite is omitting all technically unnecessary quotation marks around attribute values 😉

Nicolas, part 2—short answer: Yes (usually). Long answer: We have got data for that, but I hope I can rather go for the “long-term solution” and present these data (either on code.google.com/speed or here).

Ivan, part 2—thanks 😊

Nicolas, part 3—haha 😊—, well, how does the future of XHTML really look like? 😉

Thomas, you can optimize for performance in a lot of ways (you remind me of maybe putting together a collection of references)… and yes, omitting optional tags—which, once you are feeling comfortable around it, also helps understandability—does have an impact. A significant impact, as indicated in the video and illustrated in respective article.
On July 2, 2009, 11:03 CEST, Hem said:
I have read many articles for speeding up website, but was little tough to implement on my website, and finally i got yours. This is a real cool stuff and easy to understand. Nice work mate. Thankx…
On July 16, 2009, 19:59 CEST, Alan said:
I’ve never even thought about the effect of my (poor) coding on the speed of the web. I must apologise but i’m probably one of the ones slowing it down being an amateur coder, but thanks for making me aware of it and theres some real good tips and downloads there.
Thanks Jens.