Loading

Loading strategies assure users that their request is in progress and can create the illusion of shorter load times in apps. According to research conducted by the Nielsen Norman Group, skeleton states and other loading indicators improve user satisfaction.

In this pattern, we will look at skeleton states, loading indicators, and progressive loading.

Skeleton states are simplified versions of components used on an initial page load to indicate that the information on the page has not fully loaded yet. They should only appear for only a few seconds, disappearing once components and content populate the page.

Skeleton states use motion to convey that the page is not stuck and that data is still being loaded. This can help to reduce user uncertainty.

Only use skeleton states on container-based components like tiles and structured lists or data-based components like data tables and cards. In most cases, action components (e.g. buttons, input fields, checkboxes, toggles) do not need to have a skeleton state.

Never represent toast notifications, overflow menus, dropdown items, modals, and loaders with skeleton states. Elements inside a modal may have a skeleton state, but the modal itself should not.

Loading indicators signal a user action is processing. Unlike progress bars, loading indicators only signal that loading is occurring and do not give any indication of progress. If a process will take more than a moment or two to complete, use a progress indicator instead.

Full-screen loading indicators tell a user the entire application is processing, while inline indicators show that a specific selection or action is processing.

The loading component should be used when the entire page is processing. This is often applied after data is submitted or saved by the user.

If the process is going to take more than a few minutes, consider including a notification.

Use the inline loading component when a single component is processing. For example, when an administrator invites a user, an inline loading component indicates the system is processing the invite request.

Progressive loading is a technique that loads pages in batches. The simplest view of the page loads first, followed by progressively more detailed batches until the entire viewport has loaded.

The primary batch should show a page’s basic structure (the skeleton state versions of the container-based components), data-based text (the skeleton state version of text) and non-data text. Following batches can include images, content outside of the viewport, interactive (action-based) components, and data-based text.

Not all items need a skeleton state and instead can be expressed as negative or white space until they load. For example, a 600 x 600px image can be shown as a 600 x 600px area of white space until the full image loads.

A Load more option can be used to extend a list where only a small fraction of options are displayed. It can also be used in cases where the list of options is populated via a database. Using Load more allows the data to load in progressive batches.

A screen reader should notify a user if an application is loading, busy, gets stuck, or if a process fails.

For specific loading accessibility concerns, see the WCAG documentation for Notification of Loading/Busy and adhere to accessibility guidelines for the loading component.

Help us improve this pattern by providing feedback, asking questions, and leaving any other comments on GitHub.