How to improve webapp load performance, and interact with the three.js file in an optimal way

Questions
1

I have a webapp that is intended for mobile.
I ran Chrome devtools Audit on it with settings: Mobile and Simulated Slow 4G, 4x CPU Slowdown
The Performance is poor - specifically the measure First Contentful Paint
The first suggestion in the Opportunities section is to Eliminate render-blocking resources

One of the main js files that takes time to load is threejs, which is required for the first page, so it is in the critical path.
If I add defer to when loading the script, I get errors while loading the first page.

I am already using the minified version three.min.js and also serving it compressed with gzipped (as well as other .js, .html, .css files).
The coverage section shows that only a small part of three.js is used (as expected).

Is there a way to break the file three.js into smaller pieces, and load only the code that is in the critical path?
How can I farther optimize the load of the three.js file?

Thanks,
Avi

2

Unfortunately, it’s not yet possible to import only the classes from the three.js lib which are actually used in a project. This kind of dead-code elimination is called tree shaking and not yet supported by three.js. More information about this topic right here:

3

Are you sure that just loading and parsing the three.js library is what’s slowing your app down? If “first contentful paint” requires that you actually render something on the page using three.js, you may want to look at what time is being spent loading additional resources (models? textures?) after the three.js library has loaded but before it can render.

If you’re able to (ideally) share a demo, or do some profiling in developer tools like the Chrome Network or Performance tabs, that would help to narrow down exactly why your load time is not as good as you’d like.

If I add defer to when loading the script, I get errors while loading the first page.

I think you’ll need to share your code to get help with this. The error means your application expects three.js to be available immediately and is trying to use it too early.

4

Thanks @Mugen87 and @donmccurdy for explaining about “tree shaking” and pointing for ways to check the reason for the slow-down.

I improved the “First Contntful Paint” measure, by importing modules from Javascript modules, instead of loading all the Javascript resources from the main html page.
It turns out that loading and parsing the three.js library is not the main reason for the slow-down, even
though the entire three.js module is loaded when importing specific three.js modules.

Is this issue the correct place to track the status of tree shaking capability in tree.js?

Thanks,
Avi

5

My understanding is that tree-shaking three.js can be done now, but is not easy yet. See Tree Shaking Three.js for details.

6

That was my thread. I forget how to strip out unnecessary shader files again. I think its a hack in the gsl filter. I would like to know how to strip them out.

I have a couple of examples. I found if you import from a module its bloaty, you need to hand pick exports from source to a module. Then import that custom module.

Then export what you need from the custom module

This imports and exports everything and bundles it with other stuff.

Include paths plugin enables resolving custom paths and modules. I use it to override and resolve local path before three for my webgpu renderer fixes. three-troika/three.rollup.config.js at 68a0f952482cc0376ca766f0f9da0c93ff1d2c86 · danrossi/three-troika · GitHub