Related Question

Pros/cons of splash-screen with articifial loading delay

This is a fairly subjective question, but in my opinion most discussion on UX is at least a little subjective.

So basically I could choose a fast-loading splash screen that essentially displays an image to the user while the application loads, or a splash screen that takes 1-3 seconds to show up, but looks nicer and provides information to the user as to what piece of the application is currently loading up.

Currently, I am thinking a fast-loading splash screen is better, since in general, the user doesn't really care what part of the app is loading, only whether or not it is still loading.

  • Why do you need a splash screen? How does the splash screen help your users? Commented Feb 4, 2012 at 12:13

8 Answers 8


Good question.

As you stated, a very subjective one, however we're all users and our opinions all matter :)

In my opinion, no matter what application I'm running, I would rather see a loading screen come up immediately rather than wait 'X' seconds to see one. I'm a little curious as to why your delayed splash screen would be less flashy (is it because your framework requires loading assets/etc, which take time?)

In either case, if you can make a fairly presentable splash screen and show it immediately, I'd always go that route.

  • Certainly I can improve the design of the splash screen, but animations, text/icon updates, etc. would require loading the framework (.NET + WPF) first. There is another side to using a static image, though: it may well be the case that the manner in which the program loads changes, perhaps often. This necessitates a change to the splash screen, which I am currently thinking is more trouble than it is worth.
    – xofz
    Commented Aug 20, 2010 at 20:15
  • That is to say, it necessitates a change to the dynamic splash screen, not the static one. A static splash screen wouldn't have to change very much, if at all, when program updates occur.
    – xofz
    Commented Aug 20, 2010 at 20:16
  • 2
    This may be getting a little too technical, but a well programmed loading workflow would not have to change because another element was added to the list. It should just iterate through all the elements anonymously and execute them. That being said, I would still rather see something come up immediately while initial loading occurs (WPF, .Net, etc), then you could display a more well thought out dynamic loading screen with visual effects. Edit: Also, if the load time for your application is less than 5 or so seconds, I wouldn't bother with more than one load screen, and a static one will do
    – user708
    Commented Aug 20, 2010 at 21:49
  • WPF? See: olsonsoft.com/blogs/stefanolson/post/… Commented Aug 22, 2010 at 15:03
  • 2
    " we're all users " really? you have to remember: you are not your user.
    – hasen
    Commented Aug 27, 2010 at 11:02

Turn lemons into UX Lemonade. Use those 1-3 seconds to make your customer happy.

Fade on a pun, and then fade it away and show your app. The user will smile going into your app every time (assuming it wasn't repetitive).

  • I couldn't quite remember how to throw a boomerang, but eventually it came back to me.
  • I was going to look for my missing watch, but I could never find the time.
  • I couldn't afford cotton, so I decided to steal wool.

Every second is a chance to delight your user.


How about no splash screen?

Splash screens are annoying. They embody the "I'm the most important program here" mentality (hey, look at me, I'm loading, yay!).

If you must make a splash screen, please please pretty please:

  • Don't make it obstruct other windows that have focus.
  • Make it simple and elegant and lite.

If your splash screen appears after 2 seconds, when is the main window going to show up? After 10 seconds?

  • I disagree here. For some apps (Eclipse, I'm lookin' right at ya), loading actually can take >30 seconds. Heck for a "Hello World" WPF app, you have about 5 seconds worth of JIT, etc. If the app doesn't appear within 2 seconds, a splash screen should. But +1 for the "don't make it obstruct other windows" Commented Aug 22, 2010 at 14:43
  • 1
    in that case it's better to fix the app my making it load faster.
    – hasen
    Commented Aug 23, 2010 at 23:57
  • Good luck with that if you are using something like .NET or Java. Commented Aug 25, 2010 at 21:01
  • 1
    I don't heavily use .NET, so I don't know. But I'd say, if your choice of technology makes your program so slow as to take 30 seconds to load, then maybe you should consider using something else.
    – hasen
    Commented Aug 26, 2010 at 11:17
  • Initial cold start of the .NET framework can take a second or so - note that they cut this by 40% with 3.5 SP1. Apps that take much longer than this are often creating expensive resources (especially database, app server connections) up front and synchronously, forcing the user to wait. While there are ways to make fix these issues, sometimes the money (labour) is better spent elsewhere.
    – Bevan
    Commented Nov 7, 2010 at 19:50

Is it possible to have a fast, static splash screen be displayed for 1-3 seconds with the word 'loading...', followed by the more informative but slow loading splash screen with a progress bar?

Best of both worlds - quick response initially followed by more detailed information.

  • The benefit of displaying something while the app is loading is that something is happening, convincing the user that the device isn't frozen. A static splash page still looks static, and if the device takes any longer than normal to load what comes after, it risks reducing user experience.
    – Matthew
    Commented Aug 21, 2010 at 20:54

You should almost certainly use the fast splash load screen:

I've seen users click on an icon multiple times due to lack of response too many times to count. This almost invariably opens multiple copies of the application. If forced to choose I'd say go for the fast loading splash if the 'slow' splash with progress takes more than it takes for the person to notice the system is being irresponsive. On a really cool note this will never be faster than human reaction time (approx. 190ms).

The only reason I say 'almost' certainly is in case your app takes long enough to be seen as irresponsive after the splash screen has loaded up and the person may begin to question if your app has crashed.

Ideally I'd use both but if you need to choose between the two for some reason I'd go with the fast splash screen unless the main app takes longer than 5 seconds to load when you should go for the progress bar.

Hope this helps.


The point of either is to give some feedback to the user, to keep them entertained/informed/engaged during a long running process. That is the approach you should use. Not "which is better", but "which is more appropriate for my particular scenario".


Fast loading - ALWAYS!

Users don't like to wait for anything. If you are going to use a splash screen make it load fast and be relevant to the user's purpose of being on the site.


Sounds like the splash screen needs a splash screen. You could make a smooth transition between the two, and it might work out fine.

But you are right about that the user generally does not care. Personally, I would never make a that informative splash screen. If I had time and resources to make a splash screen informative, I would rather put that into other more valuable features, or optimizing startup.

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