The hidden cost of carousel sliders (and how to fix them)

The homepage carousel is the most-requested element in web design and one of the least effective. Stakeholders love it because it promises to fit five messages where one belongs. Visitors largely ignore it, and the browser quietly pays for it in page speed. This is the case against the auto-advancing slider — and the fixes if you are keeping one anyway.

It connects to the interactivity side of our Core Web Vitals guide, because carousels hit two of the three metrics at once.

The carousel paradox

Usability research has been consistent for over a decade. The most-cited dataset comes from the University of Notre Dame, whose web team published interaction stats showing that only about 1% of visitors clicked the homepage carousel at all — and of that 1%, roughly 84% clicked the first slide, leaving the later slides with a vanishingly small share. Nielsen Norman Group’s own usability and eyetracking work has reached the same conclusion from a different angle: people tend to ignore carousels, partly because auto-rotation reads as an advertisement and partly because moving content is hard to engage with. The numbers vary by study, but the shape never does — engagement collapses after slide one. You are not communicating five things; you are communicating one thing to most people and four things to almost nobody, while paying the full performance cost of all five.

The speed cost, metric by metric

LCP. A carousel often initialises with JavaScript, and its images may load via script after render. That delays the largest element — frequently the first slide image — and lands directly on LCP. The carousel is often the very thing being measured, not a bystander.

CLS. If slide transitions are animated with properties that trigger layout (rather than compositor-only transforms), each advance can shift surrounding content, feeding Cumulative Layout Shift.

INP. An auto-advancing carousel runs JavaScript on a timer, and its controls add interaction handlers. That constant background work competes with the visitor’s taps, hurting how responsive the page feels.

If you must keep it

• Put the first slide’s image in the server-rendered HTML so the browser discovers it immediately.
• Animate with CSS transform only (compositor-friendly), never properties that trigger layout.
• Turn off auto-advance — it is the single biggest INP and usability offender, and it frustrates anyone trying to read.
• Lazy-load slides two onward; eager-load only the first.

Why everyone asks for a carousel anyway

If carousels are this ineffective, why does every project end up with a request for one? Because a carousel resolves an organisational problem, not a user one. Three teams each want their message in the prime spot at the top of the homepage; nobody wants to be the one cut; a carousel appears to give everyone a slot. It is a political compromise dressed as a design decision. Understanding that is the key to handling the request well, because arguing performance with someone whose actual concern is “my campaign needs visibility” talks past them.

The more productive conversation reframes the trade-off: the carousel does not actually give the three messages equal visibility — the data says slides two and three are seen by almost nobody, so two of the three teams are getting a slot that does not work. A single strong hero, rotated on a schedule, or a bento layout that shows several messages at once, genuinely serves more of them than a carousel that hides most of its content. You are not taking visibility away; you are pointing out that the carousel was never delivering it. That argument lands where “carousels are slow” does not, because it speaks to what the stakeholder actually wants.

The better alternatives

Most of what a carousel is asked to do is done better by something static. A single, confident hero image and headline communicates one clear thing — which is what visitors take in anyway. A bento grid shows several items at once, all visible, none hidden behind a timer. A simple feature row lays out three or four points side by side. All of these are faster (no carousel JavaScript), more accessible, and more effective, because the visitor sees everything without waiting for a rotation.

When a carousel is actually right

There is a narrow valid case: a set of genuinely equivalent, same-context items the visitor chooses to browse — product photos of one item from different angles, or a gallery the visitor opens deliberately. The key difference is intent. A gallery lightbox the visitor opens and swipes through is fine; an auto-advancing homepage carousel that rotates marketing messages at them is the anti-pattern. One serves the visitor’s intent; the other fights it.

This is also why a gallery’s own lightbox is a different thing from a homepage slider. A well-built lightbox loads on demand, runs light JavaScript, and only does work when the visitor asks it to — which is the model to prefer. FotoGrids’ lightbox is built that way, and its layouts favour showing work in a grid the visitor scans freely rather than a rotation that hides most of it.