Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bundle size is relatively large #21

Open
shrugs opened this issue Apr 16, 2019 · 5 comments
Open

bundle size is relatively large #21

shrugs opened this issue Apr 16, 2019 · 5 comments

Comments

@shrugs
Copy link

shrugs commented Apr 16, 2019

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

@luigi-rosso
Copy link
Contributor

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.

@shrugs
Copy link
Author

shrugs commented Apr 16, 2019

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?

@luigi-rosso
Copy link
Contributor

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.

@tetedacier
Copy link

tetedacier commented Dec 19, 2019

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.

@prosenjit-manna
Copy link

I have tried. But no luck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants