[thelist] site speed

[Bob Meetin]

Paul & et,

Paul Bennett wrote:
> Hi Bob,
>
> Interesting considerations.
> Are you having trouble convincing clients to redesign, or are you trying to sell optimisation as a specific service?
>   
==>>
It gets a little fuzzy here.  I think it has to do with 1) rationalizing 
in my mind whether the size of a particular site is a problem or not in 
an analysis and 2) selecting a path that I can justify to clients. - 
i.e. is a 500kb or 1000kb site appropriate in the right circles? 

100-200kb seems to be a compromise in all worlds, kind of like buying 
all-weather tires.  I don't have a link to current stats, but I still 
hear 8 seconds as a goal.  Is 8 seconds relative to all connection 
speeds or are broadband users commonly less patient and predisposed to 
perhaps 4 seconds?

The table results on websiteoptimization.com suggest that 100k should 
load in about 20 seconds via 56k modem, but 1 second via 1.44Mbps 
broadband.  However, if 4 seconds is reasonable for broadband, then 400k 
is okay, right? 

So ------ Why bother target 100-200k if you've already blown off the 56k 
modem customers? www.espn.go.com is commonly around 450k.  Many high 
visibility consumer sites are in the 200-300k range (compusa, bestbuy)

Last night I attended a presentation by a local designer.  In general a 
good presentation, but one thing bothered me.  She made mention of a 
particular site in which she added a demo video to the home page. Her 
client's clients love it, but her client cannot even access it (56k 
modem).  I don't know whether she includes a browser test and 
alternative or not.

Yes I do see some very small local sites coming it at 900-1000k.
<<==
> Something which may help - Turn off images and show them how a search engine will 'see' the site (crude but effective)
>
> Also, the site I work on is 143Kb with css, html, scripts and images. It is very 'designed', uses tables for layout (I'm working on it ok..) and around 40K of the hp weight is in an awful legacy navigation script that uses browser code forking, document.write and noscript to accomplish its "magic" *cough*.
>
> It is a little heavy and I hope to get it down to ~100Kb with better scripts and semantic markup.
>
> The upshot to all this? It loads in under the magic '10 seconds' over a (barely) 56Kb connection, and once the css is cached the rest of the site is fine and each page loads quickly.
>
> My feeling is that a target of 50Kb as 'optimized' is a great thing to write in a book, but it may not be as relevant for many real-world websites.
> *ducks* 
>
> Paul