Loading screens (skeleton screens) on a landing page: premium effect or conversion killer?

A trend keeps resurfacing among landing page creators: a brief black screen with a pulsing logo, a stylized progress bar, or a set of gray blocks filling in with a gradient before the "real" page appears. The intent is understandable — it signals care, a finished product, almost a native app feel. The problem is that most of the time, this screen hides no real loading at all: the page is already ready, and the animation only adds an artificial wait between the visitor's arrival and the one thing that matters to them, your value proposition. What research says about perceived wait time helps separate the cases where a loading effect genuinely helps a landing page from those where it only slows it down.

What the research on perceived wait time actually measures

Two findings, one in interface design and one in services marketing, frame the question well. The first comes from a study presented at the CHI conference by Chris Harrison, Zhiquan Yeo, and Scott Hudson: by varying only the visual shape of a progress bar — a non-linear pace, a slight acceleration toward the end — without changing the actual loading time, the authors measured roughly an 11% reduction in the duration users perceived (Harrison, Yeo & Hudson, 2010). The design of a loading indicator changes the perception of time independently of the time actually elapsed — but this study concerns waits that are already necessary (an actual download), not a wait added by choice.

The second finding, better known as the "labor illusion," comes from Ryan Buell and Michael Norton, published in Management Science: on travel and dating sites, making the work performed by the service visible during a search (a bar reading "checking 50 partners…", "verifying availability…") increases the perceived value of the result, to the point that some users prefer a visibly longer search over an identical instant result (Buell & Norton, 2011). The effect is real, but it depends on actual work taking place: the service is genuinely searching for something while the bar progresses. A landing page that shows a pulsing logo for two seconds before content that was already fully loaded recreates neither condition — it doesn't speed up the perception of a necessary load, and it makes no real work visible.

The splash screen before the hero: a false good idea

On a landing page built with Next.js and served statically, the hero's HTML is usually ready to display within a few hundred milliseconds — that's exactly what LCP measures, as covered in our article on page load speed. Adding a splash screen deliberately delays this first useful paint, often by one to three seconds, for an animation that gives the visitor no information at all. The cost doesn't stop at first impression: a script that blocks the hero's render to drive an opening animation also hurts the interactivity measured by INP, covered in our guide to Core Web Vitals and INP — a visitor who clicks the CTA while the animation is still finishing may see their click ignored. A visitor arriving on a landing page already has an intent (they clicked an ad, a link, a search result); the only effect of an opening screen is to push back the moment that intent meets your offer.

Where a partial loading screen genuinely earns its place

Content that genuinely loads after the initial render

Some blocks on a landing page legitimately depend on a network call that arrives after the initial render: a signup counter fed by your email tool, reviews fetched from an API, a price or stock level recalculated live. In that specific case, a skeleton screen — a gray rectangle the exact size of the final content, rather than an empty space or a generic spinner — earns its place: it avoids the layout shift that happens when the real data arrives, and it visually prepares the eye for where the information will appear. That's exactly what the signup counter does on our SaaS Waitlist template (demo): the number shown is real data, so a brief loading state before it appears is honest rather than decorative.

A calculation that genuinely takes a moment

A pricing simulator or savings calculator, like the one covered in our article on interactive calculators, is the closest match to the labor illusion studied by Buell and Norton: if the calculation triggers actual processing (a call to a pricing API, aggregating several variables), briefly showing "calculating your estimate…" before the result can legitimately increase trust in the figure obtained — as long as that delay matches a real process and stays very short, one second, not five.

The line not to cross: simulating work that doesn't exist

Once you know about the labor illusion effect, the temptation is to add an artificial setTimeout to stretch out a calculation that actually runs instantly on the client. That's the same reasoning — and the same risk — as stock counters that never go down or countdown timers that reset, covered in our article on dark patterns: the effect works as long as the visitor doesn't notice, and backfires the moment they open dev tools or come back to the page a second time to find that "the calculation" takes exactly the same amount of time on every attempt. An honest delay varies slightly from one try to the next because it corresponds to a real network round trip; a manufactured delay is perfectly identical every time, which gives it away the moment anyone pays attention.

Checklist before adding a loading screen

• Does the hidden content genuinely take more than 300 to 400 ms to be ready? Below that, the loading screen creates more wait than it hides.
• Does the animation delay the hero and the main CTA from appearing? If so, it costs both perceived and actual speed with nothing given back to the visitor.
• Does the skeleton match the exact size of the final content? If not, it causes the very layout shift it was meant to prevent.
• Does the delay shown correspond to a real process? A delay manufactured from scratch counts as a dark pattern the moment it's discovered.
• Wouldn't the same effect be better achieved by simply making the page faster, rather than dressing up the wait?

In the vast majority of cases, the best answer to "should I add a loading screen?" is still to make the page fast enough that you no longer need to hide anything. Our 10 LanderKit templates (€89 each, €229 for the full pack) are built to display their hero immediately, with no splash screen or blocking dependency — the rare elements that load asynchronously, like the counter on the SaaS Waitlist template, reserve the skeleton screen for cases where it reflects real data rather than a stylistic effect.