Package size is massive

[1999]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

5.18.1

Description

Hi. Recently I looked into my pet project bundle size and was shocked with the size of @sentry/browser and its dependencies:

It looks like there's already been some discussion around the package size (#1552) and the problem is considered to be fixed but this is just crazy - @sentry/browser is consuming more space than React! I understand there's a lot in it, some integrations, grouping logic etc but is there a tiny Sentry client I can use which doesn't cost a world?

[jtgasper3]

This seems true of Vue.js as well. Vue's parsed size is 64.4 kB, while Sentry is a combined 68.0 kB (including the 6.1 kB Vue Integration).

[osdiab]

Agreed. I'm considering moving our company onto Sentry but this is making it a tough pill to swallow... Even with tree-shaking (importing Sentry via import { init } from "@sentry/react") and just calling that function, we're seeing +66kb before compression in our bundle - shockingly high!

Bundlephobia also reports a pretty huge size. https://bundlephobia.com/result?p=@sentry/react@5.20.0

a tough pill to swallow...

[nathancharles]

Agreed, 20K gzipped is a TON to just get basic JS error reporting support

[DouglasDev]

I also noticed that sentry is adding typescript files to the bundle: #2789

[cafesanu]

Yeah for me @sentry is 94kb already minified!

Don't get me wrong, I love Sentry, but I imagine this shouldn't be more than a few Kb. Almost as big as react-dom and bigger than Victory (our d3 chart library)!, but not bigger than Okta (which is my next github issues stop 😄 )

Any news here? An official Sentry response would be nice since this has been opened for almost 3 months. 🙂 @kamilogorek @HazAT @lobsterkatie

[jdelStrother]

There's another couple of kb added in the 5.25 -> 5.26 upgrade. Any hope for a release that goes the other direction?

[HazAT]

Hey, so this is one of the most important items on our roadmap to v6 see: #2817

It will not happen before v6 and there are a few reasons for that.
In order to make it smaller, we need to do a lot of internal refactorings, which strictly speaking, are breaking changes.

Even though from a usage perspective there shouldn't be any breaking changes (syntax, SDK API will stay the same), if someone for example wrote their own integration or used the SDK in a more advanced way there might be some breaking changes.

We will make the SDK more tree-shakable and remove a lot of internal glue code that doesn't contribute towards adding a lot of functionality.

Bear with us, we hear you and I wanted to let you know this is a high priority issue for us.

[jdelStrother]

@HazAT awesome, thanks for letting us know

[aleehedl]

Is there any workaround to use Sentry in AWS Lambda @ Edge with the 1 MB size restriction? The dependencies have grown way too big, and currently my only option is to use an older version of sentry/node. Is this being addressed somehow?

[scefali]

@aleehedl We are working on a new solution for AWS Lambda where you can add Sentry with a layer instead of using the Sentry package directly. The size of the layer is much smaller than 1 MB in size.

[prymitive]

v6.0.0 was released today but it doesn't seem to include any breaking changes.
I don't see any bundle size reduction, my webpack bundle is 615 bytes bigger with v6.
It seems that all major changes got pushed to v7 (?).

[lobsterkatie]

It seems that all major changes got pushed to v7 (?).

Yes. We needed a major bump in order to send sessions by default (see the corresponding changelog entry), and therefore the major changes will now happen in v7.

[osdiab]

just another piece of feedback - i tried adding the performance tracing integration + react router integration to my company's frontend, but it ended up increasing our bundle size on top of plain sentry error tracking +110kb before compression, compared to NewRelic's perf tracing that takes up +28kb, so we ended up implementing that. if v7 brings significant size reductions we may consider using sentry instead again, since it does have some nice extra features, but not nice enough to justify such a large bump in our bundle size (sentry taking up like double the space of React seems pretty silly).

[lobsterkatie]

if v7 brings significant size reductions

This is one of the primary goals of v7, and work is on-going, both to simplify the internals (to avoid unnecessary duplication) and to make the entire thing much more tree-shakable. Stay tuned!

[dmathewwws]

What about lazy loading Sentry: https://docs.sentry.io/platforms/javascript/install/lazy-load-sentry/ for people who are concerned about size of sentry.

[dmathewwws]

I saw the comment was downvoted. Does it not have the performance benefit? Or what are the downsides?

looking to add to my project and wanting to learn more.

[kamilogorek]

It does, but it only works from CDN, and people want smaller overall bundle-size.

[jdelStrother]

@dmathewwws We try & eager-load Sentry early so that errors/logs/events are all captured during startup.

[hakimio]

Tinkoff has open sourced their micro-sentry library. Check it out if you want to reduce the library size.

[ismay]

It does, but it only works from CDN, and people want smaller overall bundle-size.

It only working from CDN doesn't have to be a downside, depends on your situation. It's a good way to reduce bundle size, though it's possible that the loader would be blocked by an ad-blocker (for example). Then again, that same ad blocker could also block requests to Sentry made from the bundled SDK.

