cancel
Showing results for 
Search instead for 
Did you mean: 

Blo_dy FrontPage - Index page - slow

N/A

Blo_dy FrontPage - Index page - slow

YES, YES I know NOW! We have nearly finished building our first website in FP 2000, but have not uploaded it yet. It’s told us the index page takes 26 seconds to download at 56.6K, which is clearly too long. Our index page consists of tables with hyperlinks to other smaller pages and five small pictures jpg format (total of pictures = 54K).

Q1. Can we reduce the download time without changing the appearance?
OR
Q2. Insert a simple (quick) page that can be viewed while the index page is
downloading underneath?

Your comments, advise and help would be very much appreciated.

Pauline
3 REPLIES
N/A

One idea I hope might help?

Hi,
Yes! the key I personally think to fast webpage loading is to keep all the fancy graphics to a bare minimum (thats doesnt mean your webpage has to look aweful, or written by a zen monk!). If a webpage takes ages to load most users goe else where (be warned its true!).

Heres what I suggest you might like to try:-
1) change your .JPG or .JPEGS for .gif images if you can as gif's are smaller & thus load faster I think.

2) Hyperlink are small and so you shouldnt have to worry about them on there own.

3) Convert your table/s into a spreadsheet type table/s using something like MS Excel and then save the selected spreadsheet or sheet area into and image via copying it to the clipboard and pasting it into MS paint and create a .bmp or .gif image out of it.

Hope the above might be of some help? Best Regards Ivan :-)
N/A

Blo_dy FrontPage - Index page - slow

A few thoughts of my own on this, to add to Ivan's / "cyteck's":

26 seconds may not be unacceptable, as long as the viewer is able to see something and start reading, or whatever. So, although the page may not have downloaded in it entirety, the user is still occupied and may not notice its not complete.

This is aided if the browser is not constantly having to resize or re-arrange things as downloading progresses. You've mentioned tables and images, both of which can cause the browser to have to recompose the page as it discoveres more about them (eg how many columns in the table? How wide should the table be rendered? How much space needs to be reserved for the images?). The more information you can provide the browser up-front (ie by coding it in the HTML) the less disruptive it will be.

The World Wide Web Consortium provides some guidelines on performance, including the incremental display of tables in an appendix to the HTML 4.01 specification.

Regarding images, if your images amount to 54K of data, then you'd expect them to download in about 10s on a 56kbps connection (or rather more considering people won't actually get 56kbps). Is the 24s an estimate, or a measured time? How long does it take if you tell the browser not to bother with images? What's taking the rest of the time -- is it the HTML itself, or is there something else? How long does it take to just download the images (eg a bit of HTML with just the "img" elements coded)?

Have you specified the image sizes in your HTML? eg:
    <img src="someimage.gif" alt="description of the image" height="75" width="100" />
which will allow the browser to know how much space to reserve for the image in advance of having downloaded it.

Also, have you scaled your images appropriately -- I once saw a webpage in which the height and width were specified as indicated above, to give an icon sized result, but the image being downloaded was much, much bigger, a full-screen image, several hundred kilobytes in size, being scaled-down at the browser!

If you use gifs, as Ivan suggests, or even the newer png (Portable Network Graphics) format, you can "interlace" the images so that the whole picture initially downloads but in less detail, and is then gradually filled in, rather than downloading in full quality, but with the image completing a band at a time until it finally occupies its full height.
N/A

Blo_dy FrontPage - Index page - slow

Just a short note on images to add to task's and cytek's comments: gifs aren't always smaller than jpegs. It really depends on the number of colours in the image. A rule of thumb is that if there are 256 colours or more the image will compress better as a jpeg and if less than 256 colours it'll compress better as a gif.

Before we speculate further perhaps you could upload the site to your fp space so that we can see exactly what you've got? This would take the guesswork out of it Smiley

Jon.