Should a Website Use a Preloader Loading Screen?

In this guide, Talha Aslan and team explain how we make the preloader decision step by step. First, we look at how a full screen loading screen affects speed metrics. Then we cover when it is acceptable, what to use instead and how to respect the reduced motion preference. At the end, you will find a checklist you can apply to your own site.

What exactly is a preloader, and why did it become so common?

A preloader is also called a loading screen, a splash screen or an intro animation. When a visitor opens the page, they see a logo, a spinning ring or a percentage counter. The page only appears once this layer disappears. Technically, it is usually a layer that sits on top of the page and hides itself after a certain event.

Templates are the main reason it spread. Many ready made themes offer a preloader as a feature you can switch on with one click. As a result, site owners believe they gain an elegant branded moment on arrival. However, that moment delays what the visitor actually came for. So a preloader looks like a visual choice, but it is really a performance and usability decision.

• Spinning ring or dots: The most common type, a waiting signal with no content.
• Logo animation: An intro scene where the brand logo fades in and out.
• Percentage counter: A counter from 0 to 100 that often does not track real progress.
• Curtain effect: A solid color that slides aside to reveal the page.

How does a preloader affect perceived speed?

Perceived speed is how fast a visitor feels the page is. Measured time and felt time are not the same thing. For example, the headline and text may arrive in half a second. If a preloader hides them for two seconds, the visitor feels they waited two seconds.

Nielsen Norman Group describes three limits in its article on response times. A delay of 0.1 seconds feels instant, and 1 second keeps the flow of thought intact. Around 10 seconds is the limit of attention. In this framework, progress indicators belong to long waits. Showing a full screen animation during a short load makes the wait visible. In other words, it highlights the problem instead of solving it.

Moreover, a preloader usually stops the page from appearing piece by piece. Yet once a visitor starts reading the headline, they forget they are waiting. That is why we always value showing content early over distracting people with animation.

Also, the visitor's mind is not idle during the wait. They start asking whether the site works at all. If content arrives in pieces, that question never comes up, because the page shows it is responding from the first moment.

How does a preloader affect the LCP metric?

LCP (Largest Contentful Paint) is the moment the largest content element in the viewport is rendered. In its LCP guide, web.dev recommends 2.5 seconds or less for a good experience. It also explains that you should assess this at the 75th percentile of page loads.

The same guide notes that Chromium does not treat elements with an opacity of 0 as LCP candidates, because users cannot see them. It also treats elements that cover the full viewport as background rather than content. Therefore, the headline and image behind a preloader cannot become LCP candidates until the layer goes away. As a result, LCP shifts to the end of the animation, even if the browser downloaded the content long before.

If you want the full breakdown of LCP and how to improve it, read our guide to LCP optimization. Here, we focus only on its link with preloaders.

Does a preloader touch the other Core Web Vitals too?

Yes, it can, indirectly. Besides LCP, Core Web Vitals include INP (interaction responsiveness) and CLS (layout shift). We covered the general framework in our Core Web Vitals guide. Here, we only list where these metrics overlap with a preloader.

• INP: If the preloader script keeps the main thread busy, the first clicks may lag.
• CLS: If fonts or image sizes settle as the layer lifts, the page may jump.
• Total workload: An animation library adds extra code and extra downloads.

For example, a visitor taps the menu right after the layer lifts while the animation library is still running. The menu then opens late. The visitor reads this as a frozen site and taps the same button again and again.

In short, a preloader is not just a one second visual effect. It means extra code, extra painting and delayed content. The cost becomes clearer once you factor in how JavaScript affects site speed.

Does a preloader increase bounce rate?

Giving a precise percentage would be misleading, because every site has a different audience and traffic mix. Still, the logic is clear. When visitors see a waiting screen instead of content, their patience runs out sooner. On mobile and on weak connections, the back button is always one tap away.

Example scenario: a visitor arrives from an ad and sees a spinning logo instead of the product page. The logo spins for three seconds. The visitor cannot tell whether the site has crashed or is loading. That uncertainty means some of the ad budget goes to clicks that never see any content.

We collected other ways to keep visitors on the page in our article on how to reduce bounce rate on a business website.

What is the difference between a preloader and progressive loading?

