Plain glTF parsing or Draco/Meshopt decoding under a main-thread frame budget

Answer to the Core Question

For a typical three.js application running on modern browsers, plain glTF parsing is the safest choice for keeping the main thread within a per‑frame budget when the model contains < 200 k triangles. The parsing step is deterministic and does not introduce a CPU spike that could push a frame past the target (e.g., 16 ms for 60 fps). When the geometry is larger or the target device has a weaker CPU, offloading Draco or Meshopt decompression to a WebWorker becomes necessary to avoid frame budget violations.

Why Plain Parsing Wins for Small Models

• Deterministic timing: three.js’s GLTFLoader walks the JSON and builds BufferGeometry in a single pass.
• No decoder initialization cost: the loader does not need to load a separate decoder module.
• Network payload is larger, but for typical broadband connections the extra bytes do not affect the first frame.

When Compression Matters

• Draco/Meshopt reduce download size by 60–90 % for high‑detail assets.
• Decoding is CPU‑intensive; on a main thread it can consume 30–50 ms for 500 k‑triangle meshes.
• Three.js r139+ exposes DRACOLoader and MeshoptDecoder as separate modules that return promises for decoder initialization.
• Initializing the decoder once and reusing it across loads amortizes the one‑time cost.

Worker‑Based Decoding Pattern

1. Pre‑initialize the decoder in a hidden canvas or during a pre‑load phase.

   import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js';
   const dracoLoader = new DRACOLoader();
   await dracoLoader.setDecoderPath('https://cdn.jsdelivr.net/npm/three@0.139.0/examples/jsm/libs/draco/');
   await dracoLoader.init(); // one‑time cost

2. Create a WebWorker that receives the compressed ArrayBuffer.

   // worker.js
   self.importScripts('https://cdn.jsdelivr.net/npm/three@0.139.0/examples/jsm/libs/draco/draco_decoder.js');
   self.onmessage = async e => {
     const { arrayBuffer } = e.data;
     const geometry = await dracoLoader.decode(arrayBuffer);
     self.postMessage(geometry, [geometry.arrayBuffer]);
   };

3. On the main thread, post the ArrayBuffer to the worker and wait for the decoded geometry.

   const worker = new Worker('worker.js');
   worker.postMessage({ arrayBuffer: compressedBuffer });
   worker.onmessage = e => {
     const geometry = e.data;
     const mesh = new THREE.Mesh(geometry, material);
     scene.add(mesh);
   };

4. Schedule the mesh creation after the worker posts back. The main thread remains free to render frames while decoding happens in parallel.

Practical Verification Steps

• Wrap the loader’s onLoad callback with performance.now() to log the time spent in decoding.
• Measure the frame time of the first 10 frames after the model is added using requestAnimationFrame and performance.now().
• Compare the results for plain parsing vs. worker‑based compressed decoding on the target device.

Assumptions & Caveats

• Three.js version r139 or newer; older releases bundle decoders inside GLTFLoader, causing a larger one‑time penalty.
• WebAssembly decoder modules are available and loaded from the same origin or a trusted CDN.
• The model does not contain heavy non‑geometry assets (e.g., large textures or animations) that could still stall the main thread.
• WebWorkers cannot access the DOM; geometry data must be transferred via ArrayBuffer or structured clone.

Missing Diagnostic Detail

To refine the recommendation for your specific case, could you provide the approximate triangle count of the model and the target device’s CPU model or performance tier?