Practical Web Design: Speed Up Your Site

[awasson]

This forum thread discusses the SitePoint article 'Practical Web Design: Speed Up Your Site' by Mike Tuck.

"Does your site take more than 8 seconds to load over a 56k modem? Mike asks Andy King, author of 'Speed Up Your Site: Web Site Optimization', how to shave KB, and seconds, off his pages."

[TheOriginalH]

Haven't read the full article yet, but would dispute the claim that either webreference or javascript.com are worth visiting at all.


The "complimentary" site is not working (weboptimization.com)

Gripes aside, enjoying the article

[anode]

I think this interview with Andy King gives you a much better flavor of what the book is about than the review.

Originally Posted by TheOriginalH

Haven't read the full article yet, but would dispute the claim that either webreference or javascript.com are worth visiting at all.

Webreference is worth keeping in your RSS reader to see if any interesting sample chapters pop up, but agreed on javascript.com.

[jgsketch]

As a designer noob, I liked the article. Found out some things that I didn't know about. Simple things like deleting white space in code, making the file size smaller. Guess I need to do more research on this subject.

[Sarah]

Hmm, I certainly learnt a few tricks that I didn't already know (DOCTYPE Strict is faster than transitional), but on further reading I don't like the fact that they are prompting non standard code!!

Although I don't like removing returns and whitespace from me code I do know the benefits with it - just never quite get round to doing it

Interesting column - not sure I would buy the book.

I would have thought that to include details on how to find out your page size and server load and time to upload etc etc and image file size that are too large would have been much more helpful to people, that way they would know the 100KB is too large and 20KB for a page is fine. Otherwise they are saying 50% reduction is great - but yeah 50% reduction of what 50% reduction on 100kb is good but are you so concerned about 50% reduction on 20kb... nope not really.

Still a worthy read but not really for me

Sarah

[kansas411]

I wouldn't buy the book.

I understand the ideas and purposes behind what he is saying but I want to know why you would do them? Everything suggested seems to go against everything that is usually taught and said.

I can see using the techniques in a 60K+ weblog but a normal web page shouldn't be that big.

[Sarah]

Originally Posted by kansas411

I can see using the techniques in a 60K+ weblog but a normal web page shouldn't be that big.

But to a newbie how would you know this was too big? I can seen images of 100kb each before so people do do it ...

[Dr Livingston]

Webreference ? Ummm.... I used to be a regular visitor to this site but eventually - about Sep 2002 - got bored with it since there wasn't any new content that met my needs.

Also it went down hill big time when it's Javascript moved over for .NET - instant killer 8)

