What should a loading state look like on a marketing site?

Does a marketing site even need loading states?

Only where something genuinely waits, which on most marketing sites means forms, filters and embedded content. Everywhere else a loading state is decoration that costs you layout stability. The test is whether a real person will be looking at an unresolved area of the page.

I see two opposite mistakes. Sites that animate a spinner over content which was already there, and sites that let a filtered list collapse to nothing and then jump back, with no indication that anything is happening at all.

Both come from treating loading as a visual effect rather than as communication. A loading state has one job: tell the person that their action registered and that waiting is the correct thing to do right now.

Why does a loading state exist at all?

To stop someone doing your work twice. A person who clicks a filter and sees nothing change assumes the click missed, so they click again, and now you have two requests and a worse experience. The loading state is an acknowledgement, not an animation.

That framing decides where they belong. Anything triggered by an interaction needs acknowledgement, because the person is waiting for a response to something they did. Anything happening on its own, before they asked, usually does not, because they were not waiting for it.

It also decides what the state has to contain. Not entertainment, not branding, just enough for someone to conclude that the system heard them. The most successful loading states I have built are visually boring and never leave anyone wondering.

What does a bad loading state do to your Core Web Vitals?

It can wreck your layout stability. Google defines a layout shift as occurring any time a visible element changes its position from one rendered frame to the next, and CLS as a measure of the largest burst of layout shift scores for every unexpected layout shift during the page's lifecycle.

The thresholds are specific. Google states that good CLS values are 0.1 or less and poor values are greater than 0.25, and that a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. A content area that collapses and then expands is exactly the pattern those numbers punish.

The burst mechanic is worth understanding because it explains why a single messy interaction can dominate your score. Google describes a session window as when one or more individual layout shifts occur in rapid succession with less than one second between each shift and a maximum of five seconds for the total window duration. A skeleton appearing, resizing and being replaced can easily fall inside one window.

Which shifts are acceptable and which are not?

Google draws the line clearly. It says layout shifts that occur in response to user interactions are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user. That one sentence settles most arguments about this.

The interactions Google names are clicking or tapping a link, pressing a button, and typing in a search box. So the question is not whether things move. It is whether the person caused the movement and can tell that they did. A filtered list that rearranges immediately after someone picks a filter is understood. The same rearrangement happening two seconds later, after their attention moved on, is not.

That gives you a practical rule for building these. Keep the response tied tightly to the interaction, reserve space so the surrounding page does not move, and never let content reflow after the person has started reading something else. Layout stability sits alongside actual speed, and the two get confused constantly, which is why I wrote about what a CDN cache will not fix on a slow page.

Should you use a spinner or a skeleton?

A skeleton when you know the shape of what is coming, a spinner when you do not. A skeleton that matches the eventual layout reserves the space and prevents the shift. A spinner in a container of the wrong height guarantees one.

The failure case for skeletons is guessing wrong. A skeleton showing three rows where four arrive produces exactly the shift you were trying to prevent, and it does it while looking deliberate, which makes it harder to spot in review. If you cannot predict the shape, do not pretend to.

My preference for marketing sites is neither, where possible. Reserve the space with a fixed minimum height and show the result when it lands. No placeholder, no shift, nothing to animate. It is less impressive in a design review and better on a real phone on a real connection.

How long should something take before you show anything?

Long enough that the delay is real, because a loading state that flashes on and off is worse than none. If a response arrives almost immediately, a placeholder appearing and vanishing reads as a glitch rather than as feedback, and it undermines confidence in everything else on the page.

I deliberately will not give you a millisecond threshold here. Figures for how long a delay feels instantaneous circulate widely and I cannot point you at a primary source for one, so I am not going to assert a number that would sound more authoritative than my evidence for it.

What I can tell you is how to decide. Test the interaction on a throttled connection, watch whether the placeholder has time to be understood, and if it does not, delay showing it or drop it. The judgement is empirical and takes one afternoon on your own site.

How does a screen reader know something is loading?

Only if you tell it. A spinner is a visual cue and conveys nothing to someone who is not looking at the screen. MDN describes the aria-live attribute as indicating that an element will be updated, and as describing the types of updates users and assistive technologies can expect from the live region.

The value you choose matters. MDN explains that polite means updates should be presented at the next graceful opportunity, while assertive means updates have the highest priority and should be presented immediately. It also warns not to use assertive unless the interruption is imperative, because an interruption may disorient users or cause them to not complete their current task. A filter finishing is not imperative, so polite is the right choice.

There is one implementation detail that catches almost everyone. MDN says the aria-live attribute is set on an empty element, and that when an update occurs that empty element should be updated with a brief announcement informing the user an update has been made. So the live region has to exist in the page first and be empty. Adding the region and its content at the same moment is the most common way this quietly fails.

What should a failed load look like?

Like a sentence, not a spinner that never stops. The worst outcome of any loading state is one that spins forever, because it tells the person to keep waiting for something that is never coming, and they will wait far longer than you expect before giving up.

Every loading state needs a defined end in both directions. Success replaces it with content. Failure replaces it with a short explanation and something to do next, usually retry. If you have not written the failure text, you have not finished the feature, and the failure path is the one you will never see in a design tool.

Say what the person can act on and nothing else. "We could not load these results. Try again." is enough. An error code, an apology paragraph, or a technical explanation of the request that failed all make an already frustrating moment longer. The same brevity principle applies to designing a form that asks for less.

What should you do next?

Throttle your connection, then use your own site's forms and filters. Watch what moves, whether anything flashes, and whether a failure is even possible to reach. Most loading problems on marketing sites are visible in five minutes and have never been looked at once, which is also true of why a site feels slower on mobile.

Then fix them in this order: reserve the space so nothing shifts, add a polite live region that already exists in the page, and write the failure sentence. That sequence handles layout stability, accessibility and the worst-case experience, which is all three of the things people skip.

Across 70+ projects for 25+ clients, loading states are the part of a build that gets designed last and tested least, usually on the fastest connection in the office. If your site has a filter or a form nobody has tried on a slow phone, reach out and let's go and break it deliberately.