« Google and my P.I.I. -- Scary thoughts | Main | Final test begins »

November 18, 2005



XHTML can actually be used to dramatically speed up a site, if you use it right, but what I am about to describe may be considered "cheating".

Since XHTML is HTML implemented in XML, you can use AJAX techniques with it. You don't even need to learn that much AJAX: there's a super simplified subset of AJAX techniques called AHAH (Asynchronous HTML and HTTP) that permits you to update only the parts of the page that change by substituting in chunks of XHTML into the page; that's a whole lot less to transfer than an entire page. On top of that, since with AHAH, you're working with XHTML, there's no XML translation to bother with; don't even bother learning XML style sheet transformations--the stuff being added to your pages is just XHTML, which needs no translation to render on a browser. Just use some scripting to change the parts of the page that need to be updated from the server, and provide permalinks on the page as necessary. This alone will save you more bandwidth than almost all the techniques you listed combined, other than public caching and optimizing your PNGs and GIFs.

Basically, transmitting only the differences between the pages rather than whole pages is the best way to make content load fast on a site. Everything else is marginal compared to this.

(I learned about AHAH at: http://microformats.org/wiki/rest/ahah)


I find that using xhtml far outways the benifits of just doing html. There is no reason you cannot right html that is perfectly fine xhtml without the correct declerations. Your main argument was that XHTML makes your pages bigger. Well maybe by a couple of bytes. An extra couple quotations and some proper structure far outway the size increase. I doo see your point about increased size, but browsers will have an easier time rendering good code compared to bad code. XHTML also supports growing technologies and the legacy and rather depricated html will only find itself in less and less use. Also, as the web grows (at its extreme weight) we soon won't have to worry at all about squeezing bits and bytes out of our html files, more likely squeezing those bytes out of our mpg and avi files.


On point #1, you mention to get rid of all spaces, CF/LR's and quotes (if unnecessary). However, I would propose that it would be unwise to go too crazy with this. Well written, readable but slightly larger code is more valuable than illegible but tiny code. A point worth considering.


Eight of your fourteen directives result in maintenance nightmares. A site utilizing all eight of those might load fractionally faster, but no web dev with a life would think twice about offering to maintain it.

On the other hand, proper publication of images and avoidance of tables by themselves will account for most of the speed advantage, most of the time.

I'm grateful that someone pointed out DNS lookups and the hazards of requesting sibling media files from multiple/external networks. Poorly implemented sites will fail to render during network hiccups as a result (which to me is the greater hazard).


what a joker.

I hope you don't tell clients this BS... no wait I hope you do. Some I can fix it for them and get paid.

don't use XHTML... WAKE UP!! it's not 1999 any more you old fart.

You need to catch up to the rest of use because your going to go out of business in the next 3 years.


I'd argue that there's no reason to use GIF anymore. The only possible advantage GIF has over PNG is animation, which has no place on modern pages.

And I'm guessing these image compacting tools don't do anything other than index the colours. Reducing the amount of colours in a PNG to what is actually in the image, or even 255, should reduce the size dramatically. Only when PNG is using the same amount of colours is it comparable to GIF.


In response:

(1) Strip whitespace.
Bull. See #6 - they're compressed to nearly nothing anyway. And they make your markup that much harder to read in the long run, so the moment you need to make changes to it, guess what - you're spending far longer making the changes because you can't read your own markup.

(2) Don't use XHTML.
I call bull here as well. Falls back into the same category as #6 - it also enforces rules on how you write your markup, making it possible not only for the end user's system to parse the page far easier, and making it possible for you to make changes on the fly to the markup, but makes it easier in the future for alternate methods of transporting the data to be used.

(3) Keep cookies small.
Fair enough - better yet, though, keep data such as the example above on the server. Network security dictates that you don't give the client machine access to data that they don't need - keep the data in a session and only send a session ID.

(4) Keep JS small.
Um. See caching here, and while the interpreter might care and take nanoseconds longer to parse the script, nanoseconds of time isn't worth the time spent actually being able to find your way through your script again.

(5) Caching.
Good idea, but it really only helps if you've got a static site. If the CSS and scripts and images aren't being dynamically generated and aren't being cached, then you've done something wrong.

(6) Enable HTTP compression.
No disputes on this count - when dealing with uncompressed data. Otherwise it's just wasted time on both ends of the connection.

(7) Lower-case HTML, CSS, JS
While it works in conjunction with compression, unless you're using wacky caps everywhere, the difference is minimal.

(8) Avoid tables.
Any purist could tell you that. Of course, that's because "table" implies "tabular data", such as a parts catalog, or a long-format directory listing, etc. Tables got shoehorned into presentation because it was the only thing that used to be avaliable for doing any sort of complex layouts - that's what CSS is for.

(9) Set image size.
Yup. No disputes.

(10) Compact images.
Might help. If the images are only used once. Once they've been loaded - see caching, above - they don't need to be fetched again.

(11) Reduce the number of external elements.
Which is fair enough - but you lose all benefit of caching if you embed scripts & CSS into the pages, unless they're specific to that one page and you don't intend it to be viewed repeatedly. That's why inline CSS is a bad idea as well as embedded scripts.

(12) Use a single DNS lookup.
Mm, it can help the initial request. It's also a standard practice that I tend to follow - but there are plenty of reasons to avoid following it, one of them being that you have a server spewing up static content aside from the main server, for example.

(13) Delay script starts.
This doesn't do anything for the page load except makes it wait to finish. If you've got an onload handler, which is doing something essential to the usage of the page, making the stuff that happens onload wait up for a setTimeout() to take place is just making the page that much slower.

(14) Watch for memory leaks.
If you're doing anything with complex scripting, you should already be doing this.

In practice, most of the tips above don't really mean much for most developers because they have various things to do with the markup and other components after they've written the initial page - whether it's maintenance, adding features, fixing bugs, what have you - and readable XHTML, readable CSS, and readable JavaScript go a log way towards maintaining a site.


Yea great tips, maybe the author should use them as his code is filled with un-needed spaces and tabs:)

