A Visitor Opens Your 3D Showroom on Their Phone and Stalls on the First Screen
3D showroom slow to loadhow to fix slow web 3D loadingfirst screen of a 3D scenevirtual showroom loading stalls3D model slow on phone3D scene loading progressbrowser 3D performance3D virtual world base layerwebgl optimizationsource-available
The previous pieces talked about the technical side: how to compress models, how to tier detail, how to improve frame rates. This one moves to the other side — standing where the visitor stands, looking at the first thirty seconds after they open the link.
It gets its own piece because no matter how correct the technical work is, if visitors leave at the first screen, all of it was for nothing. And "the first screen" is exactly what a technical viewpoint is most likely to miss.
Stated upfront: Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D base layer that runs on your own server, and does not take showroom building projects or send a team to implement. Licensing: the source is available (source-available); it is free to run locally; online, commercial, or federated use requires a subscription license — exact terms live in the repo's LICENSE / EULA. Not repeated below.
1. What happens in the visitor's first thirty seconds
A visitor opens your 3D showroom link. You get one chance at their attention:
| Time | What they are doing | What your page is doing |
|---|---|---|
| 0–1s | Seeing what is on screen | Deciding what the first screen renders |
| 1–3s | Judging whether this is what they came for | The scene starts having content |
| 3–8s | Beginning to walk the first stretch | Assets arrive in batches |
| After 8s | They have already decided to stay or leave | — |
Every row in the timeline above maps to a concrete picture.
Above is a live desktop-browser view. Stated plainly: this is an in-development test world with no visual polish.
Above is a live phone-browser view: virtual joystick, voice, camera and jump controls, with a sign-in notice and a cross-world entry at the top. These two are two entrances to the same world — and the visitor is most likely opening the second one.
Look at the first row. That screen at 0–1s is what you are handing over as your single opportunity to introduce yourself. Its content decides the next three seconds.
And most 3D showrooms hand over one of three things on that screen: blank space, a progress bar, or a blurry texture.
2. Three ways to get the first screen wrong
Mistake 1 · The opening is blank
Cause: scene initialization has to load the renderer and parse the first batch of assets; until that finishes, the screen is empty.
Why it is fatal: blank reads as broken. A lot of visitors exit at this step, and they do not come back.
What to do: the first screen must have something in it. Even a placeholder scene — floor, a few rough silhouettes, a skybox — beats blank by an order of magnitude.
There is a counterintuitive part to this: the placeholder scene is not a temporary substitute; it is itself the content of the first screen. A visitor seeing "there is a space here, detail is loading" is far more reassured than one seeing blank or a progress bar.
Mistake 2 · The opening is a blurry image
Cause: to "look fast," an image is placed up front as a cover, later replaced by the real scene.
Why it is fatal: it makes a false promise. The visitor assumes this is how the finished thing looks, and when the real scene arrives they think it is worse than the image they just saw.
What to do: no fake cover. Either it is a real scene (even a simplified one), or it is clearly a loading state. The worst option is pretending to be done.
Mistake 3 · The progress bar sticks at one number
Cause: loading happens in batches with pauses between them, while the progress bar is computed from bytes downloaded and does not reflect real progress.
Why it is fatal: a client watching 30% stall for ten seconds is more alarmed than one watching 30% → 50% → 70%. The latter at least shows movement.
What to do: progress should be monotonic, continuous, and finish. Slower is fine; freezing on a number is not.
⚠️ One more detail: how much has to load before there is anything to see and how long full load takes are two different metrics. The second decides how long he waits; the first decides how long he is willing to wait. The one that affects retention is the first.
3. The first screen is not the same on phone and desktop
Your visitor is most likely on a phone. That deserves separate treatment.
| Desktop | Phone | |
|---|---|---|
| Network | Relatively stable | Noticeably variable |
| Processing power | Strong | Weak |
| Small screen | No | Yes → limited field of view |
| Input | Mouse and keyboard | Touch, no hover |
| Patience | Slightly higher | Lower |
Several direct consequences:
- The first screen should hold less content on phones. A small screen cannot fit much; filling it means having no focus
- It has to work in portrait. Either handle portrait natively or ask them to rotate — do not make them turn the phone first
- Touch has no hover. Anything shown on hover (specs, descriptions, QR codes) simply does not exist on a phone
- Weak-network behavior must be tested separately. Load times measured on a computer on Wi-Fi do not apply to a phone on 4G
⚠️ Emphasizing that last one: using desktop load time to infer phone load time is the most common form of optimism in this kind of project. The gap between the two scenarios is often larger than people expect.
4. Three improvements you can make right now
If time is short, do these three. None requires a rewrite — only reordering and strategy.
One: get the picture up before the detail arrives.
Do not wait for every asset before showing the scene. Layer it: the first layer (rough silhouettes, floor, building masses) appears fast, the second (model detail, textures) replaces it after. The visitor can start walking at layer one.
Two: make "loading" into a scene rather than a notification.
Use placeholder geometry to stand in for models that have not loaded. The benefit is that visitors can see how big the space is and what is in it, and loading merely swaps the placeholders out. The feel and the psychology of waiting are completely different.
Three: give an explicit next step.
Once the first screen is up, the visitor needs to know where to go. One entrance, a start button, a suggested route — any clear next step beats standing in the middle of a scene with nothing to do.
5. How to know whether the first screen works
Not by load speed. By visitor behavior.
| Metric | What it tells you |
|---|---|
| First-screen dwell time | Too short means blank/blurry/empty |
| Immediate exit after entering | The opening did not match expectations |
| Whether movement starts at the first screen | Standing still means they do not know where to go |
| Still online after the second screen | They are truly retained only past the first screen |
⚠️ A counterintuitive reminder: making loading faster does not necessarily improve these metrics. If the visitor does not know what to look at once inside, speed does not help. What the first screen has to solve is not "how fast it appears" but "whether there is anything to look at once it does."
6. Boundaries worth stating plainly
- This piece describes mechanisms, not our measured numbers. We have measured data on the rendering and loading side (draw calls, loading strategy, placeholder field), but "how long the first screen takes on a given phone for a given showroom" depends on model and scene scale and has to be measured on the actual target devices.
- Full mobile behavior requires real-device verification. We can describe the mechanism; we cannot substitute for testing on your target models.
- This piece is about experience and retention, not a conversion promise. Faster loading does not directly mean more deals — content quality and fit with the need sit in between.
FAQ
Q: How many seconds of loading is acceptable?
A: No numbers, because they depend on model scale and device variance. But there is one structural requirement: "time until something is visible" must be far shorter than "time until fully loaded." If those two are close, your loading is not layered.
Q: Should I add a loading animation?
A: Fine — but do not cover the screen with a full-screen animation. Letting visitors watch the scene take shape is more reassuring than showing them a spinner.
Q: Do I need a separate mobile build?
A: Not a separate world, but mobile-specific adjustments: less first-screen content, working portrait, touch interaction, no hover dependency.
Q: What belongs on the first screen?
A: A real, simplified scene. Not a hero-angle rendering, and not a pure placeholder. "The space looks roughly like this, detail is coming."
Q: Does the progress bar need to be accurate?
A: It does not need to be accurate, but it must be continuous and finish. A rough progress bar that completes is far more useful than an accurate one that stalls.
Q: How do I know whether visitors are leaving at the first screen?
A: Look at first-screen dwell time and the immediate-exit rate. These two say more about the opening than load time does.
Source & Repositories
The three mirrors are identical; the first two are faster inside China. The repos include deployment docs and a set of acceptance scripts you can run yourself to see the measured numbers.
- Gitee (fastest in China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (China mirror): https://gitcode.com/qq_35054471/virtual-world
- GitHub: https://github.com/miduo100/3d-virtual-world
About Genesis
Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.
Caring about what a client sees in the first second? Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D virtual scene base layer that runs on your own server — on the loading side: layered delivery gets the picture up first (distant models use simplified versions, near ones are replaced once loaded), placeholder geometry stands in for content still loading, and progress moves continuously to the end. Clients adapt by capability tier — PC, phone, tablet, and XR from one codebase. The source is available; run it locally free of charge; online, commercial, and federated use require a subscription license. Search "Genesis Virtual World CRM" to find the site with a walkable demo world.
About the name: Genesis in this article is the same self-hosted 3D virtual world product also called the Genesis Virtual World CRM. If "Genesis" does not find us, search "Genesis Virtual World CRM".