Why 3D is harder on a phone
A 3D scene is built and approved on a designer's powerful computer with a fast connection and a large screen. Most of your visitors will meet it on a phone that is several years old, on mobile data, with a dozen other apps open and a battery saver switched on. The gap between those two machines is where 3D websites fail.
On a phone, the download is slower, the graphics chip is weaker and shares its memory with everything else, sustained work makes the device hot and the system slows it down in response, and the browser may discard a page that uses too much memory. None of this prevents good 3D on phones. It means performance has to be a requirement from the first day, with numbers attached.
Set budgets before design begins
| Budget | What it limits | Why it matters |
|---|---|---|
| First view | Time until the visitor sees meaningful content and can scroll | Visitors leave before a slow page finishes. Search engines measure this too |
| 3D download size | Total bytes of models, textures and code for the first scene | Sets the wait on mobile data |
| Time to interactive 3D | From page load to a scene the visitor can rotate | Long waits need a designed loading state, or a lighter scene |
| Frame rate | Frames drawn per second during interaction | Below a smooth rate, rotation feels broken |
| Memory | Peak memory used by the page | Exceed it and the browser reloads or closes the page |
| Responsiveness | Delay between a tap and a visible response | Heavy scripts make the whole page feel frozen |
Agree the figures with your developers for a named reference device: a specific mid-range Android phone and an iPhone a few generations old, on a throttled mobile connection. Budgets without a reference device are opinions. Write them into the project requirements and check them at every review.
Load the page first, then the 3D
- 01
Show content immediately
Headline, text, navigation and a still image of the 3D scene should appear without waiting for any 3D code. The page must be useful before the scene arrives.
- 02
Use a poster image
A rendered picture of the scene in its starting state fills the space. When the 3D is ready it takes over in the same position, with no jump in layout.
- 03
Load 3D only when needed
If the scene is below the first screen, start loading as the visitor scrolls toward it. If it needs a tap to start, wait for the tap.
- 04
Load in stages
A light version of the model first, with finer detail, extra textures and optional parts following.
- 05
Prepare shaders without freezing
Compiling the programs that draw materials can stall a phone for a noticeable moment. It should happen in the background, before the scene is revealed, not on first touch.
- 06
Show honest progress
For a wait of more than a moment, a real progress indicator and something to read. Never a blank area.
- 07
Cache sensibly
Returning visitors should not download the same models again.
Google's page experience measures include how quickly the largest element appears, how stable the layout is and how quickly the page responds to input. A 3D scene that blocks any of these can affect how the page is assessed, as well as how it feels.
Keep models and textures small
- Geometry. Reduce triangle counts to what is visible at the closest view, and compress the geometry data. Remove anything the camera never sees.
- Textures. Usually the largest share of both download and memory. Use the smallest dimensions that hold up, share textures between objects, and deliver them in compressed formats that graphics chips can use directly.
- Number of separate objects. Each separately drawn object costs time per frame. Merge parts that never change and reuse repeated ones.
- Materials. Few, simple materials draw faster than many complex ones. Transparency, refraction and layered effects are expensive on phones.
- Lights and shadows. Real-time shadows are among the costliest features. Bake lighting into textures where the scene allows, and limit dynamic lights.
- Effects. Full-screen effects such as blur, glow and depth of field multiply the work per frame. Reduce or remove them on phones.
- Resolution. Phone screens have very dense pixels. Drawing at a capped resolution, slightly below the screen's maximum, often goes unnoticed and saves a great deal.
Our guide to preparing 3D product assets for a website covers how models are made light in the first place.
Hold the frame rate, memory and battery
- 01
Does it draw only when something changes?
What to requireA static scene should not redraw continuously. Drawing on demand saves battery and keeps the phone cool.
- 02
Does it pause when out of view?
What to requireWhen the scene scrolls off screen or the tab is hidden, animation and drawing should stop.
- 03
Does it adapt to the device?
What to requireMeasure the frame rate in the first seconds and lower quality automatically, by reducing resolution, effects or detail, if the device struggles.
- 04
Is memory released?
What to requireModels and textures for options no longer shown should be freed. Leaks show up as a crash after a few minutes of use.
- 05
What happens over ten minutes?
What to requirePhones slow themselves down as they heat. A scene that is smooth for thirty seconds may stutter after sustained use. Test for duration.
- 06
Does the rest of the page stay responsive?
What to requireScrolling, menus and buttons must keep working while the scene loads and runs.
A worked example
A watch brand's product page
This example is invented to show budgets catching a problem early. A watch brand commissions a product page with a 3D watch that visitors can rotate and whose strap they can change.
- BudgetsAgreed against a named mid-range Android phone on a throttled connection: page content visible within two seconds, 3D interactive within six, a smooth frame rate while rotating, and no reload in ten minutes of use.
- First buildOn the designer's laptop it is flawless. On the reference phone the 3D takes nineteen seconds to appear, the page freezes for two seconds when first touched and the browser reloads the page after four minutes.
- CausesTextures were four times larger than the phone could show. Every strap was loaded at the start. Materials were compiled on first touch. Strap textures were never released.
- FixesTextures are resized and compressed. Only the default strap loads at first. Shaders are prepared in the background behind a poster image. Unused straps are freed. Reflections are simplified on phones.
- ResultThe page shows at once with a poster, the watch becomes interactive in about five seconds and it runs for ten minutes without trouble. Older phones below a threshold receive a sequence of rendered images to swipe through instead.
Because the reference phone was tested at the first review, the problems cost a week. Found after launch, they would have meant most mobile visitors never seeing the watch at all.
Fallbacks, touch and accessibility
Considerate 3D
- A still image or image sequence where 3D cannot run or fails to load
- Vertical scrolling always works, even with a finger on the scene
- Rotation needs a deliberate gesture, with a visible hint
- Reduced motion preferences are respected
- Key information is also in text, for people who cannot use the 3D view
Inconsiderate 3D
- A blank area or an error when graphics support is missing
- The scene traps the scroll, and visitors cannot get past it
- Autoplaying motion with no way to stop it
- Essential product facts available only by exploring the model
- Controls too small for a thumb
Touch deserves particular thought. A finger dragged across the screen might mean scroll the page or rotate the object, and the page must guess. A common answer is to let vertical drags scroll and horizontal drags rotate, or to require a tap to enter an interactive mode with a clear way out. Try it one-handed on a small phone.
Test on real phones, all the way through
Desktop browser tools that imitate a phone change the screen size and slow the network. They do not imitate a phone's graphics chip, memory limits or heat. Only real devices show those. Keep the reference phones on the desk of whoever reviews the work, and look at every build on them from the first prototype.
Test on both major mobile platforms, since their browsers differ in graphics behaviour and memory limits. Use mobile data as well as office Wi-Fi. Measure with a fresh browser profile so that nothing is cached, and confirm that the page under test really is the new build. After launch, collect performance data from real visitors, which reveals devices and conditions no test lab covers.
The mobile 3D performance checklist
Mobile 3D performance checklist
0 of 11 checkedWhat to do next
Open your current or planned 3D page on the oldest phone in the office, on mobile data, and time how long it takes before you can read something and before you can interact. Use it for five minutes. What you experience is closer to your typical visitor than anything seen on a studio monitor.
Our 3D website development and website performance optimization pages explain how we build and tune 3D for phones. Send us a page that concerns you and we will tell you what we measure.
Common questions
Can interactive 3D really work well on phones?
Yes, on most reasonably recent phones, when it is built for them: small models, compressed textures, staged loading, limited effects and quality that adapts to the device. It does not work when a scene made for a desktop is simply shown on a phone. Decide at the start that phones are the primary target and test on them throughout.
Will a 3D scene hurt our search visibility?
Not by itself. Search engines assess the page's content and its measured experience: how quickly the main content appears, whether the layout shifts and how responsive it is. A scene that delays or blocks those can count against the page. Showing content and a poster image first, and loading 3D afterwards, avoids the problem.
What should visitors with old phones see?
A fallback that still presents the product well: a high-quality image, a swipeable sequence of rendered views or a short video. Detect lack of graphics support and poor measured performance, and switch automatically. A visitor who sees good pictures has lost little. One who sees a blank space or a frozen page has lost everything.
Which phones should we test on?
At least one mid-range Android phone a few years old and one older iPhone, since those represent a large share of real visitors better than current flagship models. Check your own analytics for the devices your audience uses. Add a small-screen phone for layout and touch, and test on mobile data as well as Wi-Fi.
Why does the page crash after a few minutes on some phones?
Usually memory. Mobile browsers limit how much a page may use and reload or close it when the limit is passed. Large textures are the commonest cause, followed by assets that are loaded for each option and never released. Reducing texture sizes, using compressed formats and freeing unused assets normally resolves it.