Progressive loading means showing the ready part of the page right away and adding the rest as it arrives. A preloader does the opposite. It shows nothing until everything is ready. The table below compares both approaches with the skeleton screen that sits in between.

As the table shows, progressive loading is the right default for a typical site. On the other hand, a skeleton screen is a good middle ground for sections that wait for data.

Example scenario: on a service page, the headline and short intro come ready from the server, while reviews load from a separate source. With progressive loading, the visitor reads the headline at once and the reviews settle in a moment later. With a preloader, the visitor sees nothing until the reviews arrive. So the slowest piece sets the speed of the whole page.

Can a skeleton screen replace a preloader?

In most cases yes, but only for the relevant section. A skeleton screen shows the page layout with gray boxes where content will appear. The visitor understands what the page will look like, so the wait feels shorter. Also, if the boxes match the real sizes, the page does not shift when content arrives.

However, spreading a skeleton across the whole page is just a preloader in a different costume. Parts that arrive ready from the server, such as the headline, body text and menu, should appear directly. We explain correct use, common mistakes and design details in our article what is a skeleton screen.

A skeleton screen also has a time limit. If the outline boxes stay on screen for long, visitors read them as just another waiting screen. That is why we recommend using them only for sections that truly wait for data, and only briefly.

When is a preloader acceptable?

We are not saying a preloader is always wrong. In some products, nothing can happen until a large amount of resources has downloaded. In such cases, an honest progress indicator beats an empty screen that looks frozen.

• Browser games: The game cannot start before textures, sound and level files download.
• Heavy web apps: Design tools, 3D configurators and map based dashboards.
• App shell after login: The moment a signed in user waits for dashboard data.
• Large file tasks: Jobs that truly take time, such as video conversion or uploads.

The common thread is simple. In these cases, the content is not the page itself but an application that has to download. A company page, a blog post or a product page does not belong in this group.

Even here, you do not have to hide the entire interface behind a single waiting screen. In a design tool, for instance, you can show the menu and an empty canvas first, then download heavy modules in the background. The user starts getting ready, and the wait feels shorter.

How do you design an acceptable preloader, and which rules apply?

Even when a preloader is truly needed, a few rules improve the experience a lot. Our team uses these rules as a design check.

1. Show real progress and avoid fake percentage counters.
2. Close the layer as soon as loading ends, without waiting for the animation.
3. Do not set a minimum display time that punishes users on fast connections.
4. Say in words what you are loading, for example game files.
5. Offer a way to cancel or go back during long tasks.
6. Always respect the reduced motion preference.

The 10 second limit from Nielsen Norman Group is a useful reference here. When a wait approaches that length, showing a percentage or a step tells users they are still in control. Also, a short tip that people can read during the wait makes the time feel more meaningful.

Why is a preloader so often a symptom of a slow site?

The pattern we see most often in the field goes like this. A site loads slowly, so someone adds a loading screen to hide it. The visitor then sees a neat animation instead of a half loaded, broken looking page. However, this approach does not solve the problem. It only moves it somewhere else.

The root causes are usually familiar. Think of large uncompressed images, many plugins running on load, a slow server response and unnecessary font files. Once you fix these, the page opens fast on its own. Therefore, the moment you feel you need a preloader is really the moment you need a performance audit.

That is why, when a client asks for a preloader, we first ask a simple question. Why does the page need a wait at all? The answer is usually about technical setup, not design.

How do mobile users experience a preloader?

When you test on a desktop with a fast connection, the preloader often flashes by in the blink of an eye. As a result, teams miss the problem. Yet a large share of visitors arrives on phones with variable mobile connections.

On a phone, the script that runs the animation takes longer on a weaker processor. In addition, resources download more slowly on a weak connection. As a result, a one second intro on desktop can turn into a waiting screen of several seconds on a phone.

• Slower processor: Animations and scripts run longer.
• Variable connection: Download times are unpredictable.
• Small screen: A full screen layer covers the entire view and leaves no way out.
• Low patience: On a phone, the back button is always one tap away.

For this reason, we recommend always testing the preloader decision with a slow mobile profile.

Why does a fake percentage counter hurt trust?

