2d-inc / Flare-JS

Flare Javascript ES6 runtime with Canvas rendering.

Home Page:https://flare.rive.app

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

bundle size is relatively large

shrugs opened this issue · comments

The minified bundle size is very large (a whopping 8.5Mb non-gzipped), which makes its inclusion on the web a hard sell. Eye-balling the Flare.min.js, it looks like the embedded canvaskit wasm is a large part of this bundle size.

Any tips on cutting this down beyond the basics? This gzips to like 3.5Mb, but that's still a ton of javascript.

image

When we made the decision to go with CanvasKit, we knew this would be the biggest cost.

We originally had a version that used the Canvas 2D context for rendering, but the features we currently support (and the new ones we're working on) require a more advanced renderer.

We are compiling an already slightly slimmed down version of CanvasKit, but we think there are quite a few more things we can probably strip out. We'll be taking a look at this soon.

Understood!

Perhaps a workaround mechanism is to have non-animated svg fallbacks, async-require the Flare.min.js, cache it heavily, and then upgrade those svgs into animated ones onload.

Any other suggestions for the meantime?

That's a really cool idea, I think it would require a little setup (like indicating which animation you want to build the svg preview from).

If you don't need deformed meshes/images, it shouldn't be too much work get our original Context 2D implementation working again. The biggest other missing feature would be trim paths, but again that wouldn't take too long to get working there either.

Using webpack 4.20.1 optimization on current head of master, I manage to reduce the build size by close to 11 kibi ! 😄

This optimization is as easy as adding

	optimization: {
		usedExports: true,
	},

Into the webpack config object literal in webpack.config.js

Flare.min.js size in octets without optimization Flare.min.js size in octets with webpack optimization
7358031 7346808

This may be an interesting path to reduce the overall size of the build significantly. But it will involve a scan on all the required module to make sure they are tree shakable (see webpack tree shaking guide for an in-depth explanation).

By the way, I tested this reduced build against the provided example and the Trim animation and it works as expected.

I have tried. But no luck.