Let’s Make The Web Faster
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:
- CSS: Using every declaration just once (Jens Meiert)
- How gzip compression works (Kevin Khaw, Eric Higgins)
- PHP performance tips (Eric Higgins)
- Reducing the file size of HTML documents (Jens Meiert, Kevin Khaw)
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 😊
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!
This is freakin’ nice!
I hope there is more tips to come 😊
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?
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.
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) ?
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 😉
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.
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 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.
Maybe this is interesting to you, too:
- Next: “handheld” Media Type, RIP?
- Previous: Maintainability Guide
- More under Web Development, or from 2009
- 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.