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.

  • 51
    Regardless which direction you go, both are very user unfriendly. Either you frustrate people with jumping content or you test their patience and make them wait. Are there ways you can optimize your content or cut the content into bits and display them when it's needed? Commented Nov 7, 2017 at 11:52
  • 16
    I hate loading screens and usually switch away to another tab. Whatever you do make sure that it keeps loading if the users switches tabs, nothing is worse to wait a minute in other tab to discover that you have to watch the load after all.
    – Džuris
    Commented Nov 7, 2017 at 16:42
  • 47
    Background AJAX-Calls do not slow down page scrolling - no matter how long slow requests take, you should be able to outsource heavy loads to background-tasks or promises and process them in small chunks (with service-worker or promises) so the user-experience does not slow down. I know internal pages which load millions of rows and take several seconds without much impact to the UI-Thread
    – Falco
    Commented Nov 7, 2017 at 16:53
  • 12
    Since this is a UX-Question I post this as a comment: Do browser-JS Profiling. My best guess is you are doing a lot of incremental work on the DOM inserting or moving a lot of nodes, or you do a lot of blocking operations on the foreground JS-process - both are not best practice and can usually be optimized. For DOM-Elements you could create a virtual DOM and insert your nodes in a single operation once the loading is done, or similar techniques
    – Falco
    Commented Nov 7, 2017 at 16:57
  • 7
    To add on @Falco's comment, what slows down the UI is rendering after you AJAX calls return. If you want to improve interaction with the page during rendering, try to render in small chunks and add small timeouts (10-20ms) between each chunk. The total rendering time will be bigger but you won't be blocking the UI thread to much, which is what creates the laggy UX. Commented Nov 8, 2017 at 9:50

6 Answers 6


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!

  • 1
    I have considered both the loading bar options, and think a lightbox over the page would be better, as it clearly blocks the page. A loading bar above the page content would still allow the user to use the page, and it may not be 100% obvious to some users that the slow page and the loading bar are connected.
    – R2D2
    Commented Nov 7, 2017 at 11:39
  • 2
    I guess you could hide the content until it fully calculates? Also: the lightbox can be closed by the user at any time, of course, if s/he chooses
    – colmcq
    Commented Nov 7, 2017 at 11:41
  • 2
    Indeed - giving them the choice: wait and watch this loading bar, or close this message, but expect a laggy page!
    – R2D2
    Commented Nov 7, 2017 at 12:31
  • 2
    @Mast: I agree that laggy user experience is poor - so why would you consider adding a deliberate 10 second lag (which is what the progress bar effectively is)?
    – psmears
    Commented Nov 7, 2017 at 13:58
  • 3
    @Mast: Nonsense - even on a data-heavy page, it's possible for the item I want to interact with to be at the top of the page. And indeed, with a well-designed UI, the data I want to see will always be the most visible. What's more, if the page is truly data-heavy, I may just want to look at the data (no interaction, no scrolling etc) - so showing a progress bar that blocks my view of the data slows me down for literally no gain.
    – psmears
    Commented Nov 7, 2017 at 15:26

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.

enter image description here

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.

  • 10
    @jane fully agree. Skeleton may even be latest calculated data stored in LocalStorage (with the proper formatting to show it's out of date) Commented Nov 7, 2017 at 14:29
  • 7
    Nice, especially if the placeholder will have the same size/position as the final content. I don't mind slow-loading pages that much (especially if there's some indication that is IS loading), but having things jump around on the screen as the browser frantically tries to redraw to fit in each new element is really, really annoying.
    – jamesqf
    Commented Nov 7, 2017 at 17:24
  • 8
    Oh, that is what they are for. Whenever I see then I've think something messed up and hit reload
    – PlasmaHH
    Commented Nov 7, 2017 at 18:52
  • 12
    I find the way it works in Facebook incredibly stupid. Async content loading increases the time before content becomes available for user (the skeleton had to load before it would be able to send requests to load content that is actually interesting to the user). And error handling is poor even in Facebook: if something bad happens you end up with a skeleton page with animated placeholders that are just GIFs and not a real indication of loading progress. If FB can't make it right, I don't expect average Joe Webdeveloper to do it right either.
    – n0rd
    Commented Nov 7, 2017 at 19:42
  • 5
    The screenshot looks similar to facebook... The solution smells of react, laggy and buggy.
    – Džuris
    Commented Nov 7, 2017 at 21:38

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.

  • 7
    +1 if it fits the platform. Pinterest's sole purpose is the posts/pins so their homepage is instantly filled with pins, why create a homepage for a platform with one purpose?
    – Summer
    Commented Nov 7, 2017 at 13:36
  • 3
    @JaneDoe1337 Yes, there surely are exceptions to the rule. I wasn't sure whether it's a more traditional webpage that includes a data-heavy "showcase", or more a kind of web application that is primarily visited by registered users.
    – Bergi
    Commented Nov 7, 2017 at 13:49

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.


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.

enter image description here

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.

  • 1
    Exactly this. You don't know if a specific user wants the content you worry about. Make sure the page is usable and "nice" while its loading. Perhaps even go for "best of both worlds" - a usable page and a loading bar in the slot where this specific content will go when it's loaded, for this specific content. As an aside, can you crunch the data periodically on the server so the user web page can download a precrunched version quickly, plus if needed an "(updating in the background" tag?
    – Stilez
    Commented Nov 9, 2017 at 11:28
  • "precrunching" seems very doable if this actually shows up on a page before login.
    – PeterL
    Commented Nov 10, 2017 at 23:37

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


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.

  • the trouble here is that the user might try to interact with some of the data (like I frequently do!)
    – colmcq
    Commented Nov 7, 2017 at 16:54
  • 1
    There's nothing to stop them doing that. Clicking on the data to enlarge it or whatever should still be possible. A progress bar on the data might be appropriate if it is long enough to warrant it.
    – David
    Commented Nov 7, 2017 at 16:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.