Site optimization: Actual v. Perceived Speed
The other day I was working with a buddy who was having some difficulty with his site. He had a dark background, but the center columns (with the text) were light. The light background was loading in late because some of the ads on the site were loading in slowly and as a result the site wasn’t legible (dark text on dark background) until several seconds after all the ads loaded. This wasn’t really a good situation to be in - you know how fickle visitors are, turned off at the slightest delays.
The first thing I looked at was the load speed of all the components. Fired up Tamper Data, good ol’ Tamper Data, and watched everything come in. It’s graphing ability makes things very clear and I saw that several of the ads were coming in slowly. So initially I started experimentally paring out the ads - but it became clear that it wasn’t one ad that was the problem but all of them. It wasn’t an option to remove everything. So I took a step back and looked at the actual problem.
The real problem was that the page would come in but because of the dark background it was illegible until most of the ads came in and the light background of the center columns painted in. I’ve seen this on several sites with dark backgrounds, so I started looking around at the html to see what was happening. It turns out there was one big div that encapsulated two interior divs (one for the main column and one for the right nav) and the light background was happening in this outer div. The light background only rendered when everything inside it was rendered. Fortunately, nearly all the ads/beacons were in the right nav so the easy fix was to move the light background into the main and right nav divs as well.
The result of this is that when you come to the page it looks perfect immediately - except the right nav is rendered in stages a few seconds after you hit the page. This is, for most people, just fine. There’s a lot of work you can do optimizing your pages and optimizing your delivery. There’s tools to help you do just that (tamper data or yslow, for example), but sometimes things are just going to be slow. There’s tons of beacons and ad networks out there that simply can not be enspeedified and if you decide that you want to use them, it’s just a fact of life that your pages will complete slightly slower than if they were not there.
For these cases you need to understand the trade-offs and be able to deal with perceived speed issues. That is, even if the page finishes slowly you want it to appear to render very quickly. These are html/css issues as well as organizational ones. Moving as many of the slow loading pieces into a position that doesn’t impact the snappiness of your main content is incredibly important. That way, they affect your secondary content, like navigation and archiving, which are typically looked into after perusing the main content. If they come in seconds after load, most people won’t even notice.
As an example of another trade-off, some beacons suggest you put them at the top of your content - this increases there accuracy as they are the first thing that renders on the page. However, if that service is having trouble it can slow down the display of your whole page. If you put it at the bottom of your page, it’s accuracy may be trivially reduced, but even if it shows up slowly, it won’t generally affect your perceived speed. You need to decide which is more important. Just remember, some people’s connections and computers are slower than yours, so even though your site looks pretty snappy to you, if you’ve got a lot of widgets and beacons it may be pretty slow for others.
Ultimately, don’t use widgets where straight html will do, but if you need to, be smart about where and how you place your widgets and structure your pages.
October 1st, 2007 at 11:06 am
go flash :)