Apollo and graphql bundle size combined increases significantly #8705
Comments
|
I'm seeing a very significant increase as well. Below is the output of our build system: We're all trying to keep our bundle sizes down as much as possible and increase of 13kB seems insane for a point release. 😅
|
|
Unless I'm misreading, that's +13kB of minified code before gzip, which translates to 27.14kB - 24.28kB = 2.86kB of additional bundle size (after gzip) in @miqdadfwz's example. While I understand your concern over that increase, as long as you're following the advice about replacing Apollo Client 3.4 was a big (250 commit) minor release, with significant new functionality. To make matters worse, because it was a minor release, we did not have the luxury of removing anything people might be depending on. Removal of functionality will become possible in the next major version (AC4), and please rest assured we will be looking for ways to dramatically reduce the footprint of the library in the next major version. For now, thank you for your patience with our backwards compatibility obligations. I don't know exactly how your bundlers are configured, so there might be opportunities to improve bundle sizes on the application side, without changes to Apollo Client. If you discover anything along those lines, or if you can identify parts of the library you know you aren't using, but that still end up in your bundle, please let us know, so we can talk about specific solutions. |
|
Hi @benjamn! Thanks for your detailed reply this really helps! The reported sizes are gzipped sizes, so that made me jump a bit. The above is the build output of our nextjs project (formatted as a table). I've implemented the
I'm not sure why the bundle size is still increasing 8kb, debugging further.. I've generated treemaps with lighthouse which. The result is a bit cluttered because nextjs prefetches bundles for different pages, but the important one is the top left one. Lighthouse treemap with 3.3 This shows that the difference between @apollo/client doesn't really differ much (maybe because I've now just implemented the |
To import `graphql` (and its internal `instanceOf` function) for the first time with `process.env.NODE_ENV` safely polyfilled, PR #8347 selected a somewhat arbitrary export of the `graphql` package that uses `instanceOf`, specifically the `isType` function exported by `graphql/type/definition`. As revealed by issue #8705, importing `isType` was a bad choice, since it depends on a bunch of other code within the `graphql` package, unnecessarily increasing minified+gzip bundle size by 3.4kB. A better choice is the `Source` constructor, which is already imported thanks to other necessary imports, and also imports/uses `instanceOf`.
|
@paales @miqdadfwz By my measurements, this PR will save another 3.4kB of minified+gzip bundle size: #8891. The import of |
|
The additional bundle size from the |
|
@benjamn I've updated Apollo Client to 3.4.16 and that does seem to make a big difference, more in line of what to expect :)
|
|
Hi @benjamn thank you for fixing this! I confirm that the additional bundle size has been resolved in my end. version 3.1.18 version 3.4.16 |
Intended outcome:
Bundle size does not increases significantly
Actual outcome:
We can run our production application successfully after we updating to 3.4.9 from 3.1.18, but the size from apollo and specifically from graphql increases around 13kb combined (see image below).
version 3.3.18
version 3.4.9
I was aware there that
process.env.NODE_ENVis replaced by__DEV__to avoid size increment, but apollo size is still increases. It is not that big but if we combine with graphql which is the core depedendcy for apollo-client, it increases significantly.I'm not quite sure this is an actual issue, or maybe is this expected outcome after we updating the version? if yes then any
reason behind of it?
How to reproduce the issue:
Update to latest version of 3.4.9 and run webpack bundle analyzer, compare the result with 3.3.18.
Versions
The text was updated successfully, but these errors were encountered: