Optimizing 3D Model Loading and First‑Frame Rendering with Three.js, ZIP Packaging, and WASM Decompression

Author: Su Ning from the Vivo Internet Front‑End Team.

In 3D web projects, the time from page entry to model rendering is much longer than that of ordinary H5 pages, leading to significant user loss. Reducing the loading time is essential for improving first‑screen conversion rates.

Introduction

The team used Three.js to develop a Vivo avatar feature, allowing users to create and save a 3D avatar as a profile picture.

Optimization Idea

Understanding Three.js’s model loading workflow reveals the main bottlenecks: network request size and mesh parsing speed. The optimization strategy therefore focuses on reducing resource size and accelerating mesh parsing.

1. Reducing Model Size

1.1 Common Solution – Draco Compression

Draco compresses geometry by reducing vertex count, similar to image down‑sampling. However, it introduces problems such as possible mesh tearing, limited compression (e.g., a 50.7 MB model only shrinks to 49.5 MB), and a slow decoder in H5 environments. Consequently, the team abandoned Draco.

Caption: Model tearing after Draco compression.

1.2 Advanced Solution – ZIP Packaging

Packaging the GLB file into a ZIP archive dramatically reduces size (from 50.7 MB to 11.6 MB). Since Three.js’s GLTFLoader cannot load ZIP files directly, the loader was extended to intercept the fetched ArrayBuffer, detect a .zip suffix, and unzip it using JSZip.

To further improve decompression speed, a Rust‑based tool compiled to WebAssembly was used, reducing unzip time from dozens‑hundreds of milliseconds to about 1 ms.

2. File Encryption and Decryption

To deter easy extraction, a small portion of the file buffer is symmetrically encrypted. Decryption is performed in WASM after unzip and before serialization, identified by checking for the glTF marker in the decoded data.

Decryption overhead is negligible.

3. Optimizing First‑Frame Rendering

Two goals: reduce perceived page freeze and shorten the actual first‑frame render time.

3.1 Reducing Page Freeze

During model loading, a loading screen is shown. Because JavaScript runs on a single thread, any heavy processing blocks UI updates, making the page appear frozen. The solution is step‑wise loading: hide all meshes initially, then iteratively reveal each mesh and call render() , spreading the workload into many small frames.

While this improves perceived smoothness, total loading time remains unchanged, prompting deeper analysis of Three.js rendering.

3.2 Shortening First‑Frame Render Time

The avatar uses morph targets stored in geometry.morphAttributes . Each morph target duplicates the vertex data, so many morphs cause a large amount of vertex processing. Three.js traverses every morph target to create a Float32Array, which creates a performance bottleneck.

Solution: pre‑cache compiled shader results (similar to Steam Deck’s shader cache) and store them for each mesh. Additionally, move heavy JSON parsing of the decompressed glTF file to Rust/WASM, cutting about 0.5 s per model.

Result: first‑frame render time reduced from 7 s to 0.6 s.

Further observations: morph‑target cache adds ~80 MB (compressible to 15 MB). Parsing JSON remains the biggest cost; moving this to Rust yields additional savings.

Conclusion and Future Plans

The workflow compresses GLB files into ZIP, uses a WASM‑based unzip tool, and caches morph‑target data, achieving a model size reduction from 50 MB to 11 MB and a page‑load time drop from 15 s to 5 s. Future work includes integrating morph‑target caches directly into glTF (similar to gltf‑pipeline) and moving the entire serialization pipeline to WASM to further shrink model size and parsing time.