How a 3D website is made, from the model to the legal page

The scene: a model, its materials, its light

Everything in the scene has to come from somewhere. A product is modelled in a 3D program such as Blender, which is free and open source, or commissioned from a 3D artist; a room or a device can also be built directly in code. On the web, models usually travel as glTF, the format the Khronos Group designed for loading 3D scenes efficiently.

A model made for a render or for printing is usually far too heavy for a page. It needs fewer polygons, textures sized for a screen and often compressed geometry. Then every surface needs a material — how glass, metal or paper take the light — and the scene needs its lights. Nothing is rendered in advance, as it is for a film: the visitor’s graphics chip draws every frame, so each light and each reflection costs something on their device.

In the kits. Product takes your own model as a .glb file and finds its parts by name, so the chapters that move them work with yours; compressed files are read too, and their decoders are only downloaded when a file needs them. If a model won’t load, the kit’s own flask stands in. App builds its phone and laptop in code, to a real phone’s proportions and without any brand’s logo, and puts your screenshots on their screens. Studio builds its gallery in code and hangs your project pictures in it, each frame taking the shape of its picture.

Forest needs no model at all. When you add a photo in the wizard, a depth model called Depth Anything V2 Small, run by ONNX Runtime Web on your graphics card where the browser allows it and on the processor otherwise, estimates how far away each point of the photo is; the scene then gives the photo that depth. It all happens in your browser, and your photos aren’t uploaded anywhere.

The scroll: what moves, and when

On a scroll-driven page, the scroll bar is the timeline. Someone decides, section by section, where the camera stands, what moves and when the words come in, and makes every change run both ways: scrolling back up has to play it in reverse, at whatever speed the visitor goes, with a wheel, a trackpad or a finger.

Words and 3D share one screen, so the choreography also decides where the text sits at each moment and when it gives way to the scene.

In the kits. Each page is a series of pinned sections — the page holds still while the scene plays through one moment — and each section is one shot of the same scene, blended into the next as you scroll. A section’s words show while it holds still and are gone before it moves on, so between sections only the scene moves. With a mouse or a trackpad the page smooths the scroll; on a touch screen, or with reduced motion, the scrolling is the browser’s own.

Weight and speed: a budget, and a phone

Everything the scene needs travels to the visitor before it can be drawn: the 3D library, the scene’s code, the models, the textures, the photos. web.dev describes a performance budget as a set of limits on what affects a site’s speed — the total size of a page, for one — agreed at the start and checked by the build, so a page can’t grow heavier by accident.

Phones are where it gets hard: smaller graphics chips, less memory, a battery, a narrow screen held upright, and often three physical pixels for each pixel of layout. Drawing at a ratio of 3 means nine times the pixels of a ratio of 1, on every frame, and at 60 frames a second each frame has about 16.7 milliseconds.

In this site’s build. promti.app checks its own pages: the build fails if the script the home page runs first passes 16 KB compressed, or if its 3D passes 200 KB; in the build of 27 September 2026 they came to 11.8 KB and 159 KB. For the kits, three.js, the library that draws their 3D, is 142 KB compressed, and each kit’s download is built from 19 to 27 files weighing 1.1 to 3.7 MB, plus the typefaces — most of it the demo’s own pictures and model, which yours replace. The page’s scripts are modules, which don’t hold the browser up while it reads the HTML, and each kit’s scene code is loaded separately, once the page is running.

The kits draw at most 1.75 times the layout’s pixels, whatever the screen could take; Forest draws at 1.5 on phones and, if frames average more than 19 milliseconds over a second, lowers its resolution a quarter at a time, as far as 1. Drawing stops while the tab is in the background, and a frame with nothing on screen isn’t drawn. In the wizard, Forest’s photos are resized to 2,048 pixels on their long side, and other pictures larger than 2,400 are brought down to that. Product and App frame their scene again for a phone held upright, with the words below the subject rather than beside it.

For everyone: less motion, and text that is text

Motion on screen can make some people dizzy or nauseous — the W3C’s accessibility guidance names vestibular disorders — and operating systems have a setting to reduce it, which a page can read through the prefers-reduced-motion media feature. A 3D page that ignores it moves just as much for the people who asked it not to.

In the kits. With reduced motion on, the page scrolls with the browser’s own scrolling, text appears without animating in, and the scene stops following the pointer; App skips its opening, and Forest changes from one photo to the next with a fade instead of travelling into it. The scene still follows the scroll: on these pages it is the content, so there it stays.

Text is the other half. A WebGL scene is drawn on a canvas, and a canvas holds nothing to read: MDN describes it as a bitmap that tells assistive technology nothing about what’s drawn, and Google says it doesn’t index content rendered in one. So the words have to be real HTML — headings, paragraphs, buttons, links — laid over the scene rather than painted into it.

In the kits. The headings, texts, prices and buttons you write in the wizard go into the page’s HTML, over the scene; where a kit also sets words inside the 3D, as Product does with its statement, the same words are in the HTML for screen readers. Each Forest photo’s description goes into the page as text too. And on a device that can’t run WebGL, the page still shows its words and buttons, and Forest shows your photos, flat.

What a demo never shows: languages, the legal page

A second language means a second copy of every word and, for search engines, a second address: Google asks for a separate URL for each language version, with hreflang annotations linking each to the others, and it works out a page’s language from its visible text rather than from code.

In the kits. A kit makes a site in one language, English or Spanish, chosen in the wizard; the kit’s own words, such as its menu and its buttons, come in that language, and the page’s code says which one it is. A site in two languages needs more than a kit gives.

The legal page is what a demo never has and a business site can’t skip. In Spain, the LSSI requires a site that is part of an economic activity to say who is behind it, and a contact form brings the GDPR’s privacy information with it; the legal page for a business site goes through both.

In the kits. The download carries a legal page filled in from your answers — your name, tax number, address and contact details — with a privacy section naming only the services your site uses (its host, plus Web3Forms or Stripe if you added a form or a payment link) and a note that the site sets no cookies. It’s a template with your details in, to read through, not legal advice. The same download adds the title, description and sharing tags, robots.txt, a sitemap once you give your domain, and a page for broken links.

Questions

Do I need a 3D model to have a 3D website?

Not always. A scene can be built in code, as App and Studio build their devices and their gallery, or made from photos, as Forest does with six of yours. You need a model when the 3D is your own product: Product takes it as a .glb file and, without one, uses its flask, engraved with your product’s name. The wizard offers to make your model with you on the 30-minute call.

What are WebGL and three.js?

WebGL is the browser’s interface for drawing 2D and 3D graphics with the device’s graphics chip, inside a canvas element on the page, as MDN puts it. three.js is an open-source JavaScript library built on it that handles the scene, the camera, the lights and the loading of models. All four Promti kits are made with it.

Can a 3D website work well on a phone?

It can when the phone is planned for from the start: a lower drawing resolution, a scene framed for a tall screen, lighter files, and a page that still works without the 3D. A scene tuned only on a laptop tends to show its weight on a mid-range phone, which is why this list gives phones a part of their own.

Can Google read a 3D website?

It reads the words in the HTML, not what the scene draws, which is why the kits keep every heading, text and button in the HTML over the scene. What the 3D does to a page’s speed and its Core Web Vitals is in do 3D websites slow a site down.

Why can’t I change the scene in a kit?

Because the scene — its models, its light, its choreography, its phone version — is the part that took the time, and every buyer of the kit shares it. What changes is what makes the site yours: your words, colours and links and, depending on the kit, your model, photos, screenshots or project pictures. The download is plain HTML, CSS and JS and the licence lets you change anything, so a developer can take it further.