Update performance-overhead.mdx (#7479)

* Update performance-overhead.mdx

* style(lint): Auto commit lint changes

* Update src/docs/product/session-replay/performance-overhead.mdx

* Update src/docs/product/session-replay/performance-overhead.mdx

* Update src/docs/product/session-replay/performance-overhead.mdx

Co-authored-by: Ryan Albrecht <ryan.albrecht@sentry.io>

* style(lint): Auto commit lint changes

* style(lint): Auto commit lint changes

* style(lint): Auto commit lint changes

---------

Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>
Co-authored-by: Ryan Albrecht <ryan.albrecht@sentry.io>

Author: 3 people

src/docs/product/session-replay/performance-overhead.mdx

@@ -6,11 +6,30 @@ description: "Session Replay SDK performance overhead."
 
 <Include name="feature-stage-beta-session-replay.mdx" />
 
-Session Replay works by observing and recording changes to your web application's DOM, and transmitting that data to event ingestion servers over the public internet. In order to perform this work without negatively impacting the host page's performance, the Session Replay SDK takes care to introduce minimal additional filesize, observe and record DOM content in a non-intrusive way, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users.
+Session Replay works by observing and recording changes to your web application's DOM and transmitting that data to event ingestion servers over the public internet. In order to perform this work without negatively impacting the host page's performance, the Session Replay SDK takes care to introduce minimal additional filesize, observe and record DOM content in a non-intrusive way, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users.
 
-**For most web applications, the performance overhead of our client SDK is imperceptible to end-users.**
+**For most web applications, the performance overhead of our client SDK will be imperceptible to end-users.**
 
-Performance overhead depends on the complexity of your application. Applications with a large DOM and numerous DOM node mutations will have a higher overhead than a more simpler and mostly static site. The only way to get accurate overhead metrics is to measure it yourself. We have written a blog post, [Measuring Session Replay Overhead](https://sentry.engineering/blog/measuring-session-replay-overhead), that outlines how you can get started measuring overhead of Replay on your applications without deploying to production. We measured the overhead of the Replay SDK on Sentry's web UI using the methodology from the blog. Here are the results (median values are shown):
+## How Is Session Replay Optimized?
+
+Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the page on which it's running:
+
+- At the time of publishing this document, the Session Replay plugin is an additional ~36KB gzipped.
+  - In our own research, this is among the smallest filesize Session Replay SDKs available.
+  - We provide multiple ways to load the Replay bundle, including [via our Loader Script](/platforms/javascript/install/loader/).
+- The Session Replay SDK works by snapshotting the web page’s Document Object Model (DOM) and transmitting its content to Sentry’s servers. To minimize the amount of bytes transferred, multiple strategies are employed:
+  - Once the initial DOM tree is snapshotted, the SDK records and transmits _changes_ (deltas) to the DOM rather than snapshotting the entire tree again. This ensures the smallest amount of state is transmitted to facilitate playback. Additionally, the SDK doesn't spend CPU cycles scanning for changes itself; instead it listens for changes emitted by [`MutationObserver`](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver), an internal browser API.
+  - DOM content itself is gzip compressed client-side before transmission over HTTP. The compression operation is executed in a background thread using a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers), which means the browser’s UI thread is unaffected.
+  - The SDK doesn't cause the browser to download and transmit other static assets, like images, video, etc. Instead during playback, those assets are fetched directly from the original host server.
+- Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s browser connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser.
+- The SDK is built to gracefully downgrade when needed. In the event several thousand DOM mutations happen at once, the SDK will disable recording to make sure recording the website doesn't further degrade user experience. The [mutation limit values are configurable](/platforms/javascript/session-replay/configuration/#mutation-limits).
+
+## Performance Overhead in Sentry
+
+While the performance overhead of our client SDK will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an applications has a large DOM and numerous DOM node mutations, it will have a higher overhead than simpler, mostly static sites. The only way to get accurate metrics is to measure performance overhead yourself.
+To learn how to measure performance overhead of Session Replay on your applications without deploying to production, read out blog post: [Measuring Session Replay Overhead](https://sentry.engineering/blog/measuring-session-replay-overhead).
+
+We measured the overhead of the Replay SDK on Sentry's web UI using the methodology from the blog. Here are the results (median values are shown):
 
 | Metric                           | Without Sentry | Sentry SDK only | Sentry + Replay SDK |
 | -------------------------------- | -------------- | --------------- | ------------------- |
@@ -36,25 +55,11 @@ The benchmarks were run on an Apple M1 MacBook Pro against a remote preview serv
 The benchmark test was a strenuous recording scenario (the Discover data table is one of our most complex, in regards to DOM nodes and mutations). A simpler scenario consisting of navigation to four different "Settings" pages was also ran and produced an increase of ~100 ms of total JS blocking time.
 
 <Note>
-  There is a known performance issue that happens when replays with many DOM
+  There's a known performance issue that happens when replays with many DOM
   mutations are recorded. It generally occurs when rendering large data grids.
   We're working on a fix, but in the meantime we recommend you{" "}
   <Link to="https://docs.sentry.io/platforms/javascript/session-replay/privacy/#blocking">
     use the blocking feature
   </Link>
   to avoid recording large mutations which can degrade performance for your customers.
 </Note>
-
-## How Is Session Replay Optimized?
-
-Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the page on which it's running:
-
-- At the time of publishing this document, the Session Replay plugin is an additional ~36KB gzipped.
-  - In our own research, this is among the smallest filesize Session Replay SDKs available.
-  - We provide multiple ways to load the Replay bundle, including [via our Loader Script](/platforms/javascript/install/loader/).
-- The Session Replay SDK works by snapshotting the web page’s Document Object Model (DOM) and transmitting its content to Sentry’s servers. To minimize the amount of bytes transferred, multiple strategies are employed:
-  - Once the initial DOM tree is snapshotted, the SDK records and transmits _changes_ (deltas) to the DOM rather than snapshotting the entire tree again. This ensures the smallest amount of state is transmitted to facilitate playback. Additionally, the SDK does not spend CPU cycles scanning for changes itself; instead it listens for changes emitted by [`MutationObserver`](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver), an internal browser API.
-  - DOM content itself is gzip compressed client-side before transmission over HTTP. The compression operation is executed in a background thread using a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers), which means the browser’s UI thread is unaffected.
-  - The SDK does not cause the browser to download and transmit other static assets, like images, video, etc. Instead during playback, those assets are fetched directly from the original host server.
-- Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s browser connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser.
-- The SDK is built to gracefully downgrade when needed. In the event several thousand DOM mutations happen at once, the SDK will disable recording to make sure recording the website doesn't further degrade user experience. The [mutation limit values are configurable](/platforms/javascript/session-replay/configuration/#mutation-limits).