You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ref(browser): Add section about limitations of tracing with the loader (#13804)
## DESCRIBE YOUR PR
This PR adds a "Limitations of Tracing" section to the JS loader page
(analogously to the Limitations of Errors-Only Capturing). The problem
with tracing and using the loader is the async nature of the loader and
a couple of pitfalls related to this with the order of initializing the
SDK and auto instrumentation picking up signals (e.g. fetch calls).
I also added the `Sentry.init` call to the "Guarding SDK Function Calls"
section, to make it clear that Sentry.init should happen in
`window.sentryOnLoad` and not in `Sentry.onLoad` (naming wasn't on our
side in this case 😅)
#### Why can't the loader call `Sentry.onLoad` always after
`Sentry.init`?
This is because historically, users used `Sentry.onLoad` but there were
timing issues because the function had to be registered after the loader
script was evaluated (see
getsentry/sentry#58574). So therefore, in order
for the loader's default `Sentry.init` **not** to be called, that
user-`Sentry.init` call needs to happen before --> `Sentry.onLoad` must
be called beforehand. Changing this could break peoples' Sentry (loader)
setup.
#### Why not provide a `Sentry.afterInit` hook?
This would further imply that users should delay important components of
their page, thus decreasing perceived performance. This is the very
thing why users should use the loader -> less performance overhead of
the SDK
Also, it would potentially couple user functionality to the Sentry SDK
to initialize. In many cases (ad blockers, script blockers), the SDK
can't init correctly, so that user behaviour would never be invoked.
## IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs
to go live.
- [ ] Urgent deadline (GA date, etc.): <!-- ENTER DATE HERE -->
- [ ] Other deadline: <!-- ENTER DATE HERE -->
- [x] None: Not urgent, can wait up to 1 week+
## SLA
- Teamwork makes the dream work, so please add a reviewer to your PRs.
- Please give the docs team up to 1 week to review your PR unless you've
added an urgent due date to it.
Thanks in advance for your help!
## PRE-MERGE CHECKLIST
*Make sure you've checked the following before merging your changes:*
- [ ] Checked Vercel preview for correctness, including links
- [ ] PR was reviewed and approved by any necessary SMEs (subject matter
experts)
- [ ] PR was reviewed and approved by a member of the [Sentry docs
team](https://github.com/orgs/getsentry/teams/docs)
## EXTRA RESOURCES
- [Sentry Docs contributor guide](https://docs.sentry.io/contributing/)
Copy file name to clipboardExpand all lines: docs/platforms/javascript/common/install/loader.mdx
+56-11Lines changed: 56 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -171,24 +171,69 @@ By default, the loader will make sure you can call these functions directly on `
171
171
-`Sentry.showReportDialog()`
172
172
173
173
If you want to call any other method when using the Loader, you have to guard it with `Sentry.onLoad()`. Any callback given to `onLoad()` will be called either immediately (if the SDK is already loaded), or later once the SDK has been loaded:
174
-
175
-
```javascript
176
-
// Guard against window.Sentry not being available, e.g. due to Ad-blockers
177
-
window.Sentry&&
178
-
Sentry.onLoad(function () {
179
-
// Inside of this callback,
180
-
// we guarantee that `Sentry` is fully loaded and all APIs are available
// Guard against window.Sentry not being available, e.g. due to Ad-blockers
187
+
window.Sentry&&
188
+
Sentry.onLoad(function () {
189
+
// Inside of this callback,
190
+
// we guarantee that `Sentry` is fully loaded and all APIs are available
191
+
constclient=Sentry.getClient();
192
+
// do something custom here
193
+
});
194
+
</script>
184
195
```
185
196
186
-
## Limitations of error-only capturing
197
+
## Limitations of Errors-only Capturing
187
198
188
199
When using the Loader Script with just errors, the script injects the SDK asynchronously. This means that only _unhandled errors_ and _unhandled promise rejections_ will be caught and buffered before the SDK is fully loaded. Specifically, capturing [breadcrumb data](../../enriching-events/breadcrumbs/) will not be available until the SDK is fully loaded and initialized. To reduce the amount of time these features are unavailable, set `data-lazy="no"` or call `forceLoad()` as described above.
189
200
190
201
If you want to understand the inner workings of the loader itself, you can read the documented source code in all its glory over at the [Sentry repository](https://github.com/getsentry/sentry/blob/master/src/sentry/templates/sentry/js-sdk-loader.ts).
191
202
203
+
## Limitations of Tracing
204
+
205
+
Because the loader script injects the actual SDK asynchronously to keep your pageload performance high, the SDK's tracing functionality is only available once the SDK is loaded and initialized.
206
+
This means that if you e.g. have `fetch` calls right at the beginning of your application, they might not be traced.
207
+
If this is a critical issue for you, you have two options to ensure that all your `fetch` calls are traced:
208
+
209
+
- Initialize the SDK in `window.sentryOnLoad` as described in [Custom Configuration](#custom-configuration). Then make your `fetch` call in the `Sentry.onload` callback.
- Use the [CDN bundles](#cdn) instead of the Loader Script. This will ensure that the SDK is loaded synchronously, and that all your `fetch` calls are traced.
230
+
231
+
<Alertlevel="warning">
232
+
233
+
Please be aware that both of these options will add delay to your `fetch` calls or decrease your pageload performance. Ultimately, this is the trade-off between lazy and eagerly loading the Sentry SDK.
234
+
235
+
</Alert>
236
+
192
237
## CDN
193
238
194
239
Sentry supports loading the JavaScript SDK from a CDN. Generally we suggest using our Loader instead. If you _must_ use a CDN, see [Available Bundles](#available-bundles) below.
0 commit comments