Should I use a loading state, and if so, what kind?

Question

My scenario is that I have a menu that loads pages on my SPA when an item is clicked. Right now it is rather fast (.1s with cache and ~.3s when not cached). However I expect this time to rise in production, specially in cases when the users's internet speed is slow. This is my page as is:

Highlighted in orange is the space where the pages are loaded. I wonder if I should use a loading state, which I'm very inclined to base on the heuristic of system status. However, which one? I don't want to implement a complex loading state if not necessary. Luke Wrobleski wrote an article back in 2013 about avoiding spinners and the usage of skeleton Pages, which are now most everywhere. Bill Chung performed research on user experience comaring spinners and with skeleton pages (see in Everything you need to know about skeleton screens).

I will most certainly use skeletons for the individual components of the page that has data fetching. However, is it too overkill for this idle time between a user clicking a link to a page and it being loaded? If so, what's the best approach? I'm overthinking this too much and maybe a simple spinner would do the trick without impacting the user?

Answer 1

Occupy the user with a transition animation, like fading out contents. This will distract users from the waiting and provide you some magical 200 ms more to finish the actual content loading.

Showing a spinner focusses the user on the waiting, which will lead to the delay being perceived longer, hence the app being perceived slower.

You will still need a loading indicator, in case it really takes longer, to visualise system status. But you can show it after the old content faded out and the new one is still not ready.

A good practice during longer loading periods is to provide tips on the app usage.

See also How can I distract / entertain people in an app while waiting?

Answer 2

Use loading indicators where dynamic content is loaded

Keep your "page furniture" cached or otherwise in a state where it doesn't need to be loaded every time the page paints. Then, use loaders (spinners, skeletons, whatever works best) for the dynamic content that's being retrieved. An example from Twitter shows loaders only on the content that needs to be retrieved:

Your point about the user's internet speed is right on - they might be having wifi issues that day. A loading indicator helps them understand that the system is trying to retrieve content, but there's something hindering it. Without the indicator, the user might think their browser is frozen.

Answer 3

In our work, we use spinners quite a lot. It is definitely better than not having any loading indicators. We have seen from our actual user data that, where we expected quick loading times, but something went wrong, and there were no indicators of something happening the users just refreshed the page to make the issue even worse in the end. So at least a spinner or something of a higher grade is definitely a must.