Joël Kuiper

"You need to catch up to the rest of use because your going to go out of business in the next 3 years."
Chris ... you have no idea what you are talking about do you?

I admit that the few extra bytes of data that are required for an XHTML page are no longer a problem for most people with a DSL connection.
But XHTML does have 0 benefits over HTML. In fact most people don't even use XHTML properly. That is because Internet Explorer is unable to parse it. XHTML is an XML based language and thus it requires the application/xml+xhmtl MIME (try that for fun in IE). So you'll end up sending is as text/html ... having 0 of the 'benefits' of XHTML (the browser just builds a HTML DOM). And more notebly you've spend time on doing something completely and utterly useless. Read up on some HTML vs. XHTML discussions (there are plenty of those around the web) before you just carelessly shout that one is better then the other

Sean McManus

Good ideas here, but it would be even more useful if combined with links to online resources explaining how to implement these changes.


Tip #2: Don't use XHMTL

Oh my god :-)

You want a clean and small page?

Use Webstandards! => XHTML and CSS!

But use it correct! Keep in mind XHTML is a MARKUP language not a formatting language! Separate content (XHTML) from design (CSS)!

Currently I am working on my new blog, in a view weeks I will show you there how you should use XHTML ;-)

Sjors Pals

About point 6, data compression is not always a good idea since it requires more CPU load to cache the page, if CPU is your bottleneck it can even decrease the performance of your website.


If i'm wrong and XHTML is not the future why are Microsoft adding it to IE7... that's right.

so maybe you should read up before you go shoting your mouth off.

HTML is dead and in 3 years we can start to weed out people like you and the author and only try coders will be left.

now go back to your WYSIWYG editor... amature.


and yes I am now aware I made some spelling mistakes some don't try and be clever and point them out.