In many themes, the percentage counter does not measure real downloads. It simply counts from zero to a hundred over a fixed time. Visitors notice this quickly. Sometimes the counter stalls at 99 percent, and sometimes it keeps counting while content is already ready.

This creates a small but real loss of trust. The visitor feels the site is not telling the truth. On the other hand, a bar that reflects real progress makes the wait meaningful and honestly shows how much is left.

For example, in a truly long load such as a game, a bar based on the number or size of downloaded files helps people stay patient. In short, if you use a progress indicator, either tie it to real data or drop it. For an uncertain wait, a plain status message is always more honest than an invented percentage.

Why does the reduced motion preference matter for a preloader?

Some users turn on the reduce motion setting in their operating system. The reasons can be real discomfort, such as dizziness, nausea or distraction. Browsers pass this preference to websites through a media query called prefers-reduced-motion.

In its explanation of WCAG 2.3.3 Animation from Interactions, W3C lists this query among the sufficient techniques. This criterion sits at level AAA, so it is not the mandatory minimum. Still, we recommend treating it as a sound design principle.

In practice, our approach is simple. If reduced motion is on, we turn off spinning and sliding animations and show a static message or a plain progress bar instead. The user still gets information, but the disturbing motion is gone.

Also, do not limit the reduced motion preference to the preloader. Page transitions, sliding images and parallax effects can bother the same users. So tying the preference to your site wide animation rules gives a more consistent result.

Does a preloader carry any other WCAG risk?

Yes. WCAG 2.2.2 Pause, Stop, Hide covers moving content that starts automatically, lasts more than five seconds and appears alongside other content. For such content, users need a way to pause or stop it. This criterion sits at level A. You can read the details on the W3C explanation page.

A short preloader usually stays below this limit. On the other hand, things can change when the animation drags on over a slow connection. Also, a visitor who uses a screen reader cannot see the visual animation, so you need to announce the waiting state in text. For the broader framework, see our guide to web accessibility and WCAG.

What should you put on your site instead of a preloader?

The real goal is not just removing the preloader but making the wait unnecessary. When we take over a site, we first find out why the page appears late. The animation is usually a curtain over slowness.

• Send critical content first: Let the headline, body text and first image arrive ready from the server.
• Size images correctly: Compress the main image in the viewport and serve it at the right dimensions.
• Defer what is off screen: Use lazy loading for images further down the page.
• Trim unneeded scripts: Move code that does not need to run on load to later.
• Plan your fonts: Make sure text stays visible while fonts load.

We explain where lazy loading helps and where it hurts in our lazy loading guide. After these steps, the page already feels fast, and the need for a preloader simply disappears.

Example scenario: on a company site, the hero image weighs several megabytes and five separate plugins run on load. Once you compress the image to the right size and turn off unneeded plugins, the page speeds up noticeably. At that point, the preloader is only an unnecessary delay.

Will removing the preloader break how your site looks?

Usually not. In some themes, however, the preloader hides layout problems underneath. For example, if a font loads late and the text jumps, that jump is easy to hide behind the curtain. Once the curtain lifts, the problem shows up.

So after you remove the preloader, always check the page by eye on mobile and on a slow connection. If you see shifting, treat it as layout shift; our guide to fixing CLS helps at this step. You can also use our mobile friendly test tool to quickly see how the page looks on a small screen.

If layout issues have piled up behind your preloader, rebuilding this part properly is often the shortest path. As part of our web design service, we rebuild the first view so that content comes first. You can request a quote through the form on the service page.

How can you tell if your site has a preloader?

Sometimes site owners do not even know a preloader is active. It is a leftover from the theme setup. A quick check tells you.

1. Open the page in a private window and watch the first seconds.
2. In the browser developer tools, throttle the network to a slow mobile profile.
3. Reload the page. If you see a logo, a ring or a solid color before content, you have a preloader.
4. Look for a loading screen option in the theme or page builder settings.
5. Check when the LCP element is painted in the performance report.

Example scenario: in a ready made theme, the content may be ready in half a second, yet the theme still shows the loading screen for at least a second and a half. In that case, simply turning the setting off makes a clear difference.

The page source can also give you a hint. Most page builders give the loading layer a recognizable class name. If you are not sure, ask your developer which setting turns this screen on.

