mixpanel-browser is huge! Maybe support tree shaking? What can be done?

[kazazor]

According to webpack-bundle-analyzer mixpanel-browser is huge!

This is the one of the biggest vendor packages we have and it doesn't make any sense to me.
To put it into perspective, this is moment.js:

This is even bigger tan moment, and moment is big!

I'm opening a discussion here with Mixpanel guys, how can we make it smaller?
can we support ES6 modules style in order to leverage tree shaking?
Any other ideas?

@jbwyme @ilyakamens @tdumitrescu any thoughts on the size of the package? is there any way we can decrease the size in the build step?

[jbwyme]

Totally in support of making the package size smaller. The mixpanel js library comes bundled with support for a number of different features like in-app notifications which bloats out the size. However, we should be able to restructure it a bit so that you can do more granular imports when using mixpanel-browser. I'll take a look at the work required to see if we can get some easy wins but as always PRs are welcome :)

@jbwyme awesome, thank you! It would be great to have a core package for mixpanel, and then extras like in-app notifications could be separate packages. i like the way lodash does this, where a single helper function is packaged.

[kazazor]

Thanks everyone for looking at doing that!

@baldwmic I actually disagree with the packages approach. This approach is kind of outdated and was replaced even in lodash.

In lodash instead of installing a specific package per function you can go ahead and do:

import get from 'lodash/get';
import remove from 'lodash/remove';
import isPlainObject from 'lodash/isPlainObject';

This way you don't need to go ahead and install each package and get your package.json so big.
More than that, doing that you actually able to share the different functions from different packages that uses lodash itself, which is very common. By doing so you're actually reducing the total size of your website. If you'll use individual packages, you'll make my life as a developer a little bit harder then just doing something like:

import X from 'mixpanel-browser/X';

I would suggest going with that option.

Tree shaking

In today's js frontend world, support for tree shaking is a must.
So instead of doing:

import X from 'mixpanel-browser/X';
import Y from 'mixpanel-browser/Y';
import Z from 'mixpanel-browser/Z';

I could do:

import { X, Y, Z } from 'mixpanel-browser';

tree shaking is really easy to have along side with commonjs support and it's just some babel configurations to add. You can take a look at lodash-es & react-router/es for reference..

IMO having both es support (tree shaking) along with commonjs in the same package (link react-router does) would be the best option. The other option like lodash-es does makes it harder to share common packages so I wouldn't go with that option.

WDYT? :)

ooh @kazazor i do like the idea of installing only one package and then just modifying the import statements, good point! that does seem much easier from a developer perspective.

i also agree that tree-shaking would be awesome! removing code that is not used will definitely help decrease the size of developer builds :)

[rubencodes]

So I was curious about this myself, but mostly because my gzip size comes out to 42kb (double what's loaded from the CDN, or what the OP has). Looks like our "stat size" is the same so not sure what might cause this...

[tdumitrescu]

Note that if your main concern is just reducing download size on pageload, then the CommonJS and other bundled/synchronous versions of the lib will never be as efficient as the standard snippet-loaded version (where you just add the embed code to your page). In that version, just the small minified embed code runs initially, and the rest of the lib is downloaded asynchronously without blocking, and will also be more cacheable than if it is included in the main bundle of an application.

[OllieJennings]

@tdumitrescu How about the idea of a mixpanel-lite package, which only contains say the code for tracking events, or something along those lines?

@tdumitrescu the problem with "installing" a package by embedding a script tag in html is that it's not very maintainable for our application. My team, and I'd be willing to bet many others, prefer to use npm / yarn to manage our dependencies. Is it not possible to create a liter version of the package like @OllieJennings suggested?

[tdumitrescu]

Yes, there would definitely be advantages to improving the modularization of the lib and building separate versions with different parts included. Until we find the time to implement it (or shepherd through an acceptable pull request), I was suggesting the embed code as a way to remove the pageload impact of the extra 40K gzipped bundle.

@baldwmic you can totally use npm/yarn to install mixpanel-browser and still use the embed code to load the lib asynchronously. The instructions are basically the same as for "Using Bower to load the entire library": point a script tag at the embed code downloaded with the npm package, and use the MIXPANEL_CUSTOM_LIB_URL var to point at the npm-downloaded lib src (at whichever URL your asset pipeline ends up making it available).

[matthewoates]

@tdumitrescu To elaborate on your earlier message:

Note that if your main concern is just reducing download size on pageload, then the CommonJS and other bundled/synchronous versions of the lib will never be as efficient as the standard snippet-loaded version (where you just add the embed code to your page). In that version, just the small minified embed code runs initially, and the rest of the lib is downloaded asynchronously without blocking, and will also be more cacheable than if it is included in the main bundle of an application.

Our main concern is JS execution time. Larger JS payloads, even if they're cached by the browser, impart a pretty significant first-pass performance penalty. (V8 can't do any optimizations on the first pass + parsing + JIT compilation)

see https://medium.com/reloading/javascript-start-up-performance-69200f43b201 for more info.

[tdumitrescu]

@matthewoates sure, parsing a larger blob of js will take more time before the Mixpanel lib starts firing off events, no doubt about that. My point about using the embed code is that parsing the lib in that case does not block pageload (it loads the lib asynchronously, and any mixpanel.track etc calls that you make until the lib loads are simply queued), and shouldn't measurably affect your page's startup time.

[fabiomcosta]

I think one good first step is defining what browsers should this library support.
Do we already have that?
With that in hand we might be able to do a nice cleanup on the utils.js module.

[fabiomcosta]

Created a PR to decrease its size #143
There is still a lot to be improved though, this is just the utils module.