Virtual tours on mobile: a practical checklist

A project link might arrive in a message, a search result or a brief conversation. Visitors often have no one beside them to explain it. The page needs to make sense on its own. If it takes too long to appear or the controls are confusing, a beautiful render cannot make up for the difficulty of using it.

The 2025 NAR report says that 69% of the US buyers surveyed used a mobile or tablet device to search for a home. That is not an estimate of AXIWALK’s audience in Iran, but it is a reason to take mobile use seriously. Source: Exhibit 3–2, page 52. Decisions for your own project should be based on the devices and behaviour of your actual audience.

What should appear first?

Show the project name, a short description and a clear way to start before the entire 3D scene is ready. Visitors should not face an empty screen. If loading is still in progress, explain that and keep the main information and a route back available. A progress percentage is only useful if it reflects the loading process.

Not every image and space has to load immediately. Some can be fetched when needed, depending on the design. Test this approach so that moving to the next area does not create long pauses. File size is only part of the picture: preparing and processing a model on the device also takes time.

Test touch controls separately

A control that feels natural with a mouse may be confusing on a small screen. Moving the camera should not be easily mistaken for scrolling the page. Put floor selection, back and close controls in predictable places, with short labels. Keep the introduction brief and let people dismiss it without losing access to the content.

• Can someone complete the main journey with one hand?
• Is it easy to close the floor plan and return to the previous position?
• Can visitors read Persian text and unit numbers without being forced to zoom?
• Does the tour behave sensibly in portrait and landscape?
• Does it still work after switching to another app and coming back?

Which performance measures are useful?

Google’s Web Vitals guidance defines good performance as LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, assessed at the 75th percentile of visits. These measures cover main-content loading, responsiveness and layout stability. Source: Web Vitals. A laboratory test does not replace data from real users.

For a 3D experience, also check how long it takes before the model is usable and how smoothly the main tasks work. Text may appear quickly while the model is still unavailable. The purpose is not simply to earn a score, but to understand where visitors have to wait between opening the link and reaching the space they want.

How do models and images affect performance?

Model complexity, texture sizes and rendering choices all affect resource use. MDN’s WebGL guidance includes advice on memory limits and differences between devices. Source: WebGL best practices. Prepare the web model for the visitor’s task. Detail that cannot be seen at the intended viewing distance may add processing cost without adding useful information.

Size still images for their display area and reserve their dimensions before they load, so the page does not jump. Assess renders separately from plans containing text. Heavy compression may make fine lines and numbers illegible. The small preview should load quickly, while a readable version remains available.

What if the 3D view doesn’t run?

Do not put essential project information exclusively inside the 3D scene. Keep text, plans or key images and a contact route available separately. W3C accessibility guidance calls for suitable text alternatives to non-text content. Source: Understanding WCAG criterion 1.1.1. Alternative text alone does not mean a tour meets every accessibility requirement.

An error message should offer a useful next step: view the project images, try again or ask for information. An obscure rendering-engine message gives most visitors little to act on. The enquiry form should work even if the model does not load.

A practical handover test

1. Open the link in the phone’s usual browser over mobile data.
2. Find a particular floor or space without spoken instructions.
3. Read the plan, return to the previous view and rotate the phone.
4. Leave the browser for a while, then come back.
5. Try the alternative information view and contact form.
6. Record the device, browser, network conditions and any problem you observed.

Use several devices that represent the intended audience, rather than a single phone. You can start by exploring the AXIWALK demo. Include target devices and acceptance criteria in your request for an estimate.

Sources and editorial note

1. NAR — 2025 Home Buyers and Sellers Generational Trends, Exhibit 3–2; US home-search tools
2. Google / web.dev — Web Vitals and the 75th percentile
3. MDN — WebGL best practices: compatibility and resource management
4. W3C WAI — Understanding SC 1.1.1: Non-text Content

Sources were reviewed on 13 November 2026. Unreferenced checklists and examples are editorial suggestions, not client performance reports or guarantees of results.