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 analysis #42

Merged
merged 2 commits into from
Apr 27, 2019
Merged

Bundle analysis #42

merged 2 commits into from
Apr 27, 2019

Conversation

lucasconstantino
Copy link
Collaborator

@lucasconstantino lucasconstantino commented Apr 17, 2019

The current bundle is enormously heavy, mostly due to the GraphQL libraries used t compose the API.

Here are some stats:

Description Size
Before #38 646.58 KB
After #38 1.74 MB
After #38 without API 661.62 KB
After #38 without static introspected GitHub schema 939.63 KB

Whilst we can't move the API entirely to a backend, there are some things that could be addressed in order to decrease bundle size or increase performance in general:

@lucasconstantino lucasconstantino force-pushed the issue/42--bundle-analyzer branch from 1a2f26e to 8d451f4 Compare April 17, 2019 18:56
@lucasconstantino lucasconstantino force-pushed the issue/42--bundle-analyzer branch from 8d451f4 to 9e38662 Compare April 17, 2019 19:09
@lucasconstantino
Copy link
Collaborator Author

This pull-request consists only of the bundle analyzer setup. This is the current status for the points from above:

Precompile AST: will be addressed on #41, but only for client-side code (server-side/lambda benefits less from it);
Filter GitHub schema: as of #45, we've completely removed the need for introspection handling on the client-side, meaning this is no longer a problem to the bundle-size;
Tree shaking: should still be addressed, but represents less issue since #45

@dannytce
Copy link

Looks solid! :) But once you will merge #48 it's gonna be a bit redundant. We have there a build-in webpack-bundle-analyzer. Which seems to do exactly the same.

But I ran into this tweet from Mr. Abramov and it looks like source-map-explorer is more accurate. On the other hand, this tweet was posted two years ago...

Do you have any further details on which one is better and why? :)

@lucasconstantino
Copy link
Collaborator Author

I would go with the webpack one. Better analyseable, has gzip size and other meta info. This happens because that one happens during build process, while this one uses bundled files only.

Basically, webpack will eventually use this inside it's core, if I remember.

My choice here was no choice: without ejecting I would not be able to use the analyzer of webpack.

I think we should merge this, but add a comment to adapt to webpack's one on #48

@lucasconstantino lucasconstantino self-assigned this Apr 20, 2019
@dannytce
Copy link

@lucasconstantino ok, let's merge it and put a reference to #48 :)

@lucasconstantino lucasconstantino merged commit 2d16e5a into master Apr 27, 2019
@lucasconstantino lucasconstantino deleted the issue/42--bundle-analyzer branch April 27, 2019 02:28
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

Successfully merging this pull request may close these issues.

2 participants