Let’s Make The Web Faster
Post from June 24, 2009 (↻ July 4, 2015), reflecting Jens the Web Developer.
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:
For more information go to: code.google.com/speed
About the Author
If you have any questions or concerns about what he writes, ask him to explain, or share your own position by sending a constructive comment or email. (And, if you think something could be of interest to Jens, recommendations for excellent literature are always welcome.)
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?
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.