This repository has been archived by the owner on Apr 13, 2023. It is now read-only.
Add a basic example app bundled with Rollup. #2839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The goal of this application is to get a precise, real-world measurement of the total bundle footprint of essential Apollo Client and React Apollo packages, using a modern bundler, including the weight of dependencies (excluding react and react-dom), but also taking into account the overlap between shared dependencies, which is not possible with per-package tools like https://bundlephobia.com/result?p=apollo-client@2.5.1. If you run npm install npm run analyze in this application, you'll see a breakdown of everything in the bundle that we think should be attributed to using Apollo Client and React Apollo. The current total stands at about 143KB (minified but *not* compressed with gzip, since that's how source-map-explorer works). After gzip, the total is about 39KB. Of that 143KB, apollo-client is the biggest single offender, at 39.5KB, followed closely by graphql, at 31.6KB. If we included react-dom, it would weigh in at 106KB, but there's not much we can do about that, so we don't bother measuring it. By contrast, Apollo can pick and choose what it imports from the graphql package, so the graphql package is worth measuring, even though it's not maintained by Apollo. I welcome anyone and everyone to examine the measurement methodology we're using here, because early feedback about any inaccuracies will make this application much more useful for deciding where and how to invest future bundle reduction energy. Likewise, I hope the analysis produced by this application will inspire grounded discussion of potential bundle reduction strategies, in addition to helping validate them.
|
For the sake of comparison, if you go back by a minor version ( In other words, we've reduced the bundle size contribution of Apollo Client and React Apollo by 27% since we started focusing our attention on this effort! For more details about the techniques we've tried, see #2743 and apollographql/apollo-client#4324. I'm not sure how best to share historical snapshots of this analysis, but here's an archive of the HTML output, along with the relevant |
benjamn
added a commit
to apollographql/apollo-link
that referenced
this pull request
Mar 5, 2019
Importing graphql/execution/execute adds about 30KB to the minified footprint of a typical application (6.8KB after gzip). This estimate was obtained using the apollographql/react-apollo#2839 example application, which is bundled with Rollup. This is a significant pill to swallow under any circumstances, but before this commit apollo-link-schema was bundling all of that code into itself, preventing other packages from sharing the execution code, which very likely led to its duplication in some applications. With this commit, the self-size of apollo-link-schema falls from 19.3 KB to just 398 bytes (minified+gzip), which means we can finally stop excluding it from the filesize check.
benjamn
added a commit
to apollographql/apollo-link
that referenced
this pull request
Mar 5, 2019
Importing graphql/execution/execute adds about 30KB to the minified footprint of a typical application (6.8KB after gzip). This estimate was obtained using the apollographql/react-apollo#2839 example application, which is bundled with Rollup. This is a significant pill to swallow under any circumstances, but before this commit apollo-link-schema was bundling all of that code into itself, preventing other packages from sharing the execution code, which very likely led to its duplication in some applications. With this commit, the self-size of apollo-link-schema falls from 19.3 KB to just 398 bytes (minified+gzip), which means we can finally stop excluding it from the filesize check! 🙈
benjamn
added a commit
that referenced
this pull request
Mar 5, 2019
Similar in spirit to apollographql/apollo-link#959 This inlining was first introduced in PR #2661 with the following commit: de2b5fc At the time, inlining made sense because TypeScript was injecting copies of the __extends, __rest, etc. helpers into every module that used them. Depending on the tslib package seemed undesirable because the available bundle size measurement tools (e.g. bundlephobia.com) mistakenly counted the entire tslib package against react-apollo, without acknowledging the possibility of sharing that package between multiple Apollo packages. It seemed safer to inline only the helpers we needed at the top of lib/react-apollo.esm.js. Now that we have a more holistic way to measure bundle sizes (#2839), and react-apollo works better with tree-shaking tools (#2659, #2661, #2677), we know that overall application bundle sizes benefit from sharing a single copy of the tslib helper package, even if no tree-shaking is happening. Of course, with tree-shaking, that one copy of the tslib package can be shrunk to contain just the helpers that are actually used.
|
This app have errors, cannot manage to run. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this application is to get a precise, real-world measurement of the total bundle footprint of essential Apollo Client and React Apollo packages, using a modern bundler, including the weight of dependencies (excluding
reactandreact-dom), but also taking into account the overlap between shared dependencies, which is not possible with per-package tools like https://bundlephobia.com/result?p=apollo-client@2.5.1.If you run
cd react-apollo/examples/rollup npm install npm run analyzein this application, you'll see a breakdown of everything in the bundle that we think should be attributed to using Apollo Client and React Apollo. The current total stands at about 143KB (minified but not compressed with gzip, since that's how
source-map-explorerworks). After gzip, the total is about 39KB.Of that 143KB,
apollo-clientis the biggest single offender, at 39.5KB, followed closely bygraphql, at 31.6KB. If we includedreact-dom, it would weigh in at 106KB, but there's not much we can do about that, so we don't bother measuring it. By contrast, Apollo can pick and choose what it imports from thegraphqlpackage, so thegraphqlpackage is worth measuring, even though it's not maintained by Apollo.I welcome anyone and everyone to examine the measurement methodology we're using here, because early feedback about any inaccuracies will make this application much more useful for deciding where and how to invest future bundle reduction energy.
Likewise, I hope the analysis produced by this application will inspire grounded discussion of potential bundle reduction strategies, in addition to helping validate them.