Completed experiment · Interactive web experience
I Built a 3D-Like Landing Page With AI — Here's What Happened
Can a visually rich, interactive landing page still be fast, understandable, and usable for a small business? We built one to find out.
Short answer
Yes—with restraint. The demo delivers the intended layered reveal using native browser features and no image, video, canvas, WebGL, or animation-library payload. Automated browser checks confirmed the full content remains available at seven viewport widths and with reduced motion. This experiment did not measure real-user conversion or network-based Core Web Vitals.
The Question
Can a visually rich, interactive landing page still be fast and usable for a small business?
Why We Ran This Experiment
Premium product pages often create depth with large media files and substantial JavaScript. That can be appropriate for a global product launch, but it is a risky default for a small business. We wanted to see how much of the storytelling effect could come from layout, vector geometry, and transforms already handled well by modern browsers.
What We Built
We created AURA ONE, a fictional spatial-audio device made only for this experiment. The working demo has a cinematic hero, a scroll-controlled exploded view, four explained component layers, a performance message, a mobile adaptation, and a final reassembly. It is not a client project or a commercial product.
Open the working AURA ONE demo →
The Hypothesis
A layered product story can feel dimensional without a 3D model if the animation uses a small number of meaningful planes, clear depth cues, and restrained scroll mapping. Avoiding raster media and third-party animation code should keep the route’s transfer footprint modest while preserving the visual idea.
The Setup
Tools Used
- Astro
- CSS transforms
- SVG
- TypeScript
- Playwright
- Chrome
Astro renders the content as static HTML. The product illustration is original inline SVG and CSS geometry. A route-specific TypeScript module reads scroll progress, schedules visual updates with requestAnimationFrame, and writes one CSS custom property. Playwright controls Chrome for repeatable viewport, keyboard, motion, and error checks.
How the Interaction Works
Desktop implementation
A sticky stage remains in view while the surrounding section provides scroll distance. Progress rises from 0 to 1. Each product plane receives an offset, rotation, and opacity calculated in CSS from that progress: the object separates during the first half, holds long enough to read, and reassembles near the end.
Mobile implementation
The same content and four layers remain available. Travel distances, perspective, and sticky duration are reduced; labels move into a compact grid beneath the object. Nothing essential depends on hover.
Reduced motion
When prefers-reduced-motion: reduce is active, the product is shown assembled, the sticky scroll sequence becomes a normal static section, and all component explanations remain visible.
Performance Strategy
- No Three.js, animation framework, video, image sequence, web font, or remote product asset.
- Transforms and opacity avoid geometry changes inside the animation loop.
- Scroll input is passive and visual writes are consolidated through
requestAnimationFrame. - The demo code and styles are route-scoped, so ordinary site pages do not load the interaction.
What We Measured
- Environment
- Local production build
- Date
- September 12, 2026
- Browser
- Installed Google Chrome, headless
- Method
- Astro build inspection + Playwright
- Viewports
- 360, 390, 430, 768, 1024, 1440, 1920 px
- Motion modes
- Default and reduced
Results
| Check | Observed result | Scope |
|---|---|---|
| Horizontal overflow | None detected | Seven tested viewport widths |
| JavaScript runtime errors | None detected | Automated demo run in Chrome |
| Reduced-motion fallback | Passed | Static stage; content retained |
| Keyboard access | Passed | Primary links and result CTA |
| Product media requests | 0 | No raster image, video, model, or remote asset |
| Demo-specific assets | 12,659 B CSS + 903 B JS | Uncompressed production output; JS is inline |
| Lighthouse score / field CWV | Not measured | No score is claimed |
| Conversion impact | Not measured | No real visitors or sales flow |
What Worked
The exploded view remains legible without loading a model or image sequence. The component copy gives the movement a purpose, while the static HTML preserves meaning before JavaScript runs. The mobile layout retains the idea instead of deleting it.
What Didn't Work
CSS layers cannot provide free camera movement or photorealistic reflections. At extreme scroll speed, the experience prioritizes the current state rather than animating through every intermediate position. The fictional object also cannot test whether real product imagery would remain equally light.
Limitations
- This is a controlled technical prototype, not a customer study.
- No real users, lead submissions, revenue, or conversion rate were measured.
- Automated viewport checks do not replace testing across physical devices and assistive technologies.
- Local transfer sizes are not the same as real-user network timing.
- The role of AI is limited to assistance during implementation; this test does not compare an AI workflow with a human-only baseline.
Would We Use This on a Real Small-Business Website?
For a focused campaign or premium product reveal, potentially yes. We would keep the story short, test it with the client’s real media and audience, and provide an immediate path to the primary action. We would not add this interaction to a routine service page merely to look sophisticated.
What We'd Change Next Time
Replace the abstract object with an owned, optimized product render; test on physical mid-range phones; collect consented real-user performance data; and compare task completion against a static version. Those steps would answer questions this build cannot.
Methodology
- Define one question and a fictional product so no client claim is implied.
- Build the complete interaction without third-party animation or 3D dependencies.
- Create a production build before measurement.
- Open the demo in Chrome at each declared viewport and compare document width with viewport width.
- Exercise the scroll sequence, CTA, mobile layout, keyboard focus, and reduced-motion mode.
- Record browser errors and inspect generated route assets.
- Report unsupported metrics as not measured.
Sources / Further Reading
- MDN: prefers-reduced-motion
- MDN: requestAnimationFrame
- web.dev: How to create high-performance CSS animations
- W3C: Animation from Interactions
Last tested and updated: September 12, 2026. Material changes to the implementation or results should be recorded here.