Is a slow home page better than a loading bar?

Question

I am working on a small site which needs to load a large amount of data to show on the home page.

The page container loads fast (~1 second) but then I need to retrieve data from a database and perform calculations on it and display it in a table.

I do this via Ajax calls, but it slows the use of the page down until this completes. If you scroll, the scrolling is jumpy, etc.

Should I allow the user full access to the page after 1 second, but for the next 10 seconds the page is a big slow and laggy to use?

Or should I just display a pop-up with a loading bar and block them using the page until the page is fully ready and responsive?

Once the home page loads, the site runs really fast and all is good.

Answer 1

The latter for sure. The users will experience a poor user experience with the former.

What's interesting about this question is that it raises the notion of 'visibility of system state' or "as long as I know what's going on, I feel I am in control" and that's just what your loading bar will do.

I suppose a more important question is where this status bar is presented. A lightbox over the page until loading finishes is one option. A bar at the head of the page is another.

Edit: Jane's solution down the page is a better way.

Edit 2: Jane's idea may have some folks not to enamoured by it "I find the way it works in Facebook incredibly stupid"

In this case, you need to go out and user test your ideas. Test a skeleton page, a page load indicator and a direct interaction and see which does best in testing. That's the real solution!

Answer 2

You might want to look into skeleton ui patterns or placehold patterns. They're very popular right now and are used by for example Facebook.

I found a nice short article on medium that talks about it, but I'm sure you can find a lot on it around the web. To quote the writer:

It seems like a good alternative to the loading state since it re-enforces the content layout, hence it sets the user’s expectation of where things are right away (given that it mimics the actual content layout).

Placeholders are essentially loading bars, in the form of dummy content. It let's the user know something is coming, without causing odd jumping.

Medium itself does some very nice progressive image loading that could work as an excellent placeholder as well, but you didn't give any examples of the kind of content you are looking to display.

Answer 3

Really you shouldn't put this application on your home page. The home page serves as the entry page to your site, and users will need quick access to navigation. I would consider even ~1s load time too long for that.

If you still want to present the application on your front page, I would hide it behind a button where the user can consciously start loading it. You also might want to prevent scrolling during that period - fit all the relevant stuff on the screen, and expand the page downwards when the application is ready. You can also try to pre-load the data in the background, before the user hits the button. To let the heavy data processing not affect the snappiness, run it in a background process.

Answer 4

Your best bet is to render the page formalities and structure in a second or two (ethernet time, cell-data time will vary). And then, backfill the data as the data comes up.

Imagine if you reboot the starship Enterprise. There are dozens of displays. They don't all come up at the same time, they flit on, one at a time, depending on how long they take to do their thing. We consider that normal. Also, note that the Enterprise bridge does not spasmodically get larger as workstations insert themselves Harry Potter style between other workstations as they start up. The workstations are always there, just the screens (of fixed size) start filling with data. That's the design concept to go for.

Why?

Your user may not even want that data

It's easy to suffer tunnel vision, or "get-there-itis" as the aviators call it. You're presuming everyone who lands on the homepage wants the content you've done all the work on. Good chance not.

• Some want the "About us" page or "How this business/site works" page - they're not ready to convert, and a big computational load to present your wares is wasted.
• Others want directions to your site (think music theatre, they are late to this show, and don't care about ticket availablility for other shows.)
• Others have a question and want to find a way to contact you.
• Etc. etc. Those users are not unimportant.

It's rude to make them wait. It's also suicide to delay; because if the big DB crunch never finishes, that means your site is down. Same if the big DB crunch takes 7 seconds, but they abandon in 6.

You're supposed to reserve space

This new trend they call "skeleton UIs" where you reserve space for the loading content -- it is not a new thing. It's a very old thing, and a very mandatory thing.

The web was going quite strong in 1995 when most people had 33.6kbps modems. You see the img tag with its height= and width= attributes? They're not for scaling. The Internet lived or died off of those. That's what made your site usable within a sufferable amount of time. That's what put a gray box with a little "image" icon where your content goes. People were used to this, and really appreciated it. Many set their browser to "don't auto-load images" and clicked to see the ones they wanted.

This didn't render (yet)? No matter. The page could render, and it won't jump.

Mind you in 1995, it was possible to fail to specify height= and width= parameters, and you would indeed get the sad version of scroll jumping that was possible on a 486 (that's a CPU chip) without a VPU. This only happened on the cheesiest amateur home-cooked web sites. Anyone remember loading a friend's personal travelougue site and having to go get a coffee while his 100 images jerkily loaded?

So this concept of "Don't cause scroll jumping" is nothing new. Don't normalize failure to reserve space for loading content, it's always been a lazy and sloppy way to code.

And yes, that does present design challenges for dynamically loaded content. In fact, that's how that camel-of-indeterminate-size got its nose back in the tent. Lazy sites go "We can't know how large this tweet will be" (I'm gonna guess, less than 140 characters)... good design is working this out.

In the old days, we solved almost any problem like that with an iframe. So it's definitely possible.

Answer 5

Neither. Since it's the home page, you can assume that users will be going there often. So calculate everything in advance and cache it.

If it's a "live" page that needs to provide up-to-the-minute data every time it is loaded/refreshed, then cache the result from the previous request and use this as the initial page for the next request (if the page has a "last updated" field then include the time that the cached data was originally generated). Then the page can update the data using AJAX after it's loaded. The result is that users see the page load immediately with data that's probably not more than a few minutes out of date, then within a few seconds of the page loading the data's replaced with the up-to-date data. If the user mashes the refresh button, they'll never receive older data because the data from their previous query will be cached and returned the next time.

Also limit the number of AJAX requests that you're doing and perform most of the calculations on the server. This way the client can simply make one AJAX request that returns the entire data a few seconds later rather than overloading the user's computer and network connection with many AJAX requests and a lot of calculations. Plus if you perform the calculations server-side then you can cache the results (see previous paragraphs).

Answer 6

A common solution to this is displaying an incomplete page layout that gradually fills as the information becomes available. Unless the client machine is having to process the data itself, there is no reason why loading data on a background thread should slow down the UI.

Make sure all the buttons experienced users need are accessable from the start to increase productivity.