Mobile 3D websites: what should load first?

1. Design a useful opening view

Consider a fictional product page for an industrial component. It opens with the name, purpose, image, dimensions and enquiry action. The visitor can then choose to explore the model. This synthetic example makes the information needed before interaction explicit.

Decide whether 3D starts automatically, after the content or on request. Its role should guide that decision. A long unexplained loading state leaves the visitor waiting. An initial image with a clear control explains what the next action will do.

2. Give images different priorities

The main image visible when the page opens should not automatically receive the same loading delay as images further down. The web.dev guide recommends lazy loading for images outside the initial viewport. Declared dimensions help the browser reserve their space.

Inspect the transition from image to scene. The page should not suddenly change height or move the button a visitor is approaching. Check the crop on a phone too: a small file that hides an important detail does not serve the product page’s purpose.

3. Review the cost of visual detail

For the sample scene, record the models, materials, textures and effects loaded. Ask which details support the visitor’s decision. Compare a simplified version with the original using the same view so missing details are easier to identify.

MDN explains that WebGL limits and feature support vary between devices. Memory and texture dimensions also need attention. Download size alone does not establish smooth interaction. Check the running scene on the agreed phone instead of approving it from a desktop recording.

4. Try the journey during waits and failures

Scroll and reach contact while the model is still loading. Inspect what happens if the connection is interrupted or the scene fails to start. Keep an image and essential information available, with a clear explanation when needed.

Also try returning to a previously visited page. It may behave differently from a first visit, so record cached and uncached checks separately. A fast visit after repeated testing does not necessarily describe a new customer’s experience.

5. Use comparable test conditions

Record the page and version, phone, browser, connection and cache state. Repeat opening, reading, rotation and contact without changing the device and content at the same time. Note observed timings and interruptions, then repeat to identify variation.

Core Web Vitals describe loading, responsiveness and visual stability. Real-use data and laboratory tests answer different questions. One score does not replace checking the actual 3D interaction or establish the experience of every visitor. Where field data is unavailable, label the observations as tests rather than measured customer outcomes.

6. Turn observations into a decision

Use the results to decide what to change: defer the scene, remove an effect, prepare a better opening image or reduce specific assets. Preserve the details that make the product understandable. Keep the before-and-after record so a visual compromise has an explicit reason.

• Is essential content usable before the 3D scene is ready?
• Can visitors still reach contact while it loads?
• Which devices and conditions were actually checked?
• Which changes improve repeat checks without removing useful information?
• What issues remain, and what is available without the scene?

Explore an example

Explore how Ospivia’s homepage arranges text, content and its 3D scene. Use it to describe which information your brief should make available in the opening view.

Technical references

• web.dev: browser-level image lazy loading
• MDN: WebGL best practices
• web.dev: Web Vitals