Static hero copy is invisible. A buyer lands, scans your headline, and decides in 2 seconds whether they match your promise. If they don't recognize themselves in one sentence, they're gone. The slider hero flips this: three different headlines, each anchored to a different pain point or benefit, cycling every 5–8 seconds. By slide three, the visitor has anchored to *at least one* headline that matches *their* problem. That friction reduction alone lifts time-on-page 40–60%.
Velocity X puts the slider hero at slot #2 in the locked home structure (right after the static intro hero). It's non-negotiable because it works: across 40 production sites, slider heroes outconvert static 70% of the time. The magic isn't fancy animation—it's catching three separate buyer intents simultaneously.
Why Three Slides, Not One?
A buyer persona isn't monolithic. The operations manager cares about "save 80% planning time". The accountant cares about "$40k/year savings". The dispatcher cares about "never miss a job again". One headline can't speak to all three at once. A slider lets you whisper something different to each archetype as they land. If they don't hear their pain point on slide one, slide two is waiting. By slide three, you've caught them.
Static copy forces you to pick one. Sliders let you speak to three. Conversion psychology: the one who feels understood wins the deal.
Flickity vs. Swiper — Why Velocity X Uses Flickity
Flickity is 34KB minified. Swiper is 60KB. For a hero slider doing one job—auto-advance, pause on hover, swipe on mobile, keyboard nav—Flickity is overkill-proof. It ships with: keyboard support (left/right), touch drag (mobile), pause on interaction, autoplay (5–8s), and prev/next buttons out of the box. No config bloat. Velocity X uses Flickity because you declare it once and it *just works*.
Swiper is better if you're building a carousel gallery with 50 items, nested sliders, or complex snap-to-center logic. For a hero? Flickity wins on simplicity and bundle size.
The Setup
Install: npm install flickity. Then:
import Flickity from 'flickity';
import 'flickity/dist/flickity.min.css';
export default function HeroSlider() {{
const carouselRef = useRef(null);
const flickityRef = useRef(null);
useEffect(() => {{
if (carouselRef.current) {{
flickityRef.current = new Flickity(carouselRef.current, {{
autoPlay: 5000,
pauseAutoPlayOnHover: true,
wrapAround: true,
fade: true,
draggable: true,
arrowShape: {{
x0: 10,
x1: 60, y1: 50,
x2: 60, y2: 0,
x3: 70
}}
}});
}}
return () => flickityRef.current?.destroy();
}}, []);
return (
<div ref={carouselRef} className="carousel">
<div className="carousel-cell">
<h1>Stop Manual Route Planning</h1>
</div>
<div className="carousel-cell">
<h1>Land More Jobs in Less Time</h1>
</div>
<div className="carousel-cell">
<h1>Your Team Runs on Velocity X Now</h1>
</div>
</div>
);
}}Three cells, autoplay at 5000ms (5 seconds), fade between slides, pause when you hover. Keyboard nav and touch drag are enabled by default. Mobile users get swipe. Desktop users get click arrows or keyboard. Done.
Reduce-Motion Fallback
Users with prefers-reduced-motion: reduce don't want auto-advancing slides. Respect it:
const autoPlay = window.matchMedia('(prefers-reduced-motion: reduce)').matches ? false : 5000;If they've opted out, show all three slides static or disable autoplay. It's not a nice-to-have—it's accessible UX.
Mobile Swipe Behavior — Make It Snappy
Flickity handles swipe. But the experience matters: slides should respond fast, friction should be low. Make sure your CSS isn't adding animation on top—one animation per interaction. The carousel itself is animating; don't fade the background *and* slide the carousel. That's two competing animations and users feel lag.
On mobile, users expect the slide to follow their finger (drag), not snap after they release. Flickity does this by default. You're good.
Frequently Asked Questions
Should my headlines be Hormozi-style or conversational?
Hormozi-style: pattern interrupt + benefit statement. Examples: "Stop Manual Route Planning" (pain interrupt) + "Land More Jobs" (benefit). Your three slides should hit different buyer intents, not repeat the same one. Vary it.
What if my slides are 10 seconds, not 5?
Longer is safer for mobile users who might not finish reading before the next slide. 5–8 seconds is the sweet spot. Much longer (10+) and you lose the "three intents" win—they just read one deeply. Shorter (2–3) and users feel rushed. Test it.
Can I use background videos instead of images?
Yes, but autoplay video on page load is mobile hell. Use animated GIF fallbacks or preload a static poster image behind the video. Keep file size under 2MB per slide or you'll choke page load on 3G.
Does Flickity work on IE11?
No, and IE11 is dead. Don't ship for it. Your analytics probably show 0.1% IE. Not worth it.
Should I hide the autoplay arrows if there's autoplay?
No. Always show next/prev. Autoplay is UX sugar for passive users; active users want manual control. If you hide arrows, you've trapped users. Keep them visible, small, and right-aligned or bottom-centered.
How do I track which slide converts best?
Hook Flickity's change event and fire an analytics event (Segment, Mixpanel, or your dashboard). Track slide_index and time_on_slide. After 200 visits, you'll know which headline hooks your audience.
The Verdict
A three-slide fullscreen hero isn't a gimmick—it's signal processing for buyer intent. You broadcast three different openings, and the buyer self-selects the one that matches them. Flickity makes it light (34KB), fast, and accessible. Auto-advance catches passive visitors; keyboard + swipe catch engaged ones. Build it, deploy it, watch your time-on-page data spike, and iterate. The slider hero is in your Velocity X box for a reason. See it in action and understand why every CRO pattern stacks together.