The journal.

The short version

A 3D website uses your browser's GPU to render three-dimensional objects in real-time. The dominant technology is WebGL, a JavaScript API that talks directly to your graphics card. Most developers use Three.js — a library that wraps WebGL's gnarly low-level code into something human beings can actually work with.

When someone visits a 3D website, their browser downloads the scene geometry (usually as compressed GLTF files), builds a render pipeline, and starts drawing frames at 60fps. It's the same fundamental technology that powers video games — just running inside a browser tab instead of a desktop application.

When 3D makes sense (and when it doesn't)

3D websites work brilliantly for product showcases where you need the user to inspect something from every angle — think furniture, electronics, or architectural walkthroughs. They also crush it for brand storytelling — when a flat page can't convey the mood you're after.

Where they don't make sense: content-heavy sites. If someone needs to read 2,000 words of documentation, a spinning icosahedron in the background is just a distraction. Same for e-commerce with 500+ SKUs. The GPU overhead isn't worth it when your primary interaction is "add to cart."

The performance question

The number one concern clients have is speed. And it's fair. A poorly built 3D site can absolutely tank your Core Web Vitals. But here's the thing — a well-built one doesn't. We compress all 3D models using Draco compression, which shrinks geometry files by 90%. We use texture atlasing to reduce GPU draw calls. And we implement progressive loading so the page renders useful content while the 3D scene assembles in the background.

On a decent phone over 4G, our 3D sites load in under 2 seconds. That's faster than most WordPress templates.

Our stack for 3D projects

We use Three.js for scene management, React Three Fiber when we need tight React integration, and custom GLSL shaders when the visual effect can't be achieved with standard materials. For animation sequencing, GSAP handles the heavy lifting. Everything deploys to Vercel with aggressive caching headers.

If you're thinking about a 3D web presence, talk to us. We'll be honest about whether it makes sense for your use case.

Templates solve a different problem

Website templates are designed for speed of deployment, not speed of loading. They ship with dozens of features you'll never use — sliders, mega menus, WooCommerce hooks, social widgets — and every one of those features adds JavaScript to your page. The average WordPress theme loads 2.4MB of JavaScript before your first meaningful paint.

A custom-built Next.js site ships exactly what it needs. Nothing more. Our typical homepage weighs under 200KB total.

The SEO tax

Google's Core Web Vitals directly impact your search rankings. Templates consistently fail on Largest Contentful Paint because they load everything at once. They fail on Cumulative Layout Shift because they inject ads and widgets after the initial render. And they fail on First Input Delay because all that JavaScript blocks the main thread.

Custom builds let you control exactly when and how every asset loads. We can lazy-load below-the-fold images, defer non-critical scripts, and preload the fonts that matter — because we wrote the code that manages all of it.

The design ceiling

Here's the thing nobody talks about: templates have a design ceiling. You can change the colors, swap the fonts, maybe move some blocks around. But the underlying grid, the spacing system, the animation timing — those are baked in. Every site built on the same template looks like a cousin of every other site built on that template.

When we build custom, there is no ceiling. If you want a section that transitions into a 3D environment on scroll, we build that. If you want a custom cursor that morphs based on what it's hovering, we build that. The design is limited only by imagination and good taste — not by a theme's configuration panel.

Custom doesn't have to mean slow or expensive. It means intentional. And intentional websites convert better, rank higher, and last longer. See our case studies for proof.

The feature trap

Every founder we work with starts with a feature list that's 3x too long. Dashboard. Analytics. Team management. Integrations. Payment tiers. Admin panel. Notifications. The list goes on.

Here's what investors actually look at: Does the core value proposition work? That's it. They don't care about your notification preferences page. They care about whether your one key feature solves a real problem for real people.

Our MVP framework

We run a brutal prioritization exercise in the first week. Every proposed feature gets one of three labels: Core (the product doesn't exist without it), Important (makes it better but isn't essential), or Nice (cool but irrelevant to validation).

Only Core features make it into the MVP. Everything else goes on a roadmap for post-validation. This consistently cuts scope by 60-70%, which means we can ship in 4-6 weeks instead of 4-6 months.

The tech decisions that matter

For MVPs, we almost always reach for Next.js + Supabase. Next.js gives us server-side rendering, API routes, and static generation in one framework. Supabase gives us PostgreSQL, auth, and real-time subscriptions without managing infrastructure. Add Stripe for billing and you have a production-ready stack that scales to millions of users.

The critical thing: we write clean, modular TypeScript from day one. No shortcuts that create technical debt. Because if the MVP works and you need to scale, you shouldn't need to rewrite everything. You should be able to hire engineers and have them productive within a week.

Thinking about building an MVP? Let's scope it together. No pitch deck required.

The usual suspects

Unoptimized images are the number one offender. We've audited sites serving 4MB hero images that could be 80KB WebP files with zero visible quality loss. Always use next-gen formats. Always specify dimensions. Always lazy-load below the fold.

Render-blocking JavaScript is number two. If your analytics, chat widget, and social proof popup all load before the user sees content, you've lost them. Defer everything that isn't critical to first paint.

Web fonts are sneaky. Four font weights at 200KB each means 800KB of fonts alone. We use font-display: swap, subset our character sets, and preload the one weight that appears above the fold.

Our performance checklist

Every Z-One project ships with: images in WebP/AVIF with srcset for responsive sizing, critical CSS inlined in the head, JavaScript deferred or loaded as ES modules, font preloading with display:swap, aggressive caching headers via Vercel, and lazy-loaded iframes and below-fold media.

The result? Our sites consistently score 95-100 on Lighthouse without sacrificing visual quality or animation complexity. Speed and beauty aren't opposites — they're both products of good engineering.

Week 1: Discovery and architecture

We don't start in Figma. We start in a shared doc. What problem are we solving? Who's using this? What does success look like in 3 months? We map out the information architecture — every page, every user flow, every data relationship — before a single pixel gets designed.

Week 2-3: Design and component system

Once the architecture is locked, we design in Figma using a component-first approach. We build the design system — typography scale, color tokens, spacing units, button variants — before designing any pages. This means every page we design later is automatically consistent.

Week 3-6: Build sprint

Development happens in parallel with design refinement. We use Next.js with TypeScript, building components that mirror the Figma structure exactly. Backend work (API routes, database schemas, auth) runs concurrently. We deploy to preview URLs after every push so clients can see progress in real-time.

Week 6-7: Polish and launch

The last week is all about the details that separate good from great. Micro-animations. Loading states. Error handling. SEO metadata. Performance optimization. Accessibility audit. Then we ship it — usually on a Tuesday, because nobody launches on Fridays.

Want to see this process in action? Check our case studies.