Someone may correct me here, but anymore, browsers render in different modes for different HTML DTDs - if you use XHTML markup, it will render in "strict" mode, and if you use older versions of HTML, it will render in "quirks" mode. If I'm not mistaken, writing well-formed XHTML code will render quicker in strict mode than HTML will render in quirks mode. Not to mention that tables and font tags can be replaced for the most part with CSS, saving code and speeding up rendering. The flip-side of this is, unless you're very careful about validating your code (with W3C's validator or some other tool), it hardly matters anyway, because XHTML that isn't well-formed will still get rendered in quirks mode.

That said, keeping your images compressed and making sure to include size attributes is terrific advice, keeping cookies small is terrific advice, because those are one-time things that you can set and forget. But anybody who has built and maintained more than a couple of web sites (as opposed to web *pages*) will find the usefulness of most of these tips, especially things like taking out all the spaces and linefeeds, are far outweighed by the hassle of maintaining the code. A few extra milliseconds, or even a few extra seconds, of download or rendering time vs. a few extra hours a week maintaining "optimized" code is not even a consideration. Show this list to your project manager, and he'll chuckle indulgently and tell you to stop browsing and get back to work.

N Any

Some of these tips are so idiotic and against the idea of WWW (see http://www.w3.org/Provider/Style/URI for example.) It's like someone from Microsoft had written them (smart people with no contextual awareness). Just make it work fast now and don't think big. In no means don't think about reliability.


>it requires the application/xml+xhmtl MIME

This is incorrect. From the XHTML 1.0 spec, sending as text/html is allowed:

It's amusing seeing all the ignorant people claim otherwise without ever having looked it up themselves.


Nice tips


Wow, not very bright.

Putting all HTML on one line, yes, nice for maintnance in the future, and how does that affect anything if you have gzip compression on?

Dude... don't write about things you know nothing about.


It seems to me that this very page doesn't follow your advices..


So much in this blog entry is simply wrong that I'd wonder when was the last time you've developed for the web...just for the record, Im a profession web designer/developer and have been developing/creating/administering sites since '94. So with that said...

I'd take issue with a lot of what's been proposed here...first, we live in the age of broadband, so the whole point of the post is somewhat irrelevant. Yes, I remember the age of 300baud, but we're way beyond that. A few K of savings means zero to most folks out there (33.6Kbps download mean that we're talking at most one second using the author's example of 35K in savings). And the cost in terms of readability, etc. can be huge (hearing from a former Microsoftee that HTML should be clean is kind of amusing seeing how well MS products created bloated HTML).

Tip #1
Next, leaving out CR/LF as well as spacing is insane if you ever want to have HTML that is remotely readable.

Tip #2
Don't use XHTML? Um, that's about as inane a proposition as I've heard. AJAX alone is reason enough to do this (if you're really concerned about server performance and would like to eliminate redundant calls to the server).

Tip #4:
Keeping JS small--well, that makes sense...but I'd suggest writing good JS rather than worrying about the ridiculously tiny amount of savings shortening your function names would give you...

Tip #7:
Keep everything in lowercase? Well, granted that could help on the compression, but personally I like all my HTML tags to be in uppercase...again, due to readability issues...

Tip #8:
This is simply incorrect. Browsers (at least today's rendering engines) do not wait to render a properly encoded table until all the table data is downloaded. If you encode your table appropriately, it'll render as rows are downloaded...however, with that said, using CSS instead of tables is likely a better solution in most cases.

Tip #10:
Photoshop doesn't compress? Im sure the folks at Adobe will be amused. As well as PS users everywhere. Have you used it since PS5? Because it does compress--you just have to tell it how much if you use JPEG. GIF is compressed automagically as long as you limit the color palette.

Those are my main issues with what the author suggests. I should note, however, that some of his other points are well taken, and in some cases great advice. But the simple inaccuracies in the items I've noted undermined, for me, the author's credibility to speak with any degree of authority on this matter...


First: thanks Sarah for that summary, you’re spot on!

Re: XHTML vs. HTML, quirks and Standards.

Even with HTML 4.0 and 4.01 it is more than possible to have browsers render it in standards mode — and hereby I’d like to remind you all that even IE6 has a quirks and a not-so-quirks mode.

All you have to do is put a PROPER doctype at the beginning of your file.

And, you know, even if it’s not nice (read: illegal) to serve XHTML 1.1 as text/html (it is legal to serve XHTML 1.0 so, however), you can do something about it still. For example, you serve it as text/html if the HTTP_USER_AGENT is a /^Mozilla\/4.0/ (which, for example, IE6 is), and serve it as application/xhtml+xml (not xml+xhtml) for modern browsers.


Thanks Dean for explaining it to this n00b web-designer.

PS And I think the compression is quite a bit higher than 3:1 when compressing html/xhtml. The sites I have build using Apache as webserver shows it is rather 10:1 (or more).

Jon Henshaw

Very nice article. I have a tool that can help web designers strip out extrenuous code out of their HTML, like inline styles, and obsolete and deprecated HTML. Although it's targeted as a SEO tool, it's also an excellent web standards tool, designed to help you make smaller pages.



Koenkai: #7, yeah, back in the HTML days I would do my elements ALL-CAPS, and the attribute names CamelCaps. It was so good, so easy to read! Then they decided that the XHTML namespace be all lowercase…

Others, question: image sizes. Isn’t that known the very moment the header arrives from the server? I seriously can’t be arsed when I post a picture in my blog to write height and width data in the (X)HTML of my blog entry. Thing is, the browser surely doesn’t have to wait till the whole image file loads — and if you still use images for layout…

PS: Marcelo: the Captcha is extremely unreadable, even for my — presumably human, and not even all that bad — eyes.

The comments to this entry are closed.