-
Notifications
You must be signed in to change notification settings - Fork 787
Add a basic example app bundled with Rollup. #2839
Conversation
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/[email protected]. 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great @benjamn - thanks for putting this together!
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.
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! 🙈
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. |
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
andreact-dom
), but also taking into account the overlap between shared dependencies, which is not possible with per-package tools like https://bundlephobia.com/[email protected].If you run
cd react-apollo/examples/rollup 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 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 thegraphql
package, so thegraphql
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.