Suggestions on my site please

[Frank Petronio]

It's the design and code that is slow, not the server

[David Roossien]

"why the java script? i didn't see anything that couldn't be straight html? simpler easier and more browser compatible. "

Ken is using Javascript to provide dimming and a few other style features to the site. Practically all commercial sites use VB or Javascript, so most people have it enabled these days. You might not even bother telling people that you are using it. Another way to deal with that issue is to sense whether or not a user's browser supports it and pop up a window with a warning if they don't have it enabled.

Or, don't bother with the warning at all. Most people don't even know what it is.... why bother telling them about it....

[Ken Lee]

I am the author of the code.

I currently use Javascript because I have written logic to build almost all the pages on-the-fly. All I need to do is number my images, and place them in the right directories. I arrived at this approach, after coding and maintaining each page separately, which became tedious.

Thanks for the tip about the color images. Point taken.

I have never seen any performance problems, because my internet connections at home and work are quite fast. I have tried a variety of browsers, and found no compatibility issues, since my Javascript is rather... elementary.

Thanks again !

[Marko]

Ken,

Good things first - I like the layout. Nice, easy on the eyes and unobtrusive.

But... why JavaScript? Having looked at your code, it seems to be the biggest single factor in the site being so slow. (Yes, I too have seen the previous version of your site, and this one is MUCH slower.)

Normally, browsers interpret pages in a linear fashion - they load anything within the head section first (meta data, scripts, stylesheets), then they load the body portion, render what they find there and only then apply the scripts and stylesheets.

What happens when you use JavaScript to render the pages in this manner is that the browser first renders everything as described only to be forced to re-load and re-render everything, this time with new content. JavaScript is interpreted language and browsers are not very efficient at interpreting it. They are much better at rendering tags and displaying graphic information.

Another slowdown, although not as significant but still worth mentioning, especially in this sort of layout is the use of tables for layout. For the same reasons as described above, the browser has to wait for the entire table to load before it can render it. Contrast this with a number of div tags that have no other ballast in the form of attributes, rows, columns and cells and which get positioned and styled through the use of CSS after they have already been rendered.

Finally, your thumbnails are gorgeous, but... they are big and there are many of them on each gallery page. They also look to be of good quality, which means low jpg compression, which by extension means higher byte size...

OK, now for the suggestions:

1. JavaScript - why use it at all? It is slow, it is cumbersome, it is inaccessible and when it breaks for whatever reason, so do your galleries. The major, but not the only, reasons it can and often does break are: corporate security policies and browser issues (either a crash or simply wrong settings).

If you want to render pages on the fly, you'd be much better off using server-side language such as PHP.

2. Design - tables are much slower and more cumbersome than proper, standards compliant markup, especially since you are already using XHTML rather than HTML. You could easily save 40-50% of your code by separating style, structure and behaviour through the use of PHP, semantic markup and external CSS stylesheets. That could translate into even greater responsiveness since you'd be reusing portions of the code (stylesheets) throughout the site.

3. Image size and compression - it is all very subjective, but you should strike the right balance between quality, size and speed. If I were you, I would reduce your thumbnails by about 25% or even 50% and apply more aggressive jpeg compression to them coupled with careful unsharp masking to hide the artifacts. It is the main image where quality and size really count and they load individually anyway.

That's all. Not much, really, it just sounds more complicated than it really is.

[Capocheny]

Ken,

Very nice images on the site... I'd have to agree with the Daniel and Steve about separating out the color from the B&W images.

No problems with download speed here either...

Cheers

[dsphotog]

Loaded fast for me.(Comcast cable modem)
Super quality!
I also like the tech notes.
My only criticism, you have shown 5 portraits shot in the same exact spot.
Happy shooting!
David Silva
www.davidsilvaphoto.com

[David Roossien]

I don't think Ken's thumbnails are too large. The average file size is about 35kb...reasonably sized for the image dimensions. The problem on the Landscape page is that there are 69 of them! That's 69 x 35kB = 2.5 MB of information on one page.

[Marko]

I don't think Ken's thumbnails are too large. The average file size is about 35kb...reasonably sized for the image dimensions. The problem on the Landscape page is that there are 69 of them! That's 69 x 35kB = 2.5 MB of information on one page.

35 KB is actually HUGE for a thumbnail! This is exactly what I am talking about. The one I looked at was actually 40 KB, but when I tried to Save it For Web in Photoshop, it clocked in at about 7.5 KB for the Quality of 60 (high) and at about 5 KB at the quality of 40. That's between five and seven times the savings right there.

At the lower of these two settings, which is still pretty good for the Web, it would be 69 x 5 KB = 345 KB.

And then there is a mouseover image for each of the thumbnails, which effectively doubles all the above math.

[David Roossien]

Marko, 35 kB Note the "k"

[Marko]

David, I just noted and fixed as you wrote that...