Does a preloader directly affect SEO?

Google considers page experience in its ranking systems, but it does not describe it as a single decisive signal. So a preloader alone will not push your site down. Still, if it delays LCP and drives visitors away early, it weakens both your metrics and your conversions.

Also, search engines can read content from the HTML. In that sense, the text behind the curtain is usually still readable. Things get complicated, however, when content only appears after a script runs. In short, the real SEO risk is not the preloader itself but the late, script dependent content structure that often comes with it. We covered the role of speed in rankings more broadly in how site speed affects SEO.

You can read Google's general approach in the Search Central page experience documentation. It stresses that good page experience is not limited to a single metric and that content quality comes first.

How should you decide on a preloader for online stores and company sites?

For these two site types, our answer is almost always the same: no preloader. Visitors come to see a product or a service, not to watch a brand animation. In ad traffic especially, every second of waiting raises the risk that a click you paid for goes to waste.

Instead, we deliver the brand feel through the page itself. A clear headline at the top, a carefully chosen image and consistent colors leave a stronger first impression than any intro animation. Moreover, that impression forms without making anyone wait.

If you want a soft touch on page transitions, choose a small and quick transition instead of a full screen layer. That way you keep the brand feel and never hide content.

In addition, online store visitors usually browse several pages. A loading screen that reappears on every page change becomes an obstacle that keeps interrupting the shopping. That is why we recommend turning off the preloader completely on category and product pages.

Which questions should guide your preloader decision?

The questions below make the decision easier. If most answers are no, you do not need a preloader.

• Does the page need to download a large application before the user can do anything?
• Does the wait really exceed a few seconds?
• Can we measure and show real progress?
• Is showing partial content impossible?
• Is a plain version ready for users who prefer reduced motion?

For a browser game, for instance, you will say yes to most of these. On the other hand, for a dental clinic or a law firm website, every answer is no. That contrast shows how clear the decision really is.

Asking these questions during the design phase costs far less than fixing things later. Removing a preloader from a live site means you also have to fix everything it was hiding at the same time. In the design phase, you simply build the first view with content first, and that debt never appears.

Preloader checklist: what should you check on your site?

Use the list below before launch or while reviewing your current site.

1. Is the preloader truly needed, or is it a theme leftover?
2. Does the layer lift as soon as content is ready?
3. Is a minimum display time set? If so, remove it.
4. Does the LCP element stay hidden behind the layer?
5. When reduced motion is on, does the animation stop?
6. Does a screen reader hear the waiting state as text?
7. Is there a way to pause motion that lasts more than five seconds?
8. Does the layout shift when the layer lifts?
9. Is the experience acceptable on mobile and on a slow connection?
10. Would a skeleton screen work better for sections that wait for data?

If you get more than one no on this list, we recommend removing the preloader and fixing the root causes. It is also a good habit to review the list after every major design change, because new plugins and theme updates can quietly turn the loading screen back on.

How do you measure the result after removing a preloader?

To see the effect of the change, compare the same metrics before and after. Lab tests give fast feedback, while real user data builds up over a few weeks.

• Lab test: Test the same page with the same settings and note the LCP time.
• Field data: Give real user metrics time to change.
• Behavior data: In analytics, look at how sessions without engagement change.

However, do not decide based on a single week of noise. Campaigns, seasons and traffic sources can all shift the numbers. So it is safer to compare similar periods.

Example calculation: compare the previous four weeks with the next four weeks across the same traffic sources. This approach helps you separate campaign effects. If the result is less clear than expected, look at other speed issues on the page too.

Shall we build your site's first view together?

On most sites, a preloader looks like a small design detail. Behind it, though, sit decisions about speed, accessibility and conversion. When we design a new site, we plan the first view so that content comes first, and we set up skeleton screens and progressive loading for heavy sections.

If your current site has a loading screen and removing it reveals problems, let us build this part of your site for you. Fill in the quote form on our web design service page, and we will review your site and prepare a quote with scope and timeline.

In our quote, we list each step separately. That includes removing the preloader, moving critical content forward, cleaning up images and scripts and adding reduced motion support. So you know from the start what you pay for and which result we aim for.