diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx
index d5ba4a9466ed4..176c9a30c5781 100644
--- a/docs/platforms/android/session-replay/performance-overhead.mdx
+++ b/docs/platforms/android/session-replay/performance-overhead.mdx
@@ -29,7 +29,7 @@ Below are the results of the benchmarking tests, presented as median values to r
 | CPU                              | 36%             | 42%                 |
 | App Startup Time (Cold)          | 1533.35 ms      | 1539.55 ms          |
 | Main Thread Time                 | n/a             | 20ms                |
-| Network Bandwidth                | n/a             | 35 KB               |
+| Network Bandwidth                | n/a             | 7 KB/s of recording |
 
 
 
@@ -38,3 +38,32 @@ Below are the results of the benchmarking tests, presented as median values to r
 Jetpack Compose view hierarchies may be slower to snapshot initially due to ART optimizations, compared to the traditional Android View System. But their performance improves as execution progresses.
 
 </Alert>
+
+## Reducing Performance Overhead
+
+To minimize the performance impact of the Replay SDK, consider the following steps:
+
+### Change Replay quality
+
+Lowering the quality of captured screenshots and videos can significantly reduce CPU, memory, and network bandwidth usage. Here's how you can do it:
+
+```kotlin
+SentryAndroid.init(context) { options ->
+  // this will reduce screenshot compression to 10 and bitrate to 50kbps
+  options.sessionReplay.quality = SentryReplayQuality.LOW // defaults to MEDIUM
+}
+```
+
+### Disable Replay for Low-End Devices
+
+If the Replay SDK causes performance issues on lower-end devices (for example, [this](https://github.com/getsentry/relay/blob/695b459e03481f7d799f07b2b901b140e5d5753d/relay-event-schema/src/protocol/device_class.rs#L21-L37) is how Sentry determines the device class), you can disable it specifically for those devices:
+
+```kotlin
+SentryAndroid.init(context) { options ->
+  options.dsn = "___PUBLIC_DSN___"
+  options.isDebug = true
+
+  options.sessionReplay.onErrorSampleRate = if (isLowEnd()) 0.0 else 1.0
+  options.sessionReplay.sessionSampleRate = if (isLowEnd()) 0.0 else 0.1
+}
+```
diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx
index 2ba8e35afe037..854e56cb7aabb 100644
--- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx
+++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx
@@ -29,4 +29,33 @@ Below are the results of the benchmarking tests, presented as median values to r
 | CPU                              | 4%              | 13%                 |
 | App Startup Time (Cold)          | 1264.80 ms      | 1265 ms             |
 | Main Thread Time                 | n/a             | 43ms                |
-| Network Bandwidth                | n/a             | 50 KB               |
+| Network Bandwidth                | n/a             | 10 KB/s of recording|
+
+## Reducing Performance Overhead
+
+To minimize the performance impact of the Replay SDK, consider the following steps:
+
+### Change Replay quality
+
+Lowering the quality of captured screenshots and videos can significantly reduce CPU, memory, and network bandwidth usage. Here's how you can do it:
+
+```swift
+SentrySDK.start(configureOptions: { options in
+  // this will reduce screenshot compression to 10 and bitrate to 50kbps
+  options.sessionReplay.quality = .low // defaults to .medium
+})
+```
+
+### Disable Replay for Low-End Devices
+
+If the Replay SDK causes performance issues on lower-end devices (for example, [this](https://github.com/getsentry/relay/blob/695b459e03481f7d799f07b2b901b140e5d5753d/relay-event-schema/src/protocol/device_class.rs#L21-L37) is how Sentry determines the device class), you can disable it specifically for those devices:
+
+```kotlin
+SentrySDK.start(configureOptions: { options in
+  options.dsn = "___PUBLIC_DSN___"
+  options.debug = true
+
+  options.sessionReplay.onErrorSampleRate = if isLowEnd() { 0.0 } else { 1.0 }
+  options.sessionReplay.sessionSampleRate = if isLowEnd() { 0.0 } else { 0.1 }
+})
+```
diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx
index 921aeb36a4e89..7d9c1aa5b70c9 100644
--- a/docs/platforms/react-native/session-replay/performance-overhead.mdx
+++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx
@@ -30,7 +30,7 @@ The benchmarks were run on an iPhone 14 Pro and a Pixel 2XL. Note that active Se
 | CPU                              | 4%              | 13%                 |
 | App Startup Time (Cold)          | 1264.80 ms      | 1265 ms             |
 | Main Thread Time                 | n/a             | 43ms                |
-| Network Bandwidth                | n/a             | 50 KB               |
+| Network Bandwidth                | n/a             | 10 KB/s of recording|
 
 
 
@@ -43,4 +43,4 @@ The benchmarks were run on an iPhone 14 Pro and a Pixel 2XL. Note that active Se
 | CPU                              | 36%             | 42%                 |
 | App Startup Time (Cold)          | 1533.35 ms      | 1539.55 ms          |
 | Main Thread Time                 | n/a             | 20ms                |
-| Network Bandwidth                | n/a             | 35 KB               |
+| Network Bandwidth                | n/a             | 7 KB/s of recording |