Why You Need a Loading Screen and How to Choose the Best One for Your Web Product

My name is Anton, and I am a designer of B2B products at X5 Tech. I love my job and strive to build feasible interfaces, which is why I’m constantly delving into technical details.

I’ve often needed to create loading screens for the web products I’ve worked on. I’d like to share my experiences, observations, and thoughts on this topic with you. In this article, I will be covering the technical aspects and providing a classification of loading screens, and I hope this will help you choose the best option for your product.

Introduction

When tapping on a link or entering a site address in your web browser, you can surely recall those moments when you had to wait before the page opened. While the browser seems inactive during these delays, it is actually performing several tasks: first, it receives the HTML file from the server, then it parses it line by line, downloading any additional web resources specified in the HTML.

Only after all these files are downloaded does the browser display the page. There are many intricacies in this process, but there’s no point in listing them all here, as they have already been thoroughly documented. The more complex the page and the more content it contains, the longer you’ll have to wait before the browser displays it.

During long waits, some users will patiently wait for the page to load, while others might close the tab or send angry messages to tech support. There is no universal remedy for this page-loading delay; moreover, there might be budget constraints, tight deadlines, and other external technical factors to consider.

However, this problem can be alleviated with loading screens, which basically trick the system. The concept is simple: to make the browser display the page more quickly, the server first provides a minimalistic HTML file containing only the loading screen and a JS-script that loads the full page content after the loading screen is displayed.

Interestingly, the page content can be requested not all at once, but in chunks, allowing for parallel downloads and displaying content as each part is received. Besides, there’s the concept of asynchronous operations, which means performing tasks in parallel with the main process without blocking it.

Requests to the server can be made at any time: during or after page loading, automatically or in response to specific user actions, either individually or in other ways. This can be particularly useful in various scenarios, such as pagination, “load more” buttons, lazy loading or list virtualization, where loading screens can again be quite helpful.

It’s never too early or too late to consider implementing loading screens. During the design phase, you may already anticipate handling large volumes of data, users relying on mobile internet, or concerns about server performance and peak loads. Load testing should be conducted during product development, and after launch, there’s always the opportunity to gather analytical data. However, the best time to implement loading screens is during the design phase, so you don’t have to rewrite scripts for asynchronous loading later on.

When and Where Loading Screens Are Needed

It’s difficult to establish what constitutes a long loading time since it is quite an individual matter, but let’s give it a try.

If your pages take longer than 3 seconds to load, even occasionally, it might be worth considering loading screens. If you worry that fast load times will cause the loading screen to flash for a fraction of a second, irritating users, then opt for smooth content appearance animations — 350–500 milliseconds for the whole page and 250–350 milliseconds for individual blocks should be sufficient.

Don’t forget to identify the root causes of long loading times — this will help you efficiently allocate your product development budget:

• The long loading time for the entire page is usually attributed to servers reaching their performance limits or slow internet connection at the user’s side.
• Hiccups with loading certain part of the page can be related to heavy tables or long lists.
• Sometimes it’s individual components that hinder loading your page, like statistics that need to be calculated in real-time, or dependencies on third-party services with low performance.

Types of Loading Screens

If you search online for examples of loading screens for web pages, you’ll find countless design variations. However, they generally fall into three main types.

Nondeterministic Loading

In this case it’s essentially a placeholder that covers the entire screen or the loading area, such as a dropdown list or a loading block on the page. It’s the simplest and most commonly used solution:

From a design perspective, the loading screen can look any way you choose, as long as it clearly communicates to the user that something is loading. A simple “loading” message might suffice, but a looping animation is generally more effective. The most popular solutions are spinners, abstract animations, animated logos, or skeleton screens.

When it comes to technical implementation, a nondeterministic loading screen is the simplest option, as it only requires setting up the loading screen functionality and its design. You can use a variety of elements inside, including native HTML + CSS, SVG with inline animations, Lottie, or Canvas.

Deterministic Loading

This is still a type of placeholder, but it is technically more complex. Due to its implementation specifics, it is a less common solution.

The design of a deterministic loading screen is restricted solely to its primary function: providing the user with information about the loading progress. It can be displayed in a text format — such as percentage, remaining time, or data left — or graphically, with an animation that synchronizes with the loading status from 0 to 100 percent.

