6 ms·

Ask HN: Reduce Load time 'appearance'

22 points by lachyg 16y ago

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. I'm wondering if anyone knows any articles on reducing the appearance of load time? E.g. progress bars, countdowns, etc.

LeBlanc 16y ago
jQuery UI has a progress bar that you can use: http://jqueryui.com/demos/progressbar/ 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.
Scott_MacGregor 16y ago
10 seconds is not good at all. What is causing it to load slow? Are you coding in ASP?
- lachyg 16y ago
  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 :)
  - deleted 16y ago
    [deleted]
  - mahmud 16y ago
    Mate, just send out a naked response containing all the static elements, then refresh the content via ajax. 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.
  - Scott_MacGregor 16y ago
    Maybe put the data feeds into frames on the page so the main page loads quickly and the frame data can load as it comes in. Then use a simple progress bar for each frame. 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.
  - byoung2 16y ago
    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 16y ago
      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.
  - ritonlajoie 16y ago
    Do you display someting like 10 entries per XML feed ? If you only display one, just get the first one, then in the background, get the remaining !
    - troels 16y ago
      Probably won't work. Fetching a feed is usually heavy because of the connection overhead - not the actual transfer or parsing.
  - troels 16y ago
    Don't do that as the page is rendered. Have an offline job pull in those feeds and store them in a database, then have the frontend pull from the database. Even if the feeds are highly specific for the page loaded - In that case, model the database as a queue where the frontend requests the feed and the offline jobs pulls them. This will allow you to parallelize the feeds, which is otherwise neigh impossible to do in php.
sahillavingia 16y ago
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).
- deleted 16y ago
  [deleted]
byoung2 16y ago
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
sounddust 16y ago
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 16y ago
  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.
mahmud 16y ago
I'm launching a site in a few hours Performance engineering shouldn't be an after thought left for the eleventh hour.
- lachyg 16y ago
  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 16y ago
    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 16y ago
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 16y ago
  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 16y ago
    If you're scraping 10 feeds, can you plot the hotels off each feed as they come in?
lachyg 16y ago
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 16y ago
  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.
anigbrowl 16y ago
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.
- jamesjyu 16y ago
  Reticulating splines..
- gruseom 16y ago
  This comment is gold. Strongly agree.
- ErrantX 16y ago
  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 16y ago
    Got a link to this demo mate?
endtime 16y ago
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.
gorm 16y ago
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 16y ago
  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 16y ago
    I believe that's how Mac OS X handles the bootup progress bar.
azharcs 16y ago
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 http://developer.yahoo.com/performance/rules.html

22 points by lachyg 16y ago

LeBlanc 16y ago

jQuery UI has a progress bar that you can use: http://jqueryui.com/demos/progressbar/ 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.

Scott_MacGregor 16y ago

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

lachyg 16y ago
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 :)
- deleted 16y ago
  [deleted]
- mahmud 16y ago
  Mate, just send out a naked response containing all the static elements, then refresh the content via ajax. 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.
- Scott_MacGregor 16y ago
  Maybe put the data feeds into frames on the page so the main page loads quickly and the frame data can load as it comes in. Then use a simple progress bar for each frame. 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.
- byoung2 16y ago
  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 16y ago
    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.
- ritonlajoie 16y ago
  Do you display someting like 10 entries per XML feed ? If you only display one, just get the first one, then in the background, get the remaining !
  - troels 16y ago
    Probably won't work. Fetching a feed is usually heavy because of the connection overhead - not the actual transfer or parsing.
- troels 16y ago
  Don't do that as the page is rendered. Have an offline job pull in those feeds and store them in a database, then have the frontend pull from the database. Even if the feeds are highly specific for the page loaded - In that case, model the database as a queue where the frontend requests the feed and the offline jobs pulls them. This will allow you to parallelize the feeds, which is otherwise neigh impossible to do in php.

sahillavingia 16y ago

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

deleted 16y ago
[deleted]

byoung2 16y ago

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

sounddust 16y ago

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 16y ago
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.

mahmud 16y ago

I'm launching a site in a few hours Performance engineering shouldn't be an after thought left for the eleventh hour.

lachyg 16y ago
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 16y ago
  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 16y ago

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 16y ago
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 16y ago
  If you're scraping 10 feeds, can you plot the hotels off each feed as they come in?

lachyg 16y ago

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 16y ago
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.

anigbrowl 16y ago

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.

jamesjyu 16y ago
Reticulating splines..
gruseom 16y ago
This comment is gold. Strongly agree.
ErrantX 16y ago
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 16y ago
  Got a link to this demo mate?

endtime 16y ago

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.

gorm 16y ago

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 16y ago
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 16y ago
  I believe that's how Mac OS X handles the bootup progress bar.

azharcs 16y ago

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 http://developer.yahoo.com/performance/rules.html