Slow Pages

Slow pages are most visible on slower internet connections. People with high speed internet may sometimes forget that over half of the world is still surfing with 56k or slower.

Slow pages always have one of two root causes that the site owner can control: bad hosting, or pages with a high total "page weight". The other things that can slow them down, such as poor computer performance, or overload on an ISP, are not within the control of the site owner, but should still be considered when building large pages.

Your web host may be trying to fit too much activity onto a single server. This is a problem with many budget hosting services (GoDaddy has this problem). Those hosting services may not be a problem for lightweight pages and minimal traffic, but when either traffic increases, or if you have large pages, the hosting may no longer be adequate.

So what makes a "large page"? It is usually NOT the length or the visible size of the page. While a very long page certainly takes less space than a very short one when all other components are equal, the page weight is usually affected by things that the average person does not see. Because they do not see it, that makes it even more important to build efficient pages, because visitors WON'T understand why your page, which appears substantially equal to another page, loads three times slower.

Here are some elements which contribute to a high page weight:

  1. Code bloat. Certain programs (can you say, "Microsoft"?) produce code that is very lengthy, taking 3-5 times as much code for each element as what other software produces.

  2. Extremely complex tables. Normally tables are a common element which are used extensively to control placement of elements on the page. They are more predictable at this juncture, especially for newbies, than CSS is, so they are still used extensively even by high end site designers. But when you get complex tables, very large tables (such as to show a long spreadsheet type chart), or multi-level nested tables, they take extra code to describe them.

  3. HTML Shopping Cart Code. Since each link in an HTML based shopping cart (where you edit HTML code on the page to control the shopping cart - such as PayPal or Mal's) has a couple of lines of code, or much more, what you see on the surface is not nearly what is behind the scenes. 10-30 Buy buttons on a page isn't going to slow things down much. 50 to 100 will make a noticeable difference in the file size.

  4. JavaScript, Forms, and other "on page" code. Again, you just see a little button or single element on the page, but it make take quite a bit of code to describe that element behind the scenes, plus the site has to tell the server to do something that the visitor does not see happening.

  5. Images. Images remain a separate part of the page - they are not embedded in the HTML file, but rather, they are uploaded beside the HTML file, as a separate file. But each image you show on the page adds to the total page weight and download time for the page. Images that are too large, or excessive images on a single page, are a major reason for slow pages. Since image file size is affected by more than just the visible size of the image, it is important to read up on this topic separately.

  6. Flash elements. Flash elements also reference a separate file that gets uploaded. They tend to be huge, often exceeding 5-10 times the size of the average page. These are items that no matter how efficiently you do them, will never be anywhere near fast for dial-up.

  7. Dynamic Page Elements. The coding for dynamic page elements is typically larger than for static elements, because it has more variables which must be accurately coded. They also have to go fetch individual results from the server, which also takes extra time.

  8. Dynamic Sites. Sites where the majority of the pages are created on demand, according to user input, are slower in general than static pages. This is because the actions of the user send a message to the server, and the software on the server then creates the code for the page based on what the message was. Some types of scripting are fairly quick, other types are much slower. I don't have a problem with the delays when the site function justifies it, but I do have a problem with using this type of site for a site that could have just as easily be done with static HTML.

We get back to the justification issue. For features that are worth the wait, or that are essential to the primary purpose of the site, delays are acceptable.

But for sites where complex coding is totally unnecessary, or where page bloat is present due to lack of proper care on the part of the web designer, slow pages are a major annoyance.

More than an annoyance sometimes, because slower connections will often time out before the page fully loads. Many people do not even realize that they can click the Refresh button to have it try again, they just leave, feeling like your site doesn't work.

Make each element as small as possible, while still retaining the necessary function, detail, or impact. Don't add bells and whistles just because you can, and don't leave elements too large just because you are too impatient to do them right. Take the time to streamline your site, and your visitors will never notice - that is as it should be! Fail to do it, and they WILL notice, and leave, and never come back.

Written by Laura Wheeler