Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: incrediBILL
D O N
1. HTML file itself plus any includes
2. All image files (only count each one once, even if it's used more than once)
3. External CSS files
4. External JS files
If you can keep total page weight in the 40 to 50 kb range, then you're in the sweet spot for dial up users.
As you've guessed, images are often the prime offender. Using a good optimizer such as Adobe's ImageReady makes a big difference. It also helps to crop unneccesary parts of the image. Make the right choice between .png, .jpg and .gif - and even more, consider whether the images would work well if just a bit smaller.
For instance, if an image is 100x100, and you can take it to 80x80, you didn't just save 20% of the file fize, you may have saved 36% or more.
This process is transparent to the user and can make a fair difference to the loading speed of large pages.
I don't think pre-loading images will help you much. They have to be downloaded one way or another :)
Make sure all images have HEIGHT and WIDTH attributes. This tells the browser how much room to leave for each image, so it can place text and begin displaying the page even if all the parts haven't arrived yet. This won't change the real download speed, but it can make pages *feel* faster, because it avoids the "all or nothing" style of page load and gives the user something to start reading while the images come in.
You need product images, but try to avoid using images for any other jobs that could be done by text and/or CSS styling. Do you really need fancy graphic buttons for your link menu? Do you really need spacer GIFs all over the place? Be ruthless about simplifying.
Try to make sure that all page components (images, stylesheets, external .js scripts, etc.) are served from within your own site. If the browser has to fetch things from elsewhere, you can estimate a couple of seconds added to the loading time for each external server that must be contacted. Serving things from your own site improves the speed and also makes you less vulnerable to glitches elsewhere.
My webmail client in particular was chosen because the have a no graphics/adverts/flash/gimmicks site that loads very quickly (even on 56k).
Note: this forum is just barely usable sometimes.
The thing that saves it is the fact that the top lines appear before the rest of the message table loads, so I can get to the forum list and "reset read pointer" link quite quickly.
Another thing is the way tables are rendered by the browser. If a few smaller tables are used instead of one big one for the entire page, it can give an illusion a lot more speed because loading can be progessive instead of waiting for the whole thing. There's something to look at while the rest of the page loads.
Oh, and popups slow down load time.
(note: if you use spacer gifs then A) use a blank alt="" attribute and B) consider using CSS instead).
You can speed up the 'apparent' loading of tables by specifying
in your CSS and giving each <col> a width. This means the browser can start displaying the table when it gets the first row, rather than having to wait for all the rows to load.
Thank you grahamstewart, good point. Slightly off-topic, but closely related and relevant for ease of use and visitor retention: In the case of people who use fixed-width tables and fixed-width pages, as some still do because of the particular type of layout, what's current thought on design for browser resolution?
I know 1024 resolution is growing, but it doesn't work too well on 15 inch monitors, which come stock with a lot of systems. Also, chances are people with 56K dialup may also be using out of the factory default 800x6o00 monitors.
Is 800x600 resolution still the standard for fixed-width pages, and would side scrolling be as significant factor as slow loading time for usability and conversion?
I know that visitors are lost with each second of download waiting time, but can't seem to find the exact figures for either current monitor resolution usage or recommended download times.
Note that specifying a width for the table columns doesn't mean that you are forced into a fixed width layout - you can specify the widths as percentages.
(I love fluid layouts. Fixed layouts just seem lazy to me)
As to whether side-scrolling puts people off - my gut instinct is yes, but I don't have any hard figures.
The web browser will wait for all of the contents of the table to be downloaded before displaying them. If you are able to present the information using DIVs or some other CSS method the information will appear as it is downloaded.
I would rather wait for a 10second page load if more content showed up every .5sec than a 5second page load where the whole page showed up after 5 seconds.
Also, if you have Adobe Photoshop there is a great feature called save for web or something like that on the file menu. This will let you adjust the colors, compression and other settings on the saved file to get the file size as small as possible while still preserving the image quality. You should be able to get most thumbnails under 1-2kb and larger images should be under 5kb, if possible.
I am really interested to know if these views are supported by analysis or empirical data, vs just a bit of conjecture. My understanding is as follows:
Tables will load progressively no matter which way you slice them. Of course, if the cells contain images, then you'll have to wait for the images, but the cells which don't have images will load while the images are loading in the background. If the size of the images aren't specified, then the space allowed for them will be wrong, but the text will still be displayed; its just that once the image has downloaded, the page will shuffle around a bit.
I still recommend what I suggested initially: Look at the logs, then decide what to optimise so you get the biggest impact for your effort. No point shaving off bytes by removing carriage returns in your html, when you can chop off kilobytes by optimising the compression ratio of a jpeg.
I'm not claiming to be an expert... I just thought I'd couch the above in somewhat inflamatory terms in an effort to challenge all out there to educate me if I am wrong ;), and to challenge all out there to abandon conjecture in favour of analysis and fact if I am right. ;)
Tables will load progressively no matter which way you slice them.
Not in my experience. Take this forum for instance. I get the top few lines of the outer table appearing (logo and location bar) then a pause of around ten to fifteen seconds before it displays the 'messages' table.
Note that the messages table gets displayed all at once - not row by row as it loads. (Browser: IE6, Connection: 56k)
I assume that this is because it is using the 'Automatic' table layout. If it used table-layout:fixed and specified widths for the <col>s then the W3C says:
Fixed table layout
With this (fast) algorithm, the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing...
...In this manner, the user agent can begin to lay out the table once the entire first row has been received.
I agree with you Shawn, looking at the logs for big bandwidth files is often a good place to start.
But the perception of speed is also important. I am a lot less likely to get bored if some elements appear straight away and I have something to distract me while the rest download. And unfortunately the logs can't tell you about this, you just have to find a slow connection and try it.
Front Page doesn't help as I've learned but it's what I use and will continue to do so. Code bloat seems to be a big issue while using FP but unfortunatey I'm not up to speed on what I need and don't need...still a newbie to all this.
I had alot pages at 80K and above. Took many pages and made two or three out of them while concentrating on themes around them. Images were far too large...knocked them down 70%. I had image page buttons that used up nearly 40Kb....gone now. Also an image near the top of every page that really fowled up load time.
More work for sure especially the FP bloat crap but page stickiness went from 2.1 to it's current 4.1. Time spent has increased substantially as well as I'm assuming the dialups I lost before are sticking around.
Wanna check load time on a slow dialup? I do it all the time as I'm on the road alot in hotels with a laptop. I've seen as low as 14Kb...talk about frustration when I'm used to a cable connect at home!
Okay, yes, this makes your site an administrative nightmare, so you're going to have to compromise on these extreme measures for usability's sake - and possibly for search engines' sake in some instances.
In my experience, getting familiar with CSS is the key. Assigning your default fonts values to the TD tag instead of using endless FONT tags can same a huge amount of space.
Tiling backgrounds instead of fixed graphics.
Slice big graphics so you can save space by saving some sections as PNGs or GIFs instead of JPEGs. Don't assume that HTML output from apps like Fireworks is going to incorporate any space saving techniques - chances are that the code with be bloated.
Some flat-colour graphics will be smaller as PNGs, some with be smaller as GIFs. Try both.
The site in my profile uses long filenames for supposed search engine reasons. However the drop-down list navigation isn't spidered by search engines. Therefore I've used short dynamic URLs in the drop-downs instead of the full-length ones in the main code. Both types load in the same pages. This alone has saved 2-3K per page.
I'm convinced that a fast-loading site is of the utmost importance unless your brand is so huge that visitors are prepared to wait - and I'm talking the size of The Matrix, Ford, Coke etc.
for instance at home i have ADSL and i don't really want to pay an ISP for a 56k dialup aswell just to simulate how users with slower connections see my pages!
some 'ware like that would be extremely useful :)
grahamstewart is quite right with relation to fixed-layout-tables.
A comparison demo can be seen [msdn.microsoft.com...] [note: there's no download, just in case the folder name puts you off!]
OK, Graham, I take the point that different browsers will do things differently. However, this is very strange... I don't get your symptoms at all... I tested with a 56k dial-up using IE 6.0.28, and the text comes up pretty quick (3 seconds), with just the icons in the left (user profile vs sticky mail, etc) taking a few seconds longer. (Although I agree the logo/location bar do come up first).
[Added: I should have refreshed my browser... Then I would have seen TheWhippinpost's post... Seems you guys are right... Thanks for setting me straight.
I notice it most when on the 'message list' screen, where there at least 50 rows in the table.
However, Whippinposts Microsoft demo shows the effect very clearly. Thanks WP, good find.
I just downloaded "HMTL Shrinker" and it has reduced my website pages by about a 1/3 in size...not too bad.
However i notice that it removes all the spacing and carriage returns in the HTML Code
Apart from this being difficult to read - does anyone know whether this will effect how a search engine bot reads the code - i.e. will it get meta tags mixed up... or will it read it in exactly the same as before?
The only issue with shrinking HTML that I've come across is IE adding vertical space if you have a line break after certain closing tags (</SELECT><BR /> renders differently to </SELECT> -line break- <BR />). If part of your site shrinks vertically after using HTML Shrinker you'll know why.
I'm absolutely confident that stripping those characters from a well-built page causes no ill effects in the search engines.