

Ask HN: Reduce Load time 'appearance' - lachyg

I'm launching a site in a few hours, and it takes around 10 seconds to load all the data, which isn't really reducible by much time.<p>I'm wondering if anyone knows any articles on reducing the appearance of load time? E.g. progress bars, countdowns, etc.
======
anigbrowl
I can tolerate a spinner and don't mind a progress bar, but what I like most
of all is a display telling me what it's actually doing. If I see a bunch of
libraries that are being loaded or sockets opened then I understand that
progress is taking place. I don't actually need to know the specific details,
just give me something to do/think about while I'm waiting. It could even be
knock-knock jokes if they're funny, but when I see some workings of the
program/page exposed as status information while it loads, I feel more
invested in using it because the designer/coder is keeping me in the loop.

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.

~~~
ErrantX
We've been experimenting with replacing load bars with a short textual
description; which got a lot of positive feedback from clients.

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".

~~~
lachyg
Got a link to this demo mate?

~~~
ErrantX
No, unfortunately. It is with work & our private customers.

------
sahillavingia
Staggered loading-in of data works extremely well. Instead of loading in 100
items, load in 10-20 (whatever will fill up to the fold*2 is my go-to
threshold), and then background load the rest as the user is busy with those.

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).

------
sounddust
Take a look at travel sites and see how they do it. Personally, I prefer
Kayak's approach: show whatever you _do_ have as soon as it comes in.

~~~
tjarratt
This is true, but for the poster's situation, it sounds like he has a lot of
data, all of which must be loaded before they can display any UI.

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.

------
gorm
Try this little hack. First time when you load it, just time how long it takes
and store it in a cookie. Next time, just assume it takes the same amount of
time and show a progress bar.

Really easy to code and good enough to fool the user.

~~~
tjarratt
That's a really great idea! The best part is that if you can cache anything,
subsequent loads should be faster, so the initial load serves as a loose upper
bound for the entire load process.

~~~
mst
I believe that's how Mac OS X handles the bootup progress bar.

------
mahmud
_I'm launching a site in a few hours_

Performance engineering shouldn't be an after thought left for the eleventh
hour.

~~~
lachyg
Totally agreed. Just want to get an MVP out, and then iterate. We've been
doing our best to take the time down, and we think we've got it down to as low
as it can get, we just want to make the wait more bearable.

~~~
mahmud
If it's an MVP to test the market, then that "few hours to launch" constraint
is pointless. Take a few more days to make it "fast enough", then launch. By
the way, 7AM Monday morning is an excellent time for news, if you want some
social-media love.

------
qeorge
They key is that "something" is happening. Mario Kart online does this really
well - the wait time between races is extremely long, but they switch between
4 screens and several throbbers while loading the race, so it feels snappier.

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?

~~~
lachyg
We're loading the site, and a map, then it says 'Loading Hotels' which takes
5-10 seconds, and displays them on a map, then removes the load sign.

~~~
qeorge
If you're scraping 10 feeds, can you plot the hotels off each feed as they
come in?

------
byoung2
_it takes around 10 seconds to load all the data, which isn't really reducible
by much time_

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

------
LeBlanc
jQuery UI has a progress bar that you can use:
<http://jqueryui.com/demos/progressbar/>

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.

------
lachyg
I'll provide some context. We're pulling in results from Expedia, filtering by
Price / Stars, and we need to pull the query in multiple times based in min
stars, and the price. Then exclude certain results.

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.

~~~
zackham
I think the best user experience you're going to get is by giving the user as
much information as possible. Throbbers deliver almost no information (just an
indication that _something_ is probably happening); progress bars exceed that
a bit by indicating a rough percentage of completion and allow the user to
estimate time until completion, but users are trained to be suspect of
progress bars (who hasn't been at 99% for 99% of the time...).

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.

------
azharcs
Best Practices for Speeding Up Your Web Site by Yahoo, It is a very useful
link for improving website performance.
<http://developer.yahoo.com/performance/rules.html>

------
Scott_MacGregor
10 seconds is not good at all. What is causing it to load slow? Are you coding
in ASP?

~~~
lachyg
PHP. We've got to collect about 10 XML feeds. Basically the site loads, but it
takes time for data to come in.

We collect the data, then filter it, then display it. Will do a Review My
Startup in a few hours :)

~~~
byoung2
You should look into caching the results from the XML feeds in a database, as
well as caching the output of your app. For example, if your app needs to pull
weather data from one XML feed by city, and stock quotes from another by
ticker symbol, consider using a cron to pull these at 5,10,15 minute intervals
and store them in a database. Then, have your app always look at the database
for the data. You can even cache these queries using memcached, etc. Then,
cache the output of your app in a static file and serve that with a 5,10,15
minute timeout. Most of the time your users will get the static cached file,
and if not, they will get a page generated from a memcached query result, or
pulled from the local database.

You never want to serve up that many XML feeds live because when one of them
is slow or down, so is your site.

~~~
kingofspain
Second this.

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_.

------
endtime
The rule of thumb I've heard is that if you're going to show a spinner, wait
around a second before you show it. I like anigbrowl's suggestion more,
though.

