# Browser crashes when loading large files (dxf, glTF, etc.)

**URL:** <https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309>\
**Category:** Questions\
**Tags:** memory, performance\
**Created:** [July 26, 2023, 9:00am UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309 "2023-07-26T09:00:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yan\_Zexuan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/yan_zexuan/32/38490_2.png) [@Yan\_Zexuan](https://discourse.threejs.org/u/Yan_Zexuan)\
**Post date:** [July 26, 2023, 9:00am UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/1 "2023-07-26T09:00:51Z")

</div>

We are using three.js to load 2d/3d models in BIM domain, like dxf (converted from dwg), glTF/glb, etc. When there are too many entities, browser crashes. Of course, it depends on what devices/gpus we are using.

Now I’m thinking to reduce the memory three.js uses, for one of my dxf file (1M+ entities, drawcall 20000+), log shows:

- totalJSHeapSize: 1630.15M
- usedJSHeapSize: 1564.05M  
We already merged entities together for the same type and material. Since we don’t use objects’/materials’ uuid at all, can I simply don’t generate UUID for them? As I tried, everything works fine. Do you know any side effect? And please let me know if there is other ideas. Thanks!  
Our [example](https://pattern-x.github.io/gemini-viewer-examples/)and [sample code repo](https://github.com/pattern-x/gemini-viewer-examples):

### Reproduction steps

1. Open [online sample page](https://pattern-x.github.io/gemini-viewer-examples/#/Upload_your_local_dxf)
2. Upload a dxf file ([this one](https://github.com/pattern-x/gemini-viewer-examples/blob/a141d48417dbd0c7912538537d51bb48b0e07183/public/demo/models/dxf/building_1_2.dxf) is sort of large, but there are others much larger)

It is more likely to happen on mobile devices.

---

<div class="post-metadata">

**Author:** ![mjurczyk](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mjurczyk/32/10995_2.png) [@mjurczyk](https://discourse.threejs.org/u/mjurczyk)\
**Post date:** [July 26, 2023, 9:30am UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/2 "2023-07-26T09:30:55Z")

</div>

> [@Yan\_Zexuan](#):
>
> merged entities together

1. For large models not only does that not help (you’re not really reducing the size of the memory used - at best it’d reduce the amount of draw calls, but draw calls aren’t crashing tabs, they just freeze them.), it may actually cause more issues, since merging multiple objects into a single geometry prevents frustum culling. So you’ll effectively be rendering absolutely everything at any given moment, regardless if it’s visible to the camera or not.

> [@Yan\_Zexuan](#):
>
> happen on mobile devices

1. Mobile devices (esp. iOS before [this happens](https://twitter.com/onirenaud/status/1679656244024590336)) have very strict memory limits. There’s no way to increase these limits for WebViews, so the only solution would be to limit the rendered / visible / stored-in-the-memory objects.

2. For large-scale models, you have to take into consideration that WebGL / three.js is simply not as powerful as native 3D apps like UE / Unity. Use LODs and spatial indexing to limit large worlds and models to only the parts that are essential for the user to see - and if there’s memory / rendering capacity left, only then render the fancy stuff. Also - [consider imposters](https://discourse.threejs.org/t/about-dynamic-imposters/27330), they look convincing and are essentially a texture-representation of 3D models.

---

<div class="post-metadata">

**Author:** ![donmccurdy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/donmccurdy/32/33209_2.png) [@donmccurdy](https://discourse.threejs.org/u/donmccurdy)\
**Post date:** [July 26, 2023, 12:24pm UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/3 "2023-07-26T12:24:53Z")

</div>

Do you have the option of optimizing these models offline? Or do they need to be loaded in the browser as-is, and any optimization happens clientside?

---

<div class="post-metadata">

**Author:** ![Yan\_Zexuan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/yan_zexuan/32/38490_2.png) [@Yan\_Zexuan](https://discourse.threejs.org/u/Yan_Zexuan)\
**Post date:** [July 26, 2023, 3:56pm UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/4 "2023-07-26T15:56:10Z")

</div>

Right, merge mainly reduces draw call. Well, it also reduce memory cost because each object takes some memory, it is a trouble when there are too many entities. And, ture that it prevents frustum culling, so we don’t merge everything together.

The imposter sounds interesting, I’ll consider. Many thanks!

---

<div class="post-metadata">

**Author:** ![Yan\_Zexuan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/yan_zexuan/32/38490_2.png) [@Yan\_Zexuan](https://discourse.threejs.org/u/Yan_Zexuan)\
**Post date:** [July 26, 2023, 3:58pm UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/5 "2023-07-26T15:58:26Z")

</div>

We actually do have the option to optimize them offline, if there is good idea… E.g., We can do merge offline, rather than merging in the browser.

---

<div class="post-metadata">

**Author:** ![Umbawa\_Sarosong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/umbawa_sarosong/32/30107_2.png) [@Umbawa\_Sarosong](https://discourse.threejs.org/u/Umbawa_Sarosong)\
**Post date:** [July 27, 2023, 1:12am UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/6 "2023-07-27T01:12:05Z")

</div>

use the draco loader to load compressed gltf and dispose unnecessary components in large gltf model by taking the buffer geometry from gltf models and merging it into one mesh and disposing identical materials into single materials, this will drastically reduce your model size in ram.

see demo below of a simple small island city with large gltf models compressed into buffer geometries.

see [demo](https://virtucities.web.app)

to make your project work offline use service workers to allow users or players explore your **threejs** project offline.

---

<div class="post-metadata">

**Author:** ![donmccurdy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/donmccurdy/32/33209_2.png) [@donmccurdy](https://discourse.threejs.org/u/donmccurdy)\
**Post date:** [July 27, 2023, 4:01pm UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/7 "2023-07-27T16:01:57Z")

</div>

I would suggest not worrying about Draco compression until the model renders efficiently in the browser first. Draco compresses the model over the network, but the whole thing must be decompressed in the browser memory before rendering, so your FPS isn’t going to get any better. The strongly preferable approach would be to reduce the complexity of the model (offline), compress it (offline), and then the loading and rendering will perform much better.

There is no one-size-fits-all method to optimize every possible file, you especially need to think about how much of the cost is draw calls, vertex count, texture memory, etc. But a good starting point for glTF models would be:

```javascript
npm install --global @gltf-transform/cli

gltf-transform optimize input.glb output.glb --compress draco --texture-compress webp

```

There are a number of options (see `--help`) if you need to tweak anything.

---

<div class="post-metadata">

**Author:** ![Yan\_Zexuan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/yan_zexuan/32/38490_2.png) [@Yan\_Zexuan](https://discourse.threejs.org/u/Yan_Zexuan)\
**Post date:** [July 28, 2023, 1:24am UTC](https://discourse.threejs.org/t/browser-crashes-when-loading-large-files-dxf-gltf-etc/54309/8 "2023-07-28T01:24:22Z")

</div>

Thank you, donmccurdy! If gltf-transform can reduce the complexity of model and texture, that maybe helpful to me. I will have a try later.