@sentry/browser size #1552
Comments
|
Hey, thanks for bringing this up.
Also, while this might not be applicable to everyone, we provide and usually guide people to use our CDN Loader which will set up the SDK for you on your website. see : https://docs.sentry.io/quickstart/?platform=browser The footprint and impact on your pageload time of this script it <1KB gzipped while keeping the same functionality. so tl;dr: |
I would argue it is also fair to compare minified sizes as perfomance issues not only arise from downloading javascript, but also from parsing and execution. ~92kb is quite hefty and could add up to 1s of parse time on low-end devices (just for this one library!). I'm not sure where you take the number of You should be aware that sentry's sdk is just one of many libraries developers include. PS: I love sentry, it's been super helpful for us. Web performance is just something I'm passionate about. ;) |
|
@klaemo Like I said, we are aware and it's not like we don't want it to be smaller. Sorry, the link I posted before is already outdated 🙃 |
|
@HazAT Sorry, guys, but can you provide next version release date? |
|
@rayzru Just released |
- extract from the vendors bundle as it is BIG: getsentry/sentry-javascript#1552 - Queue all events and send them when package loads
💯 I was just about to upgrade up until I noticed that:
At least the package size is smaller, but I think that |
|
@HazAT Could it be possible to generate esm files. It would allow webpack to have better result with concatenation and tree shaking. |
|
You might want to add some CI tool to track the bundle size of the package for each merge request. Since this issue it has actually grown to 100 kB, see https://bundlephobia.com/result?p=@sentry/browser@4.3.0 Try for instance https://github.com/siddharthkp/bundlesize The default performance budget for an entry point in Webpack is 250 kb to make sure you get decent performance on any device and network. 100 kb of Sentry takes up quite a lot of that budget. |
|
Please keep us updated if fixing this regression is on the roadmap at all, or if the library will just keep growing without a size budget. We are paying customers and heavily invested in Sentry on both backend, native and web, but an upgrade to over 3x the size of the library (raven-js@3.23.1 is 31 kB) is not something we can justify. |
|
@jacobrask You can stick to the older version of the library, it's what we do at https://www.onepixel.com/, it's working fine 👌. |
|
@jacobrask It's definitely on our list and we also think there are some low hanging fruits where we can easily reduce our bundle size. |
|
@HazAT |
|
The bundle size is same in 4.3.2 |
|
@vkrol We had to revert the changes that @gaterking made, at least for the npm package. We will for sure re-add the changes but we need to talk about it since we need a dep on |
|
@HazAT OK, thanks. |
Hope as soon as possible. |
|
@gaterking @kamilogorek Fixed it already #1751 |
|
On the client-side, I basically want this to capture errors and submit them to the API. What else is this library doing that's so complex? It's really hard to understand why a simpler error-reporter needs to have such a substantial footprint 😐 |
|
@mindplay-dk It's mostly because JavaScript and Browsers are a mess ^^ |
@mindplay-dk because it's not simple. Here's the code for just capturing errors in all the browsers and unifying them into a usable data structure: https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts |
|
Well done on the recent size reduction, greatly appreciated. 👍 A quick glance at the linked file shows code to handle errors for Opera 10, is that really still required? TraceKit also does not account for the (currently) 2x size increase from Raven, which was already large. Some suggestions:
|
|
Is there some shared code( |
@kamilogorek yikes, you're obviously right... I realized JavaScript was a mess - I guess I've never dug into this area before, I didn't realize how bad this was. I guess there's really no simple way to handle stack-traces in JS. Just. Yikes. 😐 |
|
@cromefire yes, because it's meant to be used as a "snippet". However you can find it's code here https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js |
|
Seems like I have to open a new PR, because with |
|
We have a solution coming that will let you use |
|
It shouldn't be hard to write a loader that loads that in under 1kb, so why not, I will try writing a quick one |
|
One thing that could help out a lot here is if some of the functionalities are optional. For instance a really nice bare minimum could be:
Any additional functionalities can just be an add on. We only support modern browsers, so we don't need to work around all the quirky behavior of old browsers. |
|
We solved this by using webpack code splitting and load sentry client only on error.
import * as Sentry from '@sentry/browser';
Sentry.init({
...
integrations: integrations => {
return integrations.filter(integration => integration.name !== 'GlobalHandlers');
},
});
export const logError = error => Sentry.captureException(error);
const captureError = async error => {
const { logError } await import(/* webpackChunkName: "sentry" */ './sentry');
logError(error);
}
window.onerror = (message, url, line, column, error) => captureError(error);
window.onunhandledrejection = event => captureError(event.reason);We do some more in there like populate breadcrumbs, add extra, add tags, etc.. but it's possible to use sentry client and not make your bundle bigger. |
|
This is somewhat what I implemented in #1846 |
|
Might be helpful to others:
resolve: {
alias: {
// use sentry ESM build which is not declared in the @sentry/browser package.json
'@sentry/browser': path.resolve(
__dirname,
'node_modules/@sentry/browser/esm',
),
}
{
test: /\.m?jsx?$/,
loader: 'babel-loader',
// compile sentry as the ESM build is new and ships modern features which break our supported browsers
exclude: /(node_modules\/(?!(@sentry\/[^/]+\/esm))|bower_components)\//,
}Notes:
|
|
You can just redirect to resolve: {
alias: {
// use sentry ESM build which is not declared in the @sentry/browser package.json
'@sentry/browser': '@sentry/browser/esm'
}But you don't need to add an alias, just import For the loader it's easier to write it like this:
{
test: /other_things/,
include: [/@sentry\/.+\/esm/],
exclude: /node_modules/,
// config
}
{
test: /@sentry\/.+\/esm/,
exclude: /node_modules/,
// config
}Also remember to customize the babel config for your needs: babel docs, else it's not worth to use the esm version |
|
Update: We will soon release new major version of the SDK which reduces the bundle size significantly.
Our prebuilt CDN versions even show better results (not sure how bundlephobia measures stuff) Anyway, I wanted to let you know that were are still working on reducing the bundle size further but this should already be a huge step in the right direction. Note on upgrading: It's a major bump since there are many internal changes in the SDK. There shouldn't be any code changes necessary on your side. We are currently testing the new version ourselves on sentry.io to see how it behaves. ref: getsentry/sentry#12492 Disclaimer: Don't use |
|
@HazAT thank you for taking this seriously! this is a big step forward - I am already much less concerned about deploying this now :-) |
|
|
|
@kamilogorek Just out of curiosity, could you add to the comparison the last version from |
|
I am closing this issue, as of now, we think, the reduction we introduced moving from v4 to v5 is a trend in the right direction. We will still try to reduce it further and we will be very conscious about increasing it ever again. As a quick remark, we really only like to compare our "bundle" size, since depending on what bundler you are using your mileage may vary, so here are the CDN bundle number we ship(ped):
With v5 we also ship and Thank you all for your patience 🙇 |
|
@HazAT @kamilogorek awesome! |
|
@Limess Is it still relevant to use this today: It's imported like |
and others
Package + Version
@sentry/browser@sentry/noderaven-jsraven-node(raven for node)Version:
Description
The size of the @sentry/browser is more than twice as large as the size of raven-js: 86 kB vs 39 kB (minified). In my opinion, this is definitely a regression and the serious reason not to update to the new version.
The text was updated successfully, but these errors were encountered: