DeepSee Commerce: A 3D E-Commerce Website Case Study

Most "3D websites" look incredible in a screen recording and fall apart the moment a real person opens them on a three-year-old laptop. DeepSee Commerce was the opposite brief: a 3D ecommerce website that had to feel cinematic and stay buttery on whatever device a prospect happened to be holding. This DeepSee Commerce case study breaks down how that site was built with Three.js, Next.js and GSAP — the brief, the WebGL craft, and the performance budgeting that kept an interactive 3D scene smooth enough to earn an Awwwards Honorable Mention. Written by the developer who shipped it.

Who built it — and why the developer credit matters

DeepSee Commerce is a boutique e-commerce agency, and I built the site as the creative developer — front-end architecture, the Three.js scene, the GSAP motion layer, and (the part nobody sees) the performance work that made all of it viable. That's me, Hon Tran.

I lead with that for a reason that's specific to 3D work: the gap between a beautiful WebGL concept and a site that actually runs at 60fps on mid-range hardware is entirely an engineering problem. I've spent 11+ years building award-winning, performance-first experiences for clients across Norway, Denmark, Sweden, Malta, Germany and Vietnam, I've been named Awwwards "Independent of the Year" twice, and I sit on the Awwwards jury. On a 3D commerce site, that experience is the difference between a scene that wows and a scene that overheats a phone and gets closed in two seconds.

The brief: 3D that sells, without the performance tax

DeepSee positions itself as the strategic partner that takes Amazon brands into deeper water — the whole identity is built on an ocean-and-iceberg metaphor ("chart a winning course," "what's beneath the surface"). The design translated that into a literal 3D underwater world: floating icebergs, depth, light scattering through water, a scene you sink into as you scroll.

That concept is a performance minefield. Three constraints shaped every decision:

• The 3D had to earn its place. A WebGL scene that's just decoration is dead weight. The depth metaphor had to be the navigation and the storytelling, not sit behind it.
• It had to stay fast everywhere. This is a sales site. A prospect on a mid-range Android is worth exactly as much as one on a maxed-out MacBook — and the iceberg scene had to hold up for both, or the whole pitch collapses.
• The first impression is a 3D scene. That makes initial load the single biggest risk. A heavy WebGL bundle blocking first paint would tank both the experience and the Core Web Vitals.

The craft: Three.js, Next.js and GSAP working together

The stack is Next.js + React on the front end, Three.js for the WebGL scene, and GSAP driving the choreography — the preloader, scroll progression, and section transitions. Here's how the signature pieces came together.

The underwater 3D scene

The iceberg world is a Three.js scene composed of layered meshes, depth fog, and light scattering to sell the "beneath the surface" idea. The trick to making 3D feel like part of the page rather than a separate canvas is to drive the camera from scroll, so descending the page literally descends through the water:

import gsap from 'gsap'
import { ScrollTrigger } from 'gsap/ScrollTrigger'
gsap.registerPlugin(ScrollTrigger)

// Map scroll progress (0 → 1) onto the camera's descent through the scene
const cam = { y: 0 }
ScrollTrigger.create({
  trigger: '#scene',
  start: 'top top',
  end: 'bottom bottom',
  scrub: 1, // smoothing — the camera eases toward scroll, never snaps
  onUpdate: (self) => {
    cam.y = -self.progress * DEPTH
    camera.position.y = cam.y
    fog.density = 0.02 + self.progress * 0.06 // murkier as you go deeper
  },
})

scrub: 1 is doing quiet but important work here — it decouples the camera from raw scroll input so the descent eases instead of jittering frame-to-frame, which is what makes a heavy scene read as smooth even when a frame occasionally drops.

Performance budgeting: where 3D sites are actually won or lost

This is the part the Awwwards jury can't see but absolutely feel. A 3D ecommerce website lives or dies on a few non-negotiable habits.

Cap the device pixel ratio. This is the single highest-leverage move on any WebGL build. A phone at DPR 3 is rendering ~9× the pixels of DPR 1 — fill rate the GPU pays for and almost nobody can see. Clamping at 2 routinely halves frame cost on high-density screens:

import * as THREE from 'three'

const renderer = new THREE.WebGLRenderer({ antialias: true, powerPreference: 'high-performance' })
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)) // never render above 2×
renderer.setSize(innerWidth, innerHeight)

