Every 3D web project starts with the same question and it is usually the wrong one to obsess over. Both answers use the same renderer.
What Each One Is
Three.js is the library that talks to WebGL. Scenes, cameras, meshes, materials, lights, loaders, the render loop. Everything real-time 3D on the web is built on it or on something like it.
React Three Fiber is a React renderer for Three.js. Same engine underneath. Instead of imperatively constructing a scene graph and mutating it, the scene is described as React components with props and state, and the reconciler handles the mutations.
R3F does not add a meaningful runtime penalty. It changes authoring, not rendering.
The Actual Decision Criteria
- Does the scene need to react to application state? If scrolling, routing, a form submission, a filter, or a user selection changes what the scene shows, R3F wins decisively. Wiring imperative Three.js to React state by hand is where projects rot.
- Is the rest of the site React? If yes, R3F keeps one mental model and one component tree instead of two systems synchronizing across a boundary.
- Is the scene self-contained? A standalone experience with its own loop and no application state around it is perfectly well served by vanilla Three.js, with less indirection.
- Does the team need the ecosystem? The R3F ecosystem, particularly the helper library around it, provides loaders, controls, post-processing, performance scaling, and environment tooling that would otherwise be hand-built. That is often the deciding practical factor.
- How much manual control of the render loop is required? Highly custom multi-pass pipelines sometimes justify going direct.
The Parts That Actually Cost More Than the Stack
The stack choice is a day. These are the real budget lines.
Asset preparation. Models arrive from a designer at production density and are unusable on the web. They need retopology, decimation, UV cleanup, baked lighting where appropriate, Draco or Meshopt geometry compression, and KTX2 texture compression. A raw GLB can drop from tens of megabytes to under two without a visible difference.
Camera choreography. Deciding where the camera goes, how it eases, what it frames, and how it responds to scroll or interaction. This is directing work, not engineering work, and it is what separates a 3D scene from a 3D experience.
Shader and material work. Custom materials are where a scene stops looking like a default viewport render.
Performance budgeting. Draw calls, texture memory, pixel ratio caps, light and shadow counts, and instancing. Covered in depth in the 3D performance breakdown.
The Architecture Rule That Protects Search
The page's real content lives in server-rendered HTML. The canvas sits on top as a presentation layer. Schema, headings, copy, and FAQ data are all in the source before any WebGL context is created.
Get that wrong and the site is invisible to crawlers and to generative engines regardless of how good it looks. Get it right and a 3D experience carries exactly the same search structure as a standard build.
UM Media builds Immersive / 3D Experiences from $12,000, typically $15,000 to $25,000 and up. See Advanced Web Experiences, or read what an immersive website actually is.