Luxury real estate website design: cinematic property tours without scroll jank

Why luxury real estate website design stutters on real phones

Picture a buyer opening a villa launch link on a three-year-old Android phone. The luxury real estate website design looked flawless on the agency’s laptop. On her phone, the living room glides in, the kitchen shudders, and the tour suddenly jumps, leaving a blank strip of screen.

The “Book a private viewing” form sits five screens of stutter further down. She closes the tab before she reaches it, and the click the launch campaign paid for is gone.

We have built two sites like this: a prototype villa tour made to test scroll-driven motion, and a lightweight website kit, a product we built for architects and property developers. Here is what they taught us.

Cinematic tours tend to fail in four places:

• Jank. Scroll-linked motion misses frames, so rooms stutter instead of glide.
• Core Web Vitals. These are Google’s scores for how fast the main content appears, how quickly taps respond and how much the layout jumps. Heavy heroes, heavy scripts and images without dimensions hurt them.
• Motion sickness. Large scroll-driven zooms with no off switch make some visitors unwell.
• Buried enquiries. The booking form sits below the spectacle and breaks when the motion code breaks.

Why the usual fixes for scroll jank fail

Teams often bolt a smooth-scroll library onto the agency build, judge the result on a laptop, and switch everything off for anyone who asks for reduced motion. Each treats a symptom.

Without a measure, designer and developer trade screen recordings and opinions. We wanted a number both sides could agree on, the same idea behind our release evidence for UAT sign-off.

One animation clock for GSAP ScrollTrigger and Lenis

Two libraries usually do the work. Lenis makes scrolling glide instead of step, and GSAP ScrollTrigger moves the rooms as the page scrolls. If each keeps its own timer, they read the scroll position at different moments, and the room trails the page by a frame.

So in the tour, one clock drives both. The GSAP ticker calls lenis.raf on every tick, and Lenis reports each scroll to ScrollTrigger.update. Setting lagSmoothing(0) stops GSAP from pretending less time passed after a long stall.

On phones this matters less than it sounds. Lenis leaves touch scrolling native by default, so the shared clock mainly fixes wheel and trackpad jitter. Touch pins still need a test on a real device.

The pinned room-by-room tour

The tour section stays pinned (fixed on screen) for five screens of scrolling, one per room. Each room fades out while scaling to 1.08, and the next settles from 1.12 to full size.

A 0.8-second scrub lets rooms ease after the scroll instead of snapping, while the pin stays locked to the page. The anticipatePin setting stops the jump as the section locks, and invalidateOnRefresh recalculates after a resize.

A 16.67 ms motion budget, and an image budget for Core Web Vitals

At 60 frames a second, the browser has 16.67 milliseconds per frame, and less on 90 or 120 Hz screens. Miss that and the frame is dropped, which the eye reads as stutter.

Transform and opacity are the properties a browser can usually animate on the GPU without new layout or paint. So every scrubbed effect in the tour is a move, a scale or a fade, and even the progress bar grows by scaling, not by height.

GSAP still writes those values from the main thread, so a long script task can drop a frame. Effects that need paint play once: the floor plan’s lines draw in when it enters view.

• Images requested at a fixed width per slot. Full-bleed rooms request 1,800 px WebP, tiles 600 to 1,000 px, swatches 500 px and floor-plan previews 400 px. With no srcset yet, a phone downloads the same 1,800 px room as a desktop.
• Only the top of the page loads eagerly. The hero and first tour room load at once, and the rest waits until the visitor nears it. The kit also gives its hero high fetch priority, since the hero is usually what Google’s main load score times.
• In the kit, every image declares width and height, so the browser reserves the space and text does not jump. The tour’s photos do not.
• A hard 300 KB cap per image. In the kit, a smoke test fails if any WebP crosses it. The six bundled photos weigh 115 KB to 233 KB.

Reduced motion as a designed version, with a pause button

Visitors who get dizzy from motion can ask their device for less, and a site reads that request through the prefers-reduced-motion media query.

Our tour prototype shows the trap. When a visitor asks for less motion, its setup code exits early, which correctly skips smooth scroll and every scroll scene.

But the same exits skip wiring the date picker, time slots and guest counter, and rooms two to five start invisible in the HTML. That visitor sees one room, a materials strip whose later swatches are out of reach, and booking controls that do not respond.

The fix is ordering: show the content and wire the form first, then exit only from the motion code.

The kit works the other way round. Under reduced motion, or without IntersectionObserver, every reveal is marked visible, and content is hidden only after the script runs. A script that fails to load never leaves a blank section.

Gate the motion, never the content or the enquiry form.

Keep the booking button in view

The tour keeps a “Book a Tour” button in its fixed navigation bar, so a buyer can jump to the form from any room. The motion is the showcase, and the enquiry should never wait behind it.

A pause button for every visitor

Many people never find the system setting, so the kit shows a visible Pause motion toggle. It stops looping animations, flattens tilted cards and pauses the embedded demo previews.

How to measure dropped frames on a website, not by feel

A frame-timing harness opens the page in a real browser engine, scrolls it in fixed steps, and records how long each frame took. Ours uses Playwright and headless Chromium at 1,440 × 900.

One run scores the whole page and a second scores the horizontal materials strip, our heaviest section. Scoring every scene separately is next.

Across the whole page, under 5% dropped frames reads as smooth, 5 to 20% as minor stutter, and over 20% as a problem. The materials run is looser: under 30% counts as smooth.

Structural checks flag a tour shorter than 90% of five viewports (a collapsed pin), a dead zone over 1,000 px after it, console errors, failed requests, broken images and sideways overflow at 390 × 844.

A smoke test for the rules people forget

The kit adds a source check that needs no browser. It fails on missing alt text or image sizes, placeholder “#” links, broken anchors and duplicate ids. It also fails on missing reduced-motion rules, any WebP over 300 KB, and JavaScript that does not parse.

Alt text alone is worth automating: WebAIM found images missing alternative text on 53.1% of the top million home pages in 2026.

What we would harden next, and a checklist you can use

Both builds have limits we would fix next:

• A laptop is not a mid-range phone. A desktop CPU flatters every number, headless Chromium has no phone GPU, and the measured steps bypass smooth scroll. Treat the scores as a relative signal. Next we would add CPU throttling, run the harness on each pull request, and compare with field data.
• The 1.5-second refresh is a guess. None of the tour’s 19 images declare width and height, and there is no srcset. Reserving image space, serving phone-sized files and refreshing when fonts are ready would remove the guess.
• Layer hints are a budget too. Each will-change hint can cost GPU memory, and the tour sets it on about 20 selectors, including every testimonial character and two wrappers that never move. We would hint only what animates.
• The tour has no pause button. Its stat marquee and slow hero zoom loop forever unless reduced motion is set, the case WCAG 2.2.2 covers.
• Reduced motion needs its own test run. Emulating the preference in the harness would have caught the hidden rooms and silent date picker on day one.

If your real estate developer website wins compliments in review and loses enquiries on phones, we can help. We build custom web software with these checks built in. Book a free 30-minute discovery call, bring the URL, and we will walk through where it stutters on a mid-range phone, what slows the first screen and whether booking works with motion off.