IMHO also www.wdvl.com has went much the same way over the last 9 or so months - another great content site hits the **** heap folks 8(

[kansas411]

Originally Posted by Sarah

But to a newbie how would you know this was too big? I can seen images of 100kb each before so people do do it ...

I guess it's just another one of things you learn over time. I remember the first site I made. It was a blog of sorts before they became popular to have. The index page was over 100K not including images. Nested tables in nested tables in nested tables. Unoptimized images. Just plain horrible looking back on it.

My code was sloppy and did most of the things recommended in the book probably. However, as big as it was, it didn't matter because there was so much of it. Now I know better and how to keep my pages small and efficient.

[dalangalma]

Dosen't server compression make a lot of these suggestions, like removing whitespace, a moot point? I mean, most servers gzip output to send to the client nowadays, right? The actual size of the HTML file on the server hardly matters, just the size after compression.

[Luke Redpath]

Mmm, I wasn't impressed with the article.

Some good points were made, in particular about the inclusion of DOCTYPEs and the brief mention of CSS-driven websites (which should surely be the way to go, especially if file size is important).

I think the ultimate way of cutting down on your filesize is the eventual elimination of table-based layouts. Furthermore, I do not like the encouragement of "botch-job" non-standards-compliant methods for cutting down on filesize.

I feel it should be emphasised that eliminating closing tags, double quotes etc. are BAD practice, that cutting out new lines and whitespace - whilst certainly up to the developer - can cause hassle when updating these pages in the future, and that finally with a bit of decent planning and efficient coding practices (standards-compliant) of course, that none of these half-arsed methods should need employing at all.

[astericks]

The article was nice. Taught me a few things, esp about doctypes.

I tried the "remove blank space" from your code thingy, and indeed, my filesize dropped from 27624 to 16415. But after that, it was kinda harder to locate chunks of code I wanted to edit.

And as some of you, I didnt like the fact that the article promoted 'bad coding'.

[anode]

The author of the book has mentioned in a few other places that he recommends having two versions of your code - one "editable" version, and another tweaked for preformance.

[astericks]

Originally Posted by anode

The author of the book has mentioned in a few other places that he recommends having two versions of your code - one "editable" version, and another tweaked for preformance.

that's the first thing I did after realising how hard editing can be after 'code-cleanup'.

[redux]

Originally Posted by dalangalma

Dosen't server compression make a lot of these suggestions, like removing whitespace, a moot point? I mean, most servers gzip output to send to the client nowadays, right? The actual size of the HTML file on the server hardly matters, just the size after compression.

i'd wholeheartedly second this thought. i would also posit that, unless we're talking 6-7 lines of whitespace for every line of html, the actual net benefit of removing unnecessary tabs, returns and spaces is negligible on most "normal" pages...but that's just me.

[platinum]

Originally Posted by redux

i'd wholeheartedly second this thought. i would also posit that, unless we're talking 6-7 lines of whitespace for every line of html, the actual net benefit of removing unnecessary tabs, returns and spaces is negligible on most "normal" pages...but that's just me.

Nope not just you I agree totally with those points....

[mynics]

I remove indent spaces and have all of my code left-aligned, but would never go so far as to remove all those other in-between spaces.

The fact of the matter is, web design isn't a one shot deal. You're always updating your page, and I can't imagine going through that god-awful mess when I need to update something. It has nothing to do with keeping my code clean for aesthetic purposes - it just makes my life easier when I revisit it.

[Mike]

That was a terrible article. Poor code throughout.

[porter]

I should start by saying that I was one of the tech editors for this book; however, I don't have any financial interest in its sales.

That being said, I wouldn't use this article, which is basically just a summary of a single, early chapter, as the basis for deciding whether or not you'd have an interest in this book. Speed Up Your Site attempts to cover optimization techniques at all the different levels of Web site delivery. Yes, optimizing the filesize of your HTML is part of it, but only a very small part.

Some of the approaches discussed are easy, low- or no-cost techniques (i.e., trivial to implement with little or no adverse effect for doing so), while others are a clear trade-off in order to gain some speed (they give up some validity, compatibility, etc. where it will increase speed). I think Andy's done a good job presenting all the options with their associated pros and cons. He's not saying that every site should use every single one of the techniques he covers. If you don't like or need some of them, don't use them. But if you're in a position where you need to eke some more performance out of your site you'd probably appreciate knowing what your options are.

To address some specific comments from other posters:

Re: Maintaining optimized code
As some other folks have already said, I don't think anyone, including Andy, would recommend that you use the "delivery optimized" version of a page as the one that you make updates and changes to. Rather, that level of optimization should be seen as part of the publishing process. That is, keep a human-readable version of all of your pages to work from, and then optimize them before putting them up on your server. There's a broad range of tools that can help automate this process.

Re: Compression
An entire chapter of the book is devoted to various approaches to compression and how best to serve compressed content to capable clients. And no, most servers do not gzip output sent to the client unless you configure them to (assuming your particular server is capable, of course).

Re: Leaving off optional end tags and quotes
The keyword here is "optional." If you're authoring in XHTML there's no such thing as an optional end tag; however, if you're authoring in HTML it is perfectly standards-compliant to leave the end tags off of elements like p, tr, td, option, etc. That's because there are strict rules on what is and isn't allowed to appear inside of those elements. For example, if the browser is parsing along inside of a td element and hits another opening td tag, it knows to end the first table cell and begin a new one since a td element may not directly contain another td element.

The same thought applies to quoting attribute values. XHTML explicitly forbids it, while HTML allows for unquoted values as long as they only contain certain characters (outlined in the book and the article).

In both cases, Andy is very realistic about the negative impacts that either practice might have -- heck, the section talking about removing quotes on attribute values is entitled "Step 6: Omit Optional Quotes, If You Dare" (emphasis mine) -- and again, presents the range of possibilities while cautioning the reader about the potential downsides.

[lkantrov]

Yahoo isn't "the best-known and most-used search engine/directory on the Web" -- Google is. Check your facts - see Search Engine Watch's stats. Geez.

The statement that "the more we optimize our sites for quick loading and ease of use, the more we'll attract and keep visitors" is literally wrong. I know what you're trying to say, but what you've said is wrong, and may be misunderstood by some folks.

See my comments on Webword for more details and how I would restate things. Optimization is good, but not the holy grail.
http://webword.com/weblog/001817.html

[toejumper]

Author here. A scattershot response to the posts so far:

The link is fixed, thanks for being patient.

Anode, it's an excellent interview with King. I'll let the audience decide whether or not the article stands on its own merits, but anyone who quotes "Miss Shapiro" in their signature is good in my book And I should have mentioned that King recommends having two versions of the code: editable and tweaked for performance. Thanks for making that point.

The interview complements the article well, and covers some aspects that the article doesn't go into.

Sarah, the information about reducing graphics size, etc. is in the book, but I didn't attempt to include everything in the one article. You make a good point.

Kansas, I agree, many of the points made in the article and in the book go against the grain and against what is usually taught. I haven't incorporated some of King's suggestion in my own sites. For a smaller page, the savings in upload time may not be worth the "untidy" code. I presented the information; it's up to each of us to decide whether or not we want to implement it.

Dalangalma, excellent point. King discusses it in both the book and the Webword interview.

Luke, I agree that "tableless" Web construction is the way to go. (You're going to hate my next article, which is about basic table layouts for novice Web designers.) Unfortunately, many people aren't yet comfortable with CSS standards or knowledgeable enough to use them. It is definitely the way of the (near) future, but for now, a tremendous number of Web sites are still table-dependent. (My next article, about table usage, is designed specifically for those people who aren't anywhere near ready for CSS layouts. In an ideal world, novice Web designers would learn CSS layouts from the outset, but that's not realistic yet. As I see it, the beginning Web designer still has to go "through" tables to get to CSS. And I think it's worthwhile for beginning Web designers to get a visceral grasp on table layout. Tables will never completely disappear, though their usage will undergo a drastic dropoff over the next few years.)

Porter, I chose to focus on the earlier chapters (read more generally accessible and generally applicable) for the single article. I believe I made it clear that I was not attempting to cover the entire book, but only certain aspects of the book. A comprehensive review of the book would probably be longer than anything SitePoint would run. Check the article; it clearly works with more than a single chapter.

LKantrov, I should have stated that Yahoo is "one of" the best-known and most well-used search engines/directories on the Web. It has more "mass appeal" than Google, which is favored by not only many "mass" Web users, but more informed and sophisticated Web users as well. Yahoo was used as an example of a nicely optimized page that garners visitors in part because it presents a lot of information in a quickly loading page. In the interview, he calls it "the most highly optimized home page I've ever seen." That's why it was discussed in both book and article, not because it is the single most popular search engine. We know that's not the case, and hasn't been the case for a good while now.

"Optimization is good, but not the Holy Grail." An outstanding quote, and one that ought to be in the article.

Thanks for responding, everyone.

[porter]

Originally Posted by toejumper

Porter, I chose to focus on the earlier chapters (read more generally accessible and generally applicable) for the single article. I believe I made it clear that I was not attempting to cover the entire book, but only certain aspects of the book. A comprehensive review of the book would probably be longer than anything SitePoint would run. Check the article; it clearly works with more than a single chapter.

I didn't mean for that remark to come off as a critique of the article at all. Sorry if it sounded that way. I just wanted to address the folks who seemed to be saying essentially, "I know this stuff already, so I don't need this book."

Yes, you do touch a bit on Chapter 2 and dip a toe briefly into Chapter 4, but the bulk of the article discusses the material in Chapter 3. Again, that is not a negative comment on the article at all. You're absolutely right that a complete summary of all the topics in the book at this level of detail would go well beyond the scope of an article like this, which was basically the point that others seemed to be overlooking and I was trying to underscore.

[I, Brian]

As growth in broadband continues, optimisation for speed is no longer an issue. Surfers are generally used to accessing dynamic pages which need a little while to load, not to mention flash sites.

So far as I can tell, surfers now demand much more graphical sites.

Even before broadband took off, people complained that my optimised pages needed more graphics (think - redundant graphics). Nowadays optimisation really isn't a concern.

[vgarcia]

Originally Posted by Chronicles

As growth in broadband continues, optimisation for speed is no longer an issue. Surfers are generally used to accessing dynamic pages which need a little while to load, not to mention flash sites.

So far as I can tell, surfers now demand much more graphical sites.

I tend to see this from an opposing viewpoint. With the rise in broadband usage, I find that users (and me too) are getting less patient. A study by Macromedia last year showed that the average dial-up user waits anywhere from 10-13 seconds on average for a page to load before getting frustrated and leaving. For broadband users, the wait was reduced to 4-5 seconds. Don't underestimate your impatient visitors!

[redux]

Originally Posted by Chronicles

Nowadays optimisation really isn't a concern.

i think that one aspect that shouldn't be overlooked is that with most hosting packages, you pay for the bandwidth. a completely unoptimised site, with huge graphics etc, that gets a fair ammount of daily traffic may actually end up costing you (the site owner) a considerable bundle. from that point of view i'd recommend at least looking at some of the most basic areas of optimisation (mainly graphics, but also clean code, separation of content/presentation, "cacheability", etc)...

just a late night / early morning thought