Lazy-init the scene and pause it off-screen. WebGL should never spin up before it's needed, and it should never burn GPU cycles rendering something nobody's looking at. An IntersectionObserver gates both the init and the render loop:

let rafId = 0
const tick = () => {
  renderer.render(scene, camera)
  rafId = requestAnimationFrame(tick)
}

const io = new IntersectionObserver(([entry]) => {
  if (entry.isIntersecting) tick()                 // run only when visible
  else cancelAnimationFrame(rafId)                 // stop the moment it scrolls away
})
io.observe(document.querySelector('#scene')!)

That single pattern — render only what's visible — is often the difference between a fan spinning up on a laptop and a scene that just sits there cool and idle.

Budget the assets like they cost money. Compressed textures (KTX2/Basis), Draco-compressed geometry, and a tuned light count keep the scene's memory and draw calls in check. On mobile I drop shadow resolution and disable the most expensive post-processing entirely rather than ship one heavy scene to every device.

I go deeper on the measurement side of this — LCP, INP and CLS on motion-heavy builds — in Core Web Vitals for animation-heavy sites, and on the fundamentals of building React scenes in the React Three Fiber tutorial for beginners.

The preloader as a performance tool, not a gimmick

A 3D-first hero means the heaviest assets load before anything's interactive — so the preloader isn't decoration, it's where the loading cost gets hidden. GSAP sequences a real progress count tied to the actual asset queue, then hands off to the scene reveal so the transition into the underwater world feels like one continuous motion instead of a stall followed by a pop-in:

const tl = gsap.timeline()
tl.to(progress, { value: 100, duration: 1.2, ease: 'power2.out', onUpdate: paintCounter })
  .to('[data-preloader]', { yPercent: -100, ease: 'expo.inOut', duration: 1 })
  .from('#scene canvas', { opacity: 0, duration: 0.8 }, '<0.1')

The point is honesty: the counter reflects real loading progress, and the reveal only fires once the Three.js scene is genuinely ready — so nobody lands on a half-built world.

The result: an Awwwards Honorable Mention

DeepSee Commerce earned an Awwwards Honorable Mention — recognition for a build that pushed 3D web interaction for an e-commerce brand while keeping the experience smooth across devices. You can see it live at deepseecommerce.com.

What that result signals to a buyer: this is a site that's genuinely ambitious in 3D and still respects the visitor's hardware. For a commerce brand, that combination is the entire value proposition — memorable enough to stand out, fast enough that the standing-out never costs you a single prospect. That balance doesn't come from the mockup; it comes from the performance discipline baked into every layer.

FAQ

What is the DeepSee Commerce website built with?

Next.js and React on the front end, Three.js for the WebGL 3D scene, and GSAP for the motion layer — the preloader, scroll-driven camera, and section transitions. The stack was chosen for a 3D-first experience that still loads fast and stays smooth across devices.

How do you keep a Three.js ecommerce site fast?

Cap the device pixel ratio (clamp at 2), lazy-initialise the WebGL scene and pause its render loop when it scrolls off-screen, compress textures (KTX2/Basis) and geometry (Draco), and scale quality down on mobile — fewer lights, lower shadow resolution, lighter post-processing.

Is a 3D website bad for performance and SEO?

Only if it's built carelessly. A 3D scene that blocks first paint will hurt Core Web Vitals — but with a proper preloader, lazy WebGL init, capped DPR and budgeted assets, a 3D ecommerce website can hold strong LCP and INP scores. The engineering is what decides it, not the ambition.

What award did DeepSee Commerce win?

An Awwwards Honorable Mention, recognising the 3D interaction design and the performance work that kept it smooth across devices.

Let's build something award-worthy

If you're a founder, brand, or agency that needs a 3D or WebGL ecommerce website that actually performs — cinematic and fast — that's exactly what I do as a creative developer.

• See how I work and start a project on the hire page.
• Browse more shipped, awarded work in the projects archive.
• Ready to talk? Let's talk →

---

Written by Hon Tran — creative developer, founder of hontran.dev, and Awwwards jury member. 11+ years building award-winning, performance-first web experiences (Three.js / WebGL, GSAP, Next.js) for clients worldwide. The first Vietnamese developer to win an international web award. hontran.dev · Behance.