Package size is massive

[1999]

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

Package + Version

• [x] @sentry/browser
• [x] @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 (https://github.com/getsentry/sentry-javascript/issues/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: https://github.com/getsentry/sentry-javascript/issues/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: https://github.com/getsentry/sentry-javascript/issues/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.

[timuric]

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.

Indeed, I have been tracking the size of sentry bundle for few years already and recently decided to move our company to competitor solely due to this reason. It is quite disappointing because sentry is a really good platform, but using a tool at the cost of user experience is not a good deal.

[hakimio]

@timuric which competitor did you choose?

[timuric]

@timuric which competitor did you choose?

newrelic

[aripalo]

Shame. I was really excited about Sentry as a product and was considering about moving from AirBrake to Sentry, but this massive browser bundle is a show stopper there.

[Daniel15]

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

@dmathewwws Unfortunately the built-in lazy loading is kinda broken for on-premise Sentry installs... There's a workaround of using the public Sentry CDN instead of anything on-premise, but I'm working around it by doing my own lazy loading using Webpack's import() support and copying some ideas from the regular lazy loader (queue Sentry, window.onerror and window.onunhandledrejection calls and replay them once the library is loaded): https://github.com/getsentry/sentry/issues/22715#issuecomment-926385843

Having said that, lazy loading is really just a workaround. What's really needed is an optimization of the library. Squeeze every byte 😃

@timuric which competitor did you choose?

newrelic

@timuric What's the total size of the New Relic JS SDK, with a similar set of features enabled?

A lot of the competitors have the same problem (eg I'm migrating from Bugsnag, which also has a large bundle size: https://github.com/bugsnag/bugsnag-js/issues/463).

IMO a lot of the issues are because the libraries may have been built before ES6 modules were widespread, so they weren't built with the idea of tree shaking and code splitting in mind. IMO all the pieces should be code shakable plugins, so you only pay for what you need. If you just want basic error logging, the impact on bundle size should be tiny.

[jdelStrother]

What's the total size of the New Relic JS SDK, with a similar set of features enabled?

Their default is something like 28k minified, 9.9k after gzip. It's missing a few things, though - eg I don't think there's a good way of capturing logs or breadcrumb events leading up to an error.

(For comparison, Sentry is ~ 85k minified, 24k after gzip.)

[brantchoate]

i wish newrelic wasn't the answer here.. :(

[rdrnt]

Any update on this? The bundle size on @sentry/gatsby is a killer.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[tizmagik]

Reset the clock, please. This is an important issue. 😅

[schlosser]

Big +1 here, this a big part of our bundle size and we'd really prefer a "pay for what you use" model.

[SevdalinZhelyazkov]

After an inspection on our company's project codebase it turns out that sentry is the biggest package of all (even bigger than MUI imports) with 26.45KB gzipped size. This is such a pity. I read the whole thread and I found no solution. Seems like the v7 roadmap is nowhere near completion. Can we have any heads-up on this from someone? I am considering moving to another solution.

[Daniel15]

I read the whole thread and I found no solution.

@SevdalinZhelyazkov You can lazy load Sentry, but that's not perfect. It's just deferring the large library, meaning it actually still loads eventually, but at least it doesn't have to block TTI and you can instead load it when the browser is idle (using requestIdleCallback). The built-in lazy loading doesn't work for on-premise installs but you can see my example code at https://github.com/Daniel15/LazySentry for an alternate approach.

[contesini]

[nicubarbaros]

-_-

[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: https://github.com/getsentry/sentry-javascript/issues/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 https://github.com/getsentry/sentry-javascript/issues/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: https://github.com/getsentry/sentry-javascript/issues/3865#issuecomment-1127497194

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