Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Apollo and graphql bundle size combined increases significantly

See original GitHub issue

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 Screen Shot 2021-08-26 at 17 44 11

version 3.4.9 Screen Shot 2021-08-26 at 17 44 03

I was aware there that process.env.NODE_ENV is 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

 System:
    OS: macOS 11.2.3
  Binaries:
    Node: 12.22.0 - ~/.nvm/versions/node/v12.22.0/bin/node
    npm: 7.20.6 - ~/.nvm/versions/node/v12.22.0/bin/npm
  Browsers:
    Chrome: 92.0.4515.159
    Safari: 14.0.3
  npmPackages:
    @apollo/client: 3.4.9 => 3.4.9

Issue Analytics

State:
Created 2 years ago
Reactions:5
Comments:7 (3 by maintainers)

Top GitHub Comments

4reactions

paalescommented, Oct 5, 2021

@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 😃

Page	Size old	Size new	Size diff	First load old	First load new	First load diff
/	0.4kB	0.4kB		230kB	233.0kB	+3kB⚠️
/[…url]	3.0kB	3.0kB		250kB	253.0kB	+3kB⚠️
/404	6.4kB	6.4kB		222kB	225.0kB	+3kB⚠️
/account	11.6kB	12.5kB	0.9kB	204kB	208.0kB	+4kB⚠️
/account/addresses	5.8kB	9.9kB	+4.1kB⚠️	214kB	218.0kB	+4kB⚠️
/account/addresses/add	7.0kB	7.5kB	0.5kB	228kB	232.0kB	+4kB⚠️
/account/addresses/edit	4.5kB	7.7kB	+3.2kB⚠️	232kB	236.0kB	+4kB⚠️
/account/authentication	6.4kB	7.9kB	+1.5kB⚠️	225kB	229.0kB	+4kB⚠️
/account/contact	6.7kB	8.2kB	+1.5kB⚠️	226kB	230.0kB	+4kB⚠️

New treemap for 3.4.16

4reactions

benjamncommented, Oct 1, 2021

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 __DEV__, I don’t have any easy advice for you.

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.