I'm wondering if anyone knows any articles on reducing the appearance of load time? E.g. progress bars, countdowns, etc.
A progress bar might be actually progressing, or it might just be an animation - and when I see a progress bar that gets to 99% or 100% and then just sits there, I find myself reflecting that the developer or product manager is lying to me in a small way. It's especially annoying when the 'progress' represents a list of startup tasks, without regard to the time they take - it moves smoothly through 30%, jumps to 95%, and then sits there for a long time before disappearing. This is the opposite of informative.
Then we tried adding a "count up" timer for each piece of text - i.e. a timer that counts how long you're stuck at each segment.
This was an entirely graphical tweak (that shipped with an update to another service) and we immediately got feedback along the lines of "OMG, whatever you just updated it is so so fast now! great stuff".
Think about caching too, if a particular XML feed is fetched frequently.
Also, animations and fades really help in the appearance of speed (versus the above, which actually increases it).
In this case, it sounds best to display some real progress dialog. Some people suggested 'reticulating splines' messages, which were very popular in Will Wright / Maxis games. I guess the trick here is finding appropriate messages to display and associating them with tasks/events in your load sequence that are long enough to be meaningful, but short enough that the user doesn't feel it dragging.
Really easy to code and good enough to fool the user.
Performance engineering shouldn't be an after thought left for the eleventh hour.
Bing and Chrome do this well too - they paint as much of the UI as they can quickly, and load the heavier elements progressively.
Are there parts of your page that you be rendered progressively as the data loads? Can you render the page first, and then load the data via AJAX?
Is it possible to cache the data? Even for something like news, stocks, or Twitter streams, the data probably doesn't need to be absolutely real-time. Static caching at 5 or 10 minute intervals shouldn't affect the freshness of the data (especially for non logged-in users), and your page will load a lot faster (likely 1-2 seconds at most).
Look into a caching proxy like Varnish to achieve this. Here's a setup I use in most apps:
Database: read from slaves, write to replication cluster Memcached on database queries (tune timeout based on query type) Static caching in application layer (e.g. Smarty or Symfony caching) Varnish caching in front of app server CDN for images, javascript, etc
Another thing you can try to do is to load the site in chunks so that the user has something to look at ASAP. If you give them something to look at, they will be more tolerant of a 10 second wait time, which is really long for the web. I have no idea what your website is so this may not be applicable.
Basically, we can cache, but it has to be reset often, as we can't cache price data for too long. I'm sure we can do something about the stars though.
I would give a progress bar with semantics specific to what you are doing (step 3 of 5 instead of 60%), estimated time to completion, and a description of the current step (Submitting search request to Expedia... Filtering results... etc).
It can be accomplished a lot of ways, but will likely be more responsive if you push the data. The easiest way I have set up something like this has been node.js, redis pubsub, and socket.io. Requires some reading, but the end result is you can push messages through Redis from your app easily, it will work in all browsers, and you won't have to write very much glue code at all.
We collect the data, then filter it, then display it. Will do a Review My Startup in a few hours :)
The users will see the full page instantly, but all the data-heavy tables will have spinner.gif laid over them until they're loaded.
Progress bars are not an optimal solution to this. Many websites shoot for 3 seconds or less load time because a lot of people will not want to wait.
Another tactic might be to prefetch the data somehow as soon as the first page loads into a visitors browser and feed the data to the user before he asks for it. If he does not ask for it you will burn unneeded bandwidth preloading it, but something needs to be done to get load times down from 10 seconds to avoid losing users.
You never want to serve up that many XML feeds live because when one of them is slow or down, so is your site.
I built a similar site a year back and what I did was pull in the UK XML data daily (the feed was updated daily) and database that mother. I'm not sure how often Expedia updates its hotel prices, but you could maybe poll every couple of hours instead.
We also had a free search for anywhere in the world, so we'd pop up a spinner and grab the XML. Then we'd cache that result set in the DB with a rudimentary script and store it for the next 24 hours. That would then be served to anywhere searching for the same thing in the meantime.
Overall, it sped things up dramatically.