You won't miss out on unhandled errors and unhandled promise rejections that occur during startup. Those will be buffered and still sent with the lazy loading script. What you'll be missing out on is the other events, like performance features and breadcrumb data (see the docs here: https://docs.sentry.io/platforms/javascript/install/lazy-load-sentry). That is, until Sentry has been lazy loaded.

@dmathewwws So depending on your usecase, lazy loading could be a good solution.

[carlosbaraza]

This is open for more than 1 year. Is there any progress on this?

I know you committed to working on this, but we've have stayed loyal Sentry customers partially in base of that promise. We would appreciate an ETA for this.

[AdamZaczek]

Just an update from another dev team.
We used to use sentry in all of our apps and love the service but we will not add it to new apps because of the bundle size.

Logic is simple here.
Slow apps = bad user experience
User experience > dev experience

[jmfrancois]

The value is still here if you care about bundle size just remove integration of framework, they are useless and need you to start sentry after your framework which do not make sens for an error tracker.

If you are focused on loading time, use a CDN with just sentry in async.
It tooks 22kb minified https://docs.sentry.io/platforms/javascript/install/cdn/

[AbhiPrasad]

Hey folks. Just wanted to give an update here.

We are actively working on small wins we can take care of to address some bundle size concerns in the short term. Check out this milestone to keep tabs on it: https://github.com/getsentry/sentry-javascript/milestone/11

Bigger changes will require a major. We have a plan for that now: #4240 with our focus primarily being tree shaking/bundle size.

I totally understand this is a concern for y'all - took us a bit but we are all hands on deck here now :)

Also, for those with advice/ideas, PRs are welcome to help us out!

[AbhiPrasad]

Hey folks, we've been spent a couple weeks at the end of last year knocking out some quick wins related to bundle size. You can check the closed PRs in our milestone to see the type of strategies we used.

We've included these changes in a beta patch: https://www.npmjs.com/package/@sentry/browser/v/6.17.0-beta.0 - we would appreciate y'all giving this a try as we've made some larger refactors in preparation for bigger changes. Here is the changelog: https://github.com/getsentry/sentry-javascript/blob/master/CHANGELOG.md#6170-beta0. If you hit any issues with the beta, please open a GH issue.

Next steps? We'll be exploring emitting different kinds of bundles - so you can choose the one that fits your needs the best (and save on bundle size accordingly). Then we are going full steam ahead on the major release - which should give us even more wins in regarding to bundle size + improve tree shaking in the SDK massively.

Any questions? Please reach out to us on our discord. We would also appreciate if you have any advice/strategies for us, especially if you've done this kind of bundle size work before - always looking for ways to make our SDK better :)

[Valerioageno]

Hi all,
thanks to the team for the update. In the meanwhile I created a package to use sentry on react application without saving it in the main bundle (is a wrap around a CDN call). Is not full features ready but it can be a good starting point for using sentry as an error tracking on the client side.

Maybe this is not the right answer but it could be a pseudo-solution.

Here the repository
I hope you can find it useful.

Ciao

[plesiecki]

Can't find a word about transpilation.

Please don't distribute ESM as pretranspiled with tsc. Right now ESM includes helpers from tslib and classes are transpiled into ES5 and there is probably more of this...

If TS doesn't let you configure it better consider transpilation with babel and leave TS only for typechecking.

Need help?

[smeubank]

Hi all!

We've recently shipped our first beta for the V7 release! We would love to get your feedback on the changes we've made to the SDK and migration guide.

Thank you!

[bscaspar]

@smeubank thanks for the update! We use the @sentry/nextjs package. A quick analysis using @next/bundle-analyzer, switching from v6.17.4 to v7.0.0-beta.1 shows a gzipped client-side package reduction from 26.93kb to 23.53kb. I appreciate the work that went into this and the small savings!

We use Sentry very simply - on the client side = captureException, captureMessage, flush , and on the server = withSentry. (plus init for both of course)

Loading 23.54kb client-side is still almost 20% of our initial client-side page load. Maybe I am missing something, is there a way to further reduce the package size for such a small use of the API?

[AbhiPrasad]

@bscaspar thanks for the feedback, great to see some savings there. If you want to do even more, you can tree-shake out debug logic as well as any of the default integrations we use: https://docs.sentry.io/platforms/javascript/configuration/tree-shaking/.

Maybe #4722 can help for the nextjs stuff if you are not using performance monitoring? It did produce a good amount of savings as seen here: #3865 (comment)

This major is just the starting point, we'll keep working toward making improvements here!

[vladanpaunovic]

This issue was addressed in our v7 version of the SDK. We reduced the overall bundle size by a solid chunk.

We will continue our efforts into making the bundle size lower.

[spiffytech]

After upgrading to v7, my app bundle gzip size has been reduced from 53.67KB to 50.8KB.

For comparison, if I remove Sentry completely my app bundle gzip size falls to 31KB. So v7 reduces sentry by ~3KB, leaving it at 20KB.

[toolness]

Thanks for reducing the bundle size in v7!

It seems like the final size might be dependent on how many of the SDK's features you use--while @spiffytech saw a very minor reduction in size, the size of @sentry in my project's bundle went from 239 kb gzipped / 952 kb parsed (in version 6.13.3) to 202 kb gzipped / 752 kb parsed (in version 7.6.0). It's still larger than I'd like it to be, but I appreciate the reduction in size.

[bscaspar]

Following up here and based on @AbhiPrasad's suggestion to tree-shake out the optional code. We're on v7.6.0, we were able to drop our Sentry client package size down to 18.71 kb - big improvements! Thank you!!

[assafalmog]

Using sentry with next.js -
We were able to reduce the gzipped bundle size with the __SENTRY_DEBUG__: false, to 17.2kb

[luukdv]

In case it might help anyone, here's how to trim Sentry to the smallest possible size using Next.js (as far as I could see):

// next.config.js

const { DefinePlugin } = require("webpack");

…

  sentry: {
    disableClientWebpackPlugin: true,
    disableServerWebpackPlugin: true,
  },
  webpack: (config) => {
    config.plugins.push(
      new DefinePlugin({
        __SENTRY_DEBUG__: false,
        __SENTRY_TRACING__: false,
      })
    );

    return config;
  },

…

In the client config you can comment out undesired integrations as you see fit:

// sentry.client.config.js

import {
  Breadcrumbs,
  BrowserClient,
  // Dedupe,
  FunctionToString,
  getCurrentHub,
  GlobalHandlers,
  HttpContext,
  // InboundFilters,
  // LinkedErrors,
  makeFetchTransport,
  TryCatch,
} from "@sentry/nextjs";

getCurrentHub().bindClient(
  new BrowserClient({
    dsn: "",
    transport: makeFetchTransport,
    integrations: [
      new Breadcrumbs(), // ~7kB unminified
      // new Dedupe(), // ~5kB unminified
      new FunctionToString(), // ~1kB unminified
      new GlobalHandlers(), // ~7kB unminified
      new HttpContext(), // ~2kB unminified
      // new InboundFilters(), // ~6kB unminified
      // new LinkedErrors(), // ~2kB unminified
      new TryCatch(), // ~9kB unminified
    ],
  })
);

[RustLoverTheCoder]

come on, make it smaller

[mustafa0x]

Very small Svelte app. Before adding "@sentry/svelte": "^7.58.1":

✓ 39 modules transformed.
dist/bundle.css  17.54 kB
dist/bundle.js   43.72 kB │ map: 134.18 kB

After:

✓ 180 modules transformed.
dist/bundle.css   17.54 kB
dist/bundle.js   231.38 kB │ map: 540.03 kB

Increased 188kb, 60kb when minified. That's way too much.

(source) Adding 1.7s to page load (and several more seconds to parse and compile) isn't a good look. :(

[mydea]

We publish in-detail bundle size information with our releases - for example, for the latest release: https://github.com/getsentry/sentry-javascript/releases/tag/7.58.1

The maximum bundle size that will be added, when using error & performance monitoring as well as replay, is ~70kb min/gzipped. Without replay, that goes down to about 30kb. There is sadly little that we can do to get the replay bundle size down, as this is just pretty complex code that has to deal with a lot of edge cases. If you care about bundle size a lot, you can either disable replay or lazy load it to lighten the load for the user. The 84kb from your screenshot are definitely not a realistic value, and we recommend to take bundlephobia values with a lot of grains of salt, as they are not always accurate (no dunk on them, they have to somehow calculate this without knowing how stuff is used, so it makes sense that this would not necessarily be correct).

TLDR: About half of the overall bundle size Sentry adds is for Replay. This is not great, but sadly there is not really much we can do about this. If this is too large for you, you should disable replay or consider lazy loading it - then Sentry should only add <30kb min/gzipped, which is not unreasonable for all the functionality the SDK provides.

[mustafa0x]

Thanks @mydea, understood. I think lazy loading makes sense.

I'm looking through the documentation and trying to figure out how I can replicate Sentry.init with a lazy loaded script. I found this link but it's 404: https://docs.sentry.io/platforms/javascript/guides/react/install/lazy-load-sentry/

I also found https://docs.sentry.io/platforms/javascript/install/loader/ but from reading the docs it seems to behave differently.

[AbhiPrasad]

Here's the docs on lazy loading session replay: https://docs.sentry.io/platforms/javascript/session-replay/#lazy-loading-replay

Lazy loading Sentry w/ the loader only supports error monitoring, as otherwise Sentry needs to be in initial load for both performance monitoring and session replay to work correctly.

[mustafa0x]

@AbhiPrasad Thanks! Unless I missed something though, that doesn't affect bundle size.

Maybe if using using the loader script, but the preceding code block shows a regular import.

(Perhaps this discussion should be continued in another issue?)

(Update: nevermind, I read more docs and I think most questions were clarified)

---