Forum Moderators: open
Does anyone else have a big homepage and do you encounter any problems?
You did not say if it was graphics, text, code etc that made up the bulk of the content. For example as an experiment I managed to call external java and lose over 4kb of code. If you have navigation buttons could you replace rollover buttons with CSS hovering??
hope that has given you a couple of ideas.
Cheers
Obviously, the less bandwidth you use the better -- but there comes a point where you start paying in terms of quality. Overcompress a JPEG, and it looks horrible.
You can employ a few cunning tricks to make a page look as if it is downloading faster than it really is, or at least to prevent users bailing because they think their browsers have hung. These include:
1. Arrange for a banner heading (or something that identifies the site in some way) to render first. That means, for example, not putting all your content into one big table, because browsers have to download the entire table before they can display anything.
2. Take advantage of the browser cache. Use external scripts and stylesheets -- these will be pulled from the cache on subsequent visits. Reuse images as much as possible. (Of course, this will not benefit users on their first page view.)
3. Always specify width and height attributes for images etc.
4. If you have large images that you can't optimize any further, use progressive JPEGs and interlaced GIFs or PNGs.
5. The obvious things -- don't use textigraphics unless you really need to, avoid animations, sound files, applets etc which are objectionable on other grounds as well.
I managed to call external java and lose over 4kb of code.
I assume you really mean Javascript (Java would slow things down a lot while waiting for the JVM to start up). Anyway, you aren't saving anything on the home page unless the user already has the homepage in the cache, in which case we don't really care about a few kb here and there anyway.
You save something on each subsequent page, but the first time the user loads the page, you have to count external JS, CSS, graphics and everything else in the page weight. It's still a good idea, but what you've actually done is added the overhead of another file access and so forth.
Tom
Perhaps I answered this slighty the wrong way. I was thinking of javascript and in the context of the original page size I thought this (4KB) was quite good.
When I look at the log files, from Se's I see a request for the main file only and not the external files. This has to be good as all I am delivering to the SE's is content and not guff. Admittedly I am doing the old <div> solution, but it seems to work for me.
I was just trying to give a few ideas to our man Dazz
cheers
Although most pages I check weigh in around 60k or more, I have always kept to the homepage under 40k and the rest under 30k (if at all possible.)
Three page lengths (as mentioned above) would seem awfully long if full of text content, so I never go over two page lengths. However, my stats report that only 30% to 40% of my visitors are actually going on to the second page after I broke-up a few recently, but of course there's no way of knowing if all the content was being read prior to breaking up these pages.
Moving my JavaScripts off the page, as well as converting to CSS, was a major reduction in bandwidth. Also removing white-space was surprisingly benneficial.
My home page is 8k, in general I try and keep the html file under 15k, total weight with images less than 40k. I just reproduced a complex page from a major site, visually identical, and cut the page size from 29k to 13k, total page weight with images from 106k to 55k.
If you cut out the content and put it in a txt file, what is your code/content ratio?
The Page Diet:
Tables are usually heavy items, take out the excessive formatting, stringing it out in longer lines if you need to keep the table (as opposed to css div's)
Obviously get rid of font tags, replace w/ css. Put javascript in external files, trim unnecessary or excessive meta tags, avoid javascript rollovers, image maps or other code heavy forms of navigation. String your code out in longer lines (Browsers actually like this, they can gulp lines up to 255 characters. I don't like to scroll to find stuff, so I stop at 100 characters or so, and break where It would be helpful in reading the code. Check that images are optimized, and I generally frown on pages that call 30 little images. There are more resources out there on page size optimizing if you really get into it.
