Search Small Tool Guides

Start typing to find a guide or tool.

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

Test Notes
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

CheckObserved resultScope
Horizontal overflowNone detectedSeven tested viewport widths
JavaScript runtime errorsNone detectedAutomated demo run in Chrome
Reduced-motion fallbackPassedStatic stage; content retained
Keyboard accessPassedPrimary links and result CTA
Product media requests0No raster image, video, model, or remote asset
Demo-specific assets12,659 B CSS + 903 B JSUncompressed production output; JS is inline
Lighthouse score / field CWVNot measuredNo score is claimed
Conversion impactNot measuredNo 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.

Try the demo

Methodology

  1. Define one question and a fictional product so no client claim is implied.
  2. Build the complete interaction without third-party animation or 3D dependencies.
  3. Create a production build before measurement.
  4. Open the demo in Chrome at each declared viewport and compare document width with viewport width.
  5. Exercise the scroll sequence, CTA, mobile layout, keyboard focus, and reduced-motion mode.
  6. Record browser errors and inspect generated route assets.
  7. Report unsupported metrics as not measured.

Sources / Further Reading

Last tested and updated: September 12, 2026. Material changes to the implementation or results should be recorded here.