This type of loading screen is essentially the same placeholder that covers the entire screen or a specific area, but it is the most complex to implement and reuse. This is because it requires identifying the list of files for a particular load, their data size, and somehow tracking their loading progress while managing the animation. All these processes are cumbersome and labor-intensive.

Skeleton Screens

Skeleton screens consist of multiple nondeterministic placeholders that selectively cover the areas where data has not yet loaded, visually and technically resembling the skeleton of the page.

The unique feature of skeleton screens is that they present the user with the page’s future structure right away, which helps to keep the users from closing the browser tab. Skeleton screens also allow to load the page in parts through multiple requests, providing access to functionality as it becomes available. For instance, if the navigation loads first, users can start navigating to other sections. Additionally, skeleton screens fit seamlessly with lazy loading and virtualized lists.

In terms of design, it’s common to use gray placeholders with wave or pulsing animations. The placement, size, and shapes of these placeholders depend on the page design. It’s important to emphasize that a canonical skeleton screen assumes placeholders for nearly every component in the actual layout, rather than a single, abstract, content-independent placeholder.

Moderately Complex Loading Screens

Essentially, this is a nondeterministic loading screen that has been enhanced through meticulous optimization of resource loading and the repeated use of placeholder elements as if they are skeleton bones, for almost every element on the page. It becomes visible to the user slightly later than other types of loading screens, since it provides the page layout, which improves usability.

Alternatives to Loading Screens

If the product you are designing is complex, with very long loading times, and you want to create a truly unique experience, consider the best practices from other industries or try employing some clever tricks. Here, I’ll try to provide some direction if you are working on a WebGL game, 3D editor, or something similar. I’ll share my thoughts, so to speak, outside the usual framework.

Background Loading

Data can also be loaded in the background while the user is occupied with other tasks. JavaScript and caching, i.e. saving files in the browser’s memory, will help you implement this approach.

For example, while the user is selecting a file from a catalog to edit, you can load the editor’s resources. Similarly, you can load a game level while the user is customizing their game character.

Engaging Distractions

You can divert the users’ attention from the loading process by providing access to something interesting. The key is not to overdo it, so that the loading process doesn’t become the main reason the user engages with your product.

As an example, during the loading process, you can offer your users a mini-game, like tic-tac-toe. Alternatively, you can display some tips and tricks about the functionality of your product — either one at a time, or by providing access to the entire help guide.

Basically, this approach is widely used in browser games, but with ads instead of tips and tricks.

Design Implementation

Before getting hands dirty in designing the loading screens, first, it is important to understand the root causes of long loading times. This understanding will guide your decisions on how to implement loading screens — whether to use them for the entire screen or just for specific areas, and if they are needed for lists, tables, or individual elements such as dropdowns and charts.

It’s important that you discuss your ideas with both client-side developers and, to be on the safe side, server-side developers as well. Both components are crucial, especially if you want to visualize the loading progress. Additionally, check if implementing these loading screens fits within your budget and won’t impact your deadlines.

If your product isn’t built on a modern JavaScript framework, be prepared that implementing even a simple loading screen may not be quick or straightforward and could require significant code adjustments.

Don’t hesitate to approach developers and ask as many questions as needed. Just ask them to explain how things will work in simple terms and clarify anything you don’t understand. It’s best to have a meeting with the entire team. Such discussions are likely to provide you with new and better ideas for the loading screen, which can make it not only more aesthetically pleasing but also more developer-friendly.

When choosing design and animation, consider those emotions that you want to evoke in your users. For example, with skeleton screens, a slow and smooth pulsing effect is ideal for interfaces where users need to proceed cautiously because mistakes can have significant consequences. In contrast, rapidly moving waves are better suited for interfaces where tasks need to be completed quickly.

Don’t forget about consistency in your product’s design. If you use skeleton screens for page loading, having a spinner in a dropdown menu may seem unexpected, inconsistent and out of place. Meanwhile, a nondeterministic loader screen can be implemented in such a way that mimics the skeleton design.

If necessary, you can combine different types of loading screens. For example, a simple and unobtrusive progress bar can serve as an excellent complement to skeleton screens by indicating progress. Alternatively, the loading progress can be highlighted with the looping animations of nondeterministic loaders.

Conclusions and Comparative Summary of Loaders

To simplify the selection of a loading screen, I have compiled a table providing the general assessment of each solution based on various parameters. Alternative options will not be considered, as they are too niche.

Thank you for reading the article to the end. I hope you found it both interesting and useful. I look forward to your comments and/or questions.