9 Causes of Web Page Obesity

Broadband speeds are improving but page weight still matters. If your web pages have become a little bloated, spare a thought for those people on slow connections or using mobile devices. Will they buy your services if you make them wait several minutes for your 5MB monstrosity?

It is possible to create mobile or low-bandwidth versions of your website, but few of us have time or resources to create and test multiple versions of content. But there’s little excuse for not keeping in shape — especially when Google could reduce your rank. Leaner pages appear faster, reduce your hosting costs, save your client’s sanity and are environmentally-friendly!

Here are 9 reasons why your site could be piling on the pounds…

1. Over-the-top advertising

We all need to earn a little money but adverts can be the biggest cause of ballooning bandwidth. Most are graphical and many use animation or video to catch the eye.

There are several ways to address adverse advert obesity:

  1. Don’t overdo it. Adverts are distracting and while most web users expect a few, don’t bombard people with dozens of flashing images. Fewer adverts may receive more clicks if your page doesn’t look like promotional puke.
  2. Remove ads which aren’t working. If a huge advert has raised $0.03 in 5 years, perhaps you can make better use of that space.
  3. Try text-based adverts.

2. Inappropriate use of plugins

fat pagesLet’s be frank — I’m talking about Flash. Despite what Apple think, Flash has its good points. But text content, roll-over effects, and simple navigation menus are not the best uses of the technology.

3. Not optimizing images

If there’s one thing I detest, it’s images which haven’t been resized for the web! Digital camera resolutions have reached ridiculously high levels, but no one wants to download a 5,0002 pixel photograph of your dog. Changing the height and width dimensions in the img tag don’t make a difference — you need to resize your images in a graphics package.

When saving, remember to use the best format and highest compression available. In general, photos are better as JPG and graphics are better as PNG or GIF format. However, you will need to experiment with formats and compression rates to squeeze the most from your images.

Finally, keep an eye on Scalable Vector Graphics (SVG). They could revolutionize image production and file sizes if Microsoft keeps its promise to add SVGs in IE9.

4. Not using image sprites

Lots of little images usually sap more bandwidth than a single large image. Each image requires a separate HTTP request/response and most browsers will download a maximum of 4 files at a time. Putting many images into one file then splitting them with the CSS background-position property can save bandwidth. Amazon.com has a great example.

5. Over-reliance on JavaScript frameworks

I’ve nothing against jQuery and similar libraries, but be wary about becoming too dependent on them. Using two or more libraries for effects may also be wasteful.

The W3C website is prime example: it loads a 22Kb file containing jQuery and a plugin to handle basic stylesheet switching. It could have been written in a dozen lines of JavaScript with better browser support.

6. Inefficient HTML

The best HTML is lean, clean and easy to maintain. Your code could be getting out of hand if you find yourself adding 15 nested div tags each with an ID and multiple classes.

WYSIWYG design packages are partly to blame. They have their place, but don’t consider yourself to be a web developer until you have reasonable knowledge of HTML!

Older versions of Visual Studio and ASP.NET web forms can also generate truly shocking and verbose mark-up. Visual Studio has improved, but even previous versions can generate clean code. Be careful when dragging and dropping controls and inspect the resulting HTML.

7. Embedding CSS and JavaScript

CSS and JavaScript should be contained in external files which can be cached and reused throughout every page on your site. There is no excuse for bulking up your HTML with embedded styles and event handlers.

I’d also recommend putting your script tags at the end of the page just before the </body> tag. The page can then be viewed before any scripts are downloaded and executed.

8. Not exploiting CSS cascades or shorthand notation

A little CSS knowledge can go a long way. Novice coders often apply classes to every HTML element and set properties such as font-family within every CSS definition. A little background reading can drastically cut coding time and stylesheet file sizes.

Don’t forget shorthand notation either. The following code snippets are stylistically identical…

Overweight CSS:


#element
{
	margin-top: 0px;
	margin-bottom: 10px;
	margin-left: 5px;
	margin-right: 20px;
	background-color: #aabbcc;
	background-image: url("myimage.png");
	background-position: center center;
	background-repeat: no-repeat;
}

Toned-up CSS:


#element
{
	margin: 0 5px 10px 20px;
	background: #abc url(myimage.png) 50% 50% no-repeat;
}

9. Not using compression

Your server can gzip files before they’re sent to the browser. HTML, CSS, and JavaScript files can all be compressed by removing comments and unnecessary whitespace. There are many tools and applications to help you squeeze the most from files prior to deployment or automatically at runtime.

Do you know of any other causes of web page obesity? Comments welcome…

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • richthegeek

    Some of these are good examples, others seem like space-fillers.

    There are really only three things to worry about: Flash, images, and code.

    Flash is by far the worst for weight and processor clogging (makes some pages unusable in Linux), and cutting them out is generally worth the time investment in pure usability and conversion rates.

    Images tend to be more vital, and time yields smaller, yet still significant gains. That said, there is a big difference between resizing an image (huge saving) and compressing to the optimal quality (mediocre saving) in most cases.

    The point about sprites is not so much about size (although there will be gains here) but connections. The browser will only open so many synchronous connections to the same server at the same time, so if you have 30 images to load and each one takes 0.5s to connect, you will be looking at upwards of 4s in just domain resolution. The two solutions are to either use multiple sub-domains such as img1.amazon.com and img2.amazon.com, OR to remove the issue entirely by compressing them into a single sprite. It’s not *size*, it’s *speed*.

    Finally, code – the sizes here are frankly piffling when you look at time/savings. Even with a fully verbose CSS being 4 times the size of the compressed/top-level rule, the saving would be maybe 100kb with Sitepoint’s quite weighty CSS. Considering that can be more than saved with even one image being resized, it’s a huge time investment (although it’d be easy to write some code to automatically minimise a sheet).

    tl;dr : remove flash and resize your images. Anything beyond that is not really worth it.

  • http://codefisher.org/ codefisher

    Too many comments!!

    :P

  • http://www.optimalworks.net/ Craig Buckler

    Thanks richthegeek — some good points.

    Sprites do affect size and speed. Every request receives the file and header information from the server. Therefore two 100 byte files still require a larger overall data transmission than a single 200 byte file.

    I agree that the savings you can make in CSS are far smaller than those with images, Flash, etc. But look after the bytes and the kilobytes will look after themselves!

  • tiggsy

    It’s possible to resize images using php. My biggest sites use a lot of images, but at small sizes. I wrote a script that works every night to pick up images in gif, png or jpg format and produce the optimized versions used, which has speeded up my site so much it’s incredible.

  • Niubi

    So how do websites like http://www.dubli.com fit into this scheme? I’m new to this kind of thing and I’m finding it hard to get a handle on it to be honest. Practice makes perfect, I guess :)

  • NetNerd85

    I agree that you should watch 1 and 7 but the rest are not really things to worry about apart from the obvious techniques to reduce size. I don’t think you should go crazy and freak out that your CSS is not optimized for size. I’d rather it be readable for myself and others that want to view it.

  • http://vanishdesign.com vanishdesign

    There are many tools and applications to help you squeeze the most from files prior to deployment or automatically at runtime.

    Cool, but where?
    And how do I set up GZIP on my server?

  • http://www.optimalworks.net/ Craig Buckler

    @vanishdesign
    Good point — that’s a topic for another article…
    Stay tuned!

  • http://www.joecianflone.com ChestRockwell

    I think this is a funny article because the sitepoint website breaks a lot of these rules.

  • Tariq

    Good and prominent work keep it up.