Why the rendered avatar was too heavy for mobile

The mobile limitation was a product result of the Avashi engagement: the rendered version was too heavy for the intended phones. The retained files let us inspect some contributing costs, even though they do not provide a standardized frame-rate benchmark across named devices.

The useful response is to separate transfer, decode, graphics memory and per-frame work. Reducing one can leave the others almost unchanged. An asset that downloads quickly can still overheat a phone, while a small vertex count can coexist with expensive textures and materials.

What the asset inspection measured

The September 2026 inspection read glTF JSON from local GLB/VRM binaries. It recorded file bytes, primitives, materials, image entries, position-accessor counts and morph-target counts. It did not run the renderer or infer GPU timings from file size.

The stylized pair’s reduction is approximately 37.2% in file bytes. Both files retain a summed position-accessor count of 43,988. This does not isolate which optimization caused each saved byte, and it does not establish a 37.2% runtime-speed improvement.

The asset table is available as a sanitized measurement record. Proprietary meshes and textures are not included.

The first budget is network transfer

A 62,421,180-byte file contains almost 499.4 million bits. At an ideal sustained 10 Mbit/s, transfer alone takes about 49.9 seconds. Protocol overhead, congestion and startup add time; a warm cache can remove much of it. Both cold and warm sessions therefore need separate measurements.

Compression affects this stage directly. So do progressive loading, a lower-detail initial representation and deliberate cache policy. A static portrait or text interface can keep the conversation usable while a larger visual asset loads, provided the interface does not imply that the character is ready before it is.

Compressed textures are not GPU texture memory

For an uncompressed 2,048 × 2,048 RGBA8 texture, the base level is 16 MiB. A full mip chain adds roughly one third, yielding about 21.33 MiB. Eight such textures would occupy roughly 170.7 MiB before render targets, geometry, audio, JavaScript and browser overhead.

That is a worked resource calculation, not a statement that the inspected avatar had exactly eight textures at that size. The file’s image count alone does not establish dimensions, channel format or the driver’s final allocation.

JPEG, PNG or WebP can reduce transfer bytes while still decoding into a larger pixel allocation. GPU-native texture compression can change the residency cost, but requires compatible assets and loader support. The optimizer and browser must agree on the format and its declarations.

Morph targets add another budget

A dense position-only morph target needs three values per affected vertex. For the FLAME face and 52 targets:

5,023 vertices × 3 coordinates × 52 targets × 4 bytes
= 3,134,352 bytes ≈ 2.99 MiB

Normals and tangents can add more. Sparse targets reduce stored data when few vertices move, but setting small values to zero does not itself guarantee a sparse binary encoding. The exporter must actually write that representation.

Similarly, rounding positions onto a 16-bit grid and returning float32 arrays reduces precision without automatically reducing their byte width. The inspected optimization code made this distinction worth checking at the export boundary. Measure the resulting accessors and buffers, not only the function name.

Pixel ratio multiplies fragment work

Some Avashi viewers capped device-pixel ratio at two, enabled antialiasing and used environment lighting; the shared canvas defaulted to shadows. These are reasonable quality-oriented settings, but they compete for a mobile frame budget.

A 390 × 844 CSS-pixel viewport at pixel ratio two renders 780 × 1,688 pixels: four times the pixel count at ratio one. Post-processing and multisampling can multiply work and memory further. Reducing polygon count alone cannot solve a fill-rate bottleneck.

At 60 fps the frame interval is about 16.7 ms; at 30 fps it is 33.3 ms. Animation, scene updates, rendering and browser work all share the interval. Averages can hide visible spikes during asset upload, garbage collection or context reconstruction.

Profile the complete conversation

Run the same session on the chosen low-end and mid-range devices: cold load, a spoken exchange, interruption, background/resume and ten minutes of sustained use. Record frame-time distributions, dropped or late audio, crashes, context loss and degradation over time.

A proposed first mobile profile could cap pixel ratio at one, target 30 fps, disable dynamic shadows and expensive post-processing, use a reduced material set and render on demand while idle. These are starting controls to test, not a claim that this profile already passed on a phone.

The reference mobile acceptance profile makes those choices explicit. Record actual device results before promoting it from candidate to supported configuration.

Optimize in the order the trace supports

If startup dominates, work on transfer and decoding. If frame time is dominated by transparent hair and lighting, simplify those features. If morph processing is expensive, reduce active controls and preserve only the necessary targets. If memory grows across sessions, investigate disposal and ownership before reducing visual quality again.

Keep a before-and-after trace with the same device and scene. Otherwise a smaller file or smoother desktop demonstration can be mistaken for a mobile fix.

The project’s lesson was not that interactive avatars cannot run on phones. It was that mobile feasibility has to govern the asset and rendering contract early enough to influence the product being built.