Lazy loading of @sentry/browser

[ackushiw]

What problem does this feature solve?

This will reduce the app bundle size and improve initial loading speeds.

What does the proposed changes look like?

Following the guide here https://docs.sentry.io/platforms/javascript/#lazy-loading-sentry it should be possible, though it looks like the sentry loader is not available via npm :/

_{This feature request is available on Nuxt community (#c77)}

[atinux]

Actually they they to use the defer attribute to lazy load, every scripts added by Nuxt already use the defer attribute :)

[rchl]

While defer attribute is not exactly comparable to lazy loading (it means the script will be parsed after the page is parsed but still before DOMContentLoaded), using lazy-loaded loader would have major drawback that you wouldn't have the guarantee that Sentry catches all the errors. And of course it's not currently possible to integrate it (even as an option) as it's meant for browser-only usage and not through npm so webpack is not able to bundle it.

[pimlie]

Could we maybe revisit this issue? The sentry dependency adds 20KB gzipped to the vendors bundle which I think is quite a bit.

It should be probably be possible to add a small helper script which we load directly through vue-meta as follows:

window.__errors = []
window.addEventListener('error', (...args) => window.__errors.push(args))

then we should fully defer loading this module / Sentry until the browser is idle again after rendering the page and then after sentry init manually report errors from window.__errors or something

That way we have both the benefit that we are capturing errors as soon as possible (which we dont atm) as that the user experience doesnt take (a small) hit by error reporting logic.

[rchl]

The question is... what would such lazy-loaded Sentry provide comparing to the one that is "integrated" (bundled through their SDK via this module)?

I'm pretty sure it won't be as well integrated as SDK.

• It won't be available in the Vue context using `this.$sentry.
• It won't have Vue-specific integrations listed in https://docs.sentry.io/platforms/javascript/vue/.

And maybe we could add some of that manually through a plugin but then we'd be re-implementing parts of their SDK.

Isn't that a deal-breaker? You would have to be quite careful when using this.$sentry not to use it on the client.

We could still pursue this path but, if added, there would have to be a big note saying how this affects everything.

[pimlie]

It should be possible to use a Nuxt plugin and pass the references we need to sentry only once ready. From their sdk docs they dont seem to require that you bind to Vue's errorHandler before your app is mounted.
Within the Nuxt plugin you would wait until nuxt is ready and only then do a dynamic import & initilization.

For this.$sentry we could add a ready method that you have to await, a bit similar to how $nextTick works. This would be a breaking change, but it would result in your browser not having to download or parse or execute a chunk of 20KB of gzipped javascript before it has rendered your app

  await this.$sentry.ready()
  this.$sentry.whatever()
}, 1)

Possibilities on how to implement this are probably endless. I do agree that preferably this would be totally solved by sentry themselves though

[MartinMalinda]

👍 For this.

In a previous app I've built I had a "analytics" service that loaded all kinds of scripts like Sentry, Google Analytics etc. lazily when they were requested.

const sentry = await $analytics.getSentry();
const ga = await $analytics.getGoogleAnalytics();

It also used requestIdleCallback() to do the import in the right moment and not jank the browser unnecessarily.

There's a certain risk of some errors not being reported because the Sentry was not loaded, but I believe this danger is relatively small and the trade off is worth it in most cases.

[rchl]

There's a certain risk of some errors not being reported because the Sentry was not loaded, but I believe this danger is relatively small

I'm not sure if we can reliably assess the danger from where we stand.
You would potentially not catch all kinds of critical errors that break page loading completely since those would happen very early.
How can we tell for sure that it's safe, or even relatively safe?

[AndrewBogdanovTSS]

@rchl maybe it could be an optional solutions so users who are ok with such behavior can enable it via configuration setting?

[rchl]

Just to be clear that was the purist in me speaking.

The pragmatic side of me wants this feature and I would likely use it myself seeing how most of the client-side errors are garbage and I barely even look at them anymore...

@rchl maybe it could be an optional solutions so users who are ok with such behavior can enable it via configuration setting?

Still, it would be good to explain to the user what he should expect. And I think we can't say much apart from "you might miss some errors, potentially even critical to your site working".

[AndrewBogdanovTSS]

Well, that can be mentioned in option's documentation. Most of the tools should be used with responsibility in mind. If the guys who were producing hammers would stop after first person hitting a thumb instead of a nail - than humanity wouldn't built lots of amazing things

[MartinMalinda]

BTW what about the cases when the app fails to load because the bundle was too big and the internet is shaky/slow :) those get unreported too

I believe with the addEventListener('error') solution in a small script in head to capture the early errors the real extra risk would be only that the lazy load of Sentry fails. That can happen in case of shaky internet connection I assume. But in that case Sentry itself can fail too, although it probably tries to be quite resilient in reporting errors. After all that's prob one of the reasons why it has 20KBs instead of, idk, 2, ha.

[drewbaker]

Wasn't excited to see this in my bundle analyzer after installing this. Also, I hate Filestack! LOL!