Let's figure out why it's needed and how to choose the optimal loading screen for your web product

Introduction

When you click on a link or enter an address into your browser, you've probably had to wait while the browser is idle. During this pause, the browser receives only the HTML file from the server and processes it line by line, downloading the files specified in it. And only after this operation is completed, it displays the page. There are many subtleties in this process, but there is no point in reprinting them, everything is already described before me. And the more complex the page, and the more content it contains, the longer you will have to wait for the browser to display the page.

If there is a long wait, some users will wait until it loads, while others may close the tab or write angry messages to support. And there is no panacea for this pause, but there are budget restrictions, tight deadlines and external technical factors.

However, loading screens help smooth out this situation, one might say, by deceiving the system. In order for the browser to display the page as quickly as possible, the server gives it the simplest possible HTML file, which contains only a loading screen and some JS script to load the page content after the page is displayed. If you are interested in finding out the details, then I bring to your attention this article. Interestingly, content can be requested not only in one “piece”, but also in parts, downloading them in parallel and displaying them as they are downloaded. And there is the concept of asynchrony, that is, parallelism with the main process without blocking it.

Requests to the server can be made at any time: during or after loading the page, automatically or during certain user actions, single or different. This is needed in approaches with pagination, “show more” buttons, lazy loading or list virtualization, where loading screens will again be useful.

It's never too early and never too late to think about implementing loading screens. At the design stage, you may already understand that you will have large amounts of data or that users will use the mobile Internet, or you may have doubts about the server component and peak loads. During the product development process there should be load testing. And after its launch, there is always the opportunity to collect analytical data. However, the best time to implement loading screens is during product design, so you don't have to rewrite scripts to prepare for asynchronous loading.

When and where are loading screens needed?

Long loading time is a subjective concept, but let's try it.

If your product pages take longer than 3 seconds to load, even intermittently, then you might want to consider loading screens. If you are worried that during fast loading, the loading screen will appear for a split second, unnerving users with such flickering, make a smooth animation of the appearance of the content – 350-500 milliseconds for the entire page and 250-350 for individual blocks is enough.

And be sure to understand the reasons for the long loading time in order to rationally use your product budget to optimize the development budget:

• the entire page takes a long time to load, for example, when the server is working at the limit of its capabilities or users have a slow Internet;

• only part of the page takes a long time to load, for example, large tables and long lists;

• single components slow down loading, such as statistics, which must be calculated in real time every time or when there is a dependence on third-party services with low performance.

Types of loading screens

If you search the Internet for examples of loading screens for web pages, you will find an endless number of design variations, but they fit into only three types.

Non-deterministic loading

This is simply a placeholder that covers the entire screen or loading area, like a drop-down list or loading block on a page. The simplest and most popular solution:

From a design point of view, the loading screen can look like anything, the main thing is that it is clear to the user that loading is in progress. To solve this problem, a “loading” sign or a looping animation may be enough; the second option clearly copes with its task better. The most popular solutions are spinners, abstract animations, animated logos or skeleton stylizations.

Technically, a non-deterministic loading screen is the simplest option, since it only requires implementing the ability to use loading screens and the design itself. You can place anything inside: native HTML + CSS, SVG with inline animation, Lottie or Canvas.

Deterministic loading

This is still the same plug, but technically complex. Due to the implementation features, a solution is rare.

The design of a deterministic loading screen is limited only by its task – to give the user information about the loading progress. It can be displayed in text format as a percentage, time, data volume or any other units, or graphically, playing an animation synchronously with the loading status, from 0 to 100 percent.

This loading screen is the same as a placeholder applied to the entire screen or area, but is also the most difficult to implement and reuse. The point is that you need to find out the list of files for a specific download, their total volume, and somehow monitor the progress of their download, while controlling the animation. All these processes are inconvenient and time-consuming.

Skeleton

It is a set of non-deterministic stubs that specifically cover unloaded data, reminiscent of the skeleton of the page visually and technically.

The peculiarity of skeletons is that they greet the user with the structure of the page, from the first seconds keeping them from closing the browser tab. Skeletons also allow you to load a page in parts, with several requests, providing access to functionality. For example, if navigation loads first, it will be available and the user will be able to move to another section. Skeletons also fit very well into lazy loading and virtualized lists.

In terms of design, it is customary to make gray tiles with wave or pulsating animation. The location, dimensions and shapes of these dies depend on the page design. It is important to emphasize that the canonical skeleton is placeholder dies instead of almost every component in the real layout, and not an abstract and content-independent placeholder.

Loading screen is average in complexity. Essentially, this is a non-deterministic loading screen, complicated by painstaking work to optimize the loading of resources and its repeated targeted use in the form of skeleton bones for almost every element on the page. It is displayed a fraction of a second later than others, as it contains page layout, but this is useful to users.

Alternatives to loading screens

If your product is something complex and takes a very long time to load, and you need a truly unique experience, then you should pay attention to the experience of other industries or try to cheat. In general, I’ll try to set a vector for your WebGL game, 3D editor or something else. I will give my thoughts outside, so to speak, the general standings.

Background

You can also download data in the background while the user is solving other problems. JS and caching, that is, saving files in the browser’s memory, do an excellent job of this.

For example, while a user selects a file from a directory to edit, editor resources can be loaded. Or a game location while customizing a game character.

Distracting

The user's attention can be diverted from the download process by giving access to something that will interest the user. The main thing is not to get carried away so that the download process does not become the reason for which the user uses your product.

As an example: during loading, you can offer users some kind of mini-game, like tic-tac-toe. Or show tips and tricks on functionality, both individually and give access to a whole reference book.

We can say that this approach is actively used in browser games, only instead of advice they place advertising.

Implementation in design

Before you start designing loading screens, be sure to understand the reasons for long loading times so that you can decide how to use loading screens, whether to cover the entire screen or just areas, and whether they will be needed in lists, tables, or individual elements like drop-down lists and graphs.

Be sure to discuss your ideas with the developers of the client and, just in case, the server components of the product. Both “sides” are especially important if you want to display loading progress. Understand whether your budget and product delivery deadlines allow you to implement loading screens.

If your product is not based on a modern JS framework, then be prepared for the fact that it is not always possible to quickly and easily implement even the simplest loading screen, and significant modifications to the code may be required.

Don’t be afraid to approach the developers and ask a lot of stupid questions, just ask them to tell you what and how it will work in simple words, clarify what you don’t understand. It is best to hold a meeting with the whole team. It's highly likely that such a story will give you new and better ideas for the loading screen, which will not only make the screen more aesthetically pleasing, but also easier to develop.

When choosing design and animation, think about what emotions you want to create in the user. Using skeletons as an example: slow and smooth pulsation is great for interfaces where users need to work slowly because the cost of error is high. While rushing waves are better suited to interfaces where work needs to be done quickly.

Don't forget about consistency in your product design. If you use skeletons to load a page, then a spinner in a drop-down list will be perceived unexpectedly and inconsistently. At the same time, a non-deterministic loader can be styled as a skeleton.

If necessary, you can combine different loading screens. For example, along with skeletons, a modest and unobtrusive progress bar would look good to show progress. And progress is very advantageously emphasized by the looping animation of non-deterministic loading.

Conclusions and comparison page of downloaders

To make it easier to choose a loading screen, I’ll try to put together a table and roughly evaluate each of the solutions according to a number of parameters. We will not consider an alternative, since they are too specific.

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