Some time ago, I was working on a 3D project with Three.js and ran into a very typical problem: the models displayed correctly, but the loading speed was slow, there was obvious stutter on the first screen, and interacting with the scene often caused frame drops.
At first, I also suspected things like lighting, shadows, or post-processing. But after actually looking into it, I found that a lot of the performance pressure was not really coming from the code layer, but from the models themselves. Once the number of models in the scene increased and the polygon count got higher, the problem became much more obvious.
In the end, performance issues in Three.js usually come down to two main areas:
One is that model transfer and loading are too heavy — the file size is large, so network download and browser parsing both take time.
The other is that the rendering stage is under too much pressure — because every model in the scene, no matter how near or far, is rendered at the same level of detail, the GPU keeps taking on unnecessary drawing work.
So when I run into this kind of problem now, I mainly focus on two things: Draco compression and LOD.
First, Draco
Draco is essentially a compression method designed for 3D geometry data. It is mainly used to compress things like vertices, faces, and normals in a model. What it solves is the problem of models being “too large.”
Loading Draco-compressed models in Three.js is not complicated either:
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js';
const loader = new GLTFLoader();
const dracoLoader = new DRACOLoader();
dracoLoader.setDecoderPath('https://www.gstatic.com/draco/versioned/decoders/1.5.6/');
loader.setDRACOLoader(dracoLoader);
loader.load('model.glb', (gltf) => {
scene.add(gltf.scene);
});
With this setup, the loader can automatically handle geometry data that has already been compressed with Draco. Compared with loading raw, unoptimized models directly, this approach is generally much more reliable in terms of file size and loading efficiency.
What problem does LOD solve?
LOD stands for Level of Detail. What it solves is not the problem of “large files,” but the fact that there is no need to keep rendering everything at the highest level of detail all the time.
For example, models close to the camera can use a high-detail version. But for distant buildings, equipment, or decorative objects, you can absolutely switch to lower-polygon versions instead. This way, the visual difference is usually small, but the GPU workload becomes much lighter, and the scene runs more smoothly and steadily.
Simply put, Draco is more about solving problems in the loading stage, while LOD is more about solving problems in the runtime rendering stage. The former makes model assets “lighter when they come in,” while the latter makes the scene “lighter when it runs.” Putting these two together is basically the core approach I use when optimizing models in Three.js.
Using Translight 3D to implement this solution
If you only need to process one model once in a while, it is still possible to use one tool for Draco compression and manually prepare a few LOD levels.
But once the number of models in a project grows, the problem becomes obvious. The whole workflow gets fragmented, and there is a lot of repetitive work involved.
For example, once a model is updated, you may need to compress it again, simplify it again, export different LOD levels again, and then recheck whether those assets still work correctly.
Handling all of that one by one manually can be pretty tedious. With Translight 3D, you can run through the whole process in one go, which makes things much more convenient.
It puts Draco compression and LOD generation into the same workflow. In other words, before a model even enters Three.js, the two core problems — “files being too large” and “rendering being too heavy” — are already dealt with in advance.
On the one hand, it can reduce geometry data size through Draco compression, turning the model into a lighter asset that is better suited for the web. On the other hand, it can also generate multiple versions of the model at different detail levels in advance for LOD usage. After this kind of processing, the model itself becomes much better suited for online scenes, instead of forcing Three.js to handle all the performance pressure directly.
So if we are specifically talking about lag caused by models in Three.js, a very practical workflow is this:
First, use Draco compression to reduce loading pressure. Then, use LOD to reduce rendering pressure at runtime. Translight 3D simply brings this optimization workflow together and lets you finish it all in one process, which saves both time and effort.
Top comments (0)