DEV Community: Pritam Patra

From 2.0 MB to 471 KB: Debugging Rawbee with Sentry + Gemini

Pritam Patra — Sun, 16 Aug 2026 21:37:22 +0000

I Thought Rawbee Was Slow — Then I Opened the Network Tab

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Project

Rawbee is a full-stack video-sharing and real-time streaming platform that I built as a YouTube-inspired application.

It currently includes:

Video uploads
Video discovery
Subscriptions
Watch history
Live streaming
WebRTC-based functionality
Screen sharing
Socket.IO communication
Cloudinary media delivery

The stack includes:

Frontend: React 18, TypeScript, Tailwind CSS, Vite
Backend: Node.js, Express
Database: MongoDB
Media: Cloudinary
Real-time: Socket.IO, WebRTC
Observability: Sentry
AI debugging: Google Gemini

Repository: View Rawbee on GitHub

Bug Smash PR: View the Pull Request

For this Bug Smash, I deliberately stopped adding new features and focused on one question:

Where is Rawbee doing unnecessary work, and can I prove that my fixes actually made it better?

The Moment I Realized Something Was Wrong

Nothing was obviously broken.

The homepage loaded. Videos appeared. Search worked.

But the application felt heavier than it should.

My first instinct was to blame React.

When I typed into the search bar, the parent component updated and the video-card tree was being evaluated again.

So I opened React DevTools and started profiling.

The profiler showed repeated VideoCard renders during a simple interaction, even when the underlying video data had not changed.

That was the first bug.

Then I opened the Network tab.

And I found a much bigger problem.

The Network Tab Changed Everything

The production homepage was transferring approximately:

2.0 MB

Some individual image assets were enormous for their displayed size:

834 KB
433 KB
160 KB

An 834 KB thumbnail for a relatively small video card immediately looked wrong.

At that point, the problem stopped being:

"The page feels slow."

and became:

"The browser is downloading far more data than this UI should need."

Before: Production Baseline

📸 SCREENSHOT 1 — BEFORE NETWORK

Production baseline before optimization. The homepage transferred approximately 2.0 MB, with individual image assets reaching 834 KB, 433 KB, and 160 KB.

The baseline showed:

30 requests
2.0 MB transferred
2.3 MB resources
593 ms DOMContentLoaded
2.61 s Load
2.82 s Finish

For the first time, I had a real baseline instead of a vague feeling that the application was slow.

Fix #1 — Stopping Unnecessary React Renders

The first fix was React.memo().

The problem looked roughly like this:

Search state changes
        ↓
Home re-renders
        ↓
VideoCard renders again

But if the video's data hasn't changed, that child component doesn't necessarily need to render again.

I changed the component to:

import { memo } from "react";

const formatDuration = (seconds: number) => {
  // ...
};

const formatViews = (views: number) => {
  // ...
};

const VideoCard = memo(function VideoCard({
  video
}: VideoCardProps) {
  return (
    <div className="group cursor-pointer">
      {/* Video card UI */}
    </div>
  );
});

export default VideoCard;

I also moved pure formatting helpers outside the component so their definitions weren't recreated during every component execution.

The important optimization, however, was React.memo() combined with stable props.

When the video prop remains referentially equal, React can skip rendering the component.

React Profiler — Before

📸 SCREENSHOT 2 — REACT PROFILER BEFORE

Before memoization: VideoCard renders repeatedly during the recorded interaction as parent state changes.

The profiler gave me a concrete reason to make the optimization instead of blindly applying React.memo().

React Profiler — After

📸 SCREENSHOT 3 — REACT PROFILER AFTER

After memoization: the Profiler explicitly reports "Did not render on the client during this profiling session." The memoized component is skipped when its props remain unchanged.

The important result wasn't the raw number of React commits.

It was seeing React actually skip the component when its props remained unchanged.

Fix #2 — The 834 KB Thumbnail

The React optimization removed unnecessary rendering work.

But the Network tab was still pointing at the much larger problem:

image delivery.

The original application requested full-size images from Cloudinary even when the UI only needed a relatively small thumbnail.

I created a helper:

const getOptimizedCloudinaryUrl = (
  url: string,
  width = 500
) => {
  if (!url || !url.includes("cloudinary.com")) {
    return url;
  }

  return url.replace(
    "/upload/",
    `/upload/w_${width}/f_auto/q_auto/`
  );
};

Then:

<img
  src={getOptimizedCloudinaryUrl(
    video.thumbnail,
    500
  )}
  alt={video.title}
/>

The transformation uses:

w_500 to resize the image
f_auto to let Cloudinary select an appropriate format
q_auto to optimize quality

Before optimization, some image responses were approximately:

834 KB
433 KB
160 KB

After optimization, examples included:

7.3 KB
2.0 KB
22.0 KB
2.6 KB

This became the biggest contributor to the overall network improvement.

Instead of:

2.0 MB

the optimized production build transferred:

471 KB

That's a:

76.5% reduction in transferred data.

After: Optimized Production Build

📸 SCREENSHOT 4 — AFTER NETWORK

Same page, same throttling, same cache-disabled conditions. Payload dropped from 2.0 MB to 471 KB and Load time from 2.61 s to 1.60 s.

Fix #3 — Why Load JavaScript for Pages the User Hasn't Opened?

Rawbee contains multiple routes.

But a user visiting the homepage doesn't need every page's JavaScript immediately.

So I introduced route-level code splitting using React.lazy() and Suspense:

import { lazy, Suspense } from "react";

const Home = lazy(
  () => import("./pages/Home")
);

const Login = lazy(
  () => import("./pages/Login")
);

function App() {
  return (
    <Router>
      <Suspense <div className="flex h-screen items-center justify-center" fallback="{">
            Loading...
          </div>
        }
      >
        <Routes>
          <Route element="{<Login" path="/login"/>}
          />

          <Route element="{<Home" path="/"/>}
          />
        </Routes>
      </Suspense>
    </Router>
  );
}

Instead of:

Application
    ↓
Everything loads immediately

the browser can now load:

Current route
    ↓
Current route chunk
    ↓
User navigates
    ↓
Additional route chunk

This keeps the initial JavaScript workload focused on the route the user is actually visiting.

Fix #4 — Cleaning Up Sentry Configuration

While working on observability, I also found that the Sentry DSN was hardcoded in the source.

I moved it to environment configuration.

Before:

Sentry.init({
  dsn: "your_dsn_here"
});

After:

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN
});

with:

VITE_SENTRY_DSN=your_dsn_here

This makes the configuration easier to manage across environments and keeps environment-specific configuration outside application source.

Fix #5 — When MongoDB Stopped Connecting

While working on the frontend, I encountered a completely different problem.

MongoDB stopped connecting and the backend reported:

querySrv ECONNREFUSED

At first, I treated it as a MongoDB problem.

But the failure was occurring during DNS/SRV resolution.

I investigated the DNS behavior using:

Resolve-DnsName <mongodb-host>

After confirming the DNS resolution problem in my Windows environment, I changed the MongoDB connection strategy to a direct connection configuration as a workaround.

The backend then reconnected successfully.

Best Use of Sentry

Sentry became part of my debugging workflow rather than something I added only after the application was finished.

My process became:

Runtime problem
      ↓
Sentry captures the event
      ↓
Inspect issue + stack trace + context
      ↓
Locate affected code
      ↓
Fix
      ↓
Verify

One concrete example happened during a refactor.

I accidentally removed an import for VideoSkeleton.

The application could still build successfully.

But when the loading path executed at runtime, the browser threw:

ReferenceError: VideoSkeleton is not defined

Sentry captured the runtime failure and provided the stack trace and surrounding debugging context.

Instead of:

"Something is broken."

I now had:

"This exact runtime path is throwing this exact error."

📸 SCREENSHOT 5 — SENTRY ISSUE

Sentry captured the runtime failure with the stack trace and execution context used during debugging.

Sentry and React Profiler Answered Different Questions

One of the biggest lessons from the project was that different debugging tools answer different questions.

Sentry

What is failing?

React Profiler

What is rendering?

Chrome Network

What is the browser downloading?

Using separate tools for separate questions made the investigation much clearer.

Best Use of Google AI

I used Google Gemini 3.1 Pro as a debugging partner rather than simply asking it to generate code.

The MongoDB DNS error was the clearest example.

I provided Gemini with:

The querySrv ECONNREFUSED error
My Windows environment
Node.js information
The MongoDB connection behavior

Gemini helped investigate possible causes involving DNS resolution, MongoDB SRV records, and IPv4/IPv6 behavior.

One useful diagnostic was:

Resolve-DnsName _mongodb._tcp.cluster0.x3qwygg.mongodb.net

I ran the command myself.

That distinction was important:

I treated Gemini's response as a hypothesis, not as proof.

I independently verified the behavior before changing the connection configuration.

The debugging loop became:

MongoDB querySrv ECONNREFUSED
        ↓
Gemini analysis
        ↓
DNS / IPv4-IPv6 hypothesis
        ↓
Resolve-DnsName verification
        ↓
Connection configuration workaround
        ↓
Backend restored

📸 SCREENSHOT 6 — GEMINI DEBUGGING

Gemini helped narrow down the MongoDB connection failure; I independently verified the suggested diagnostic path before implementing the workaround.

The useful part of AI debugging wasn't:

"AI wrote code for me."

It was:

"AI helped me turn an unfamiliar error into a testable hypothesis."

The Final Benchmark

After applying the fixes, I repeated the production benchmark under the same conditions:

Chrome
Fast 4G throttling
Browser cache disabled
Same homepage
Same machine
Same production preview workflow

Metric	Before	After	Change
Network transferred	2.0 MB	471 KB	−76.5%
Resources loaded	2.3 MB	767 KB	−66.7%
Load event	2.61 s	1.60 s	−38.7%
Finish	2.82 s	1.81 s	−35.8%
Requests	30	32	+2
DOMContentLoaded	593 ms	624 ms	+31 ms

The two numbers I cared about most were:

2.0 MB → 471 KB

76.5% less network data transferred

and:

2.61 s → 1.60 s

38.7% faster Load event

What Didn't Improve

Not every metric improved.

The request count changed:

30 → 32

and DOMContentLoaded changed:

593 ms → 624 ms

I also had a stale thumbnail returning a 404, which I flagged as follow-up work.

I don't want to turn a benchmark into:

"Everything got better."

It didn't.

The meaningful result was the large reduction in transferred data and the improvement in the Load event.

Those are the results I can actually demonstrate.

What I'm Most Proud Of

The thing I'm most proud of isn't a particular line of code.

It's the change in how I approached the problem.

Before this work, my instinct would have been:

"The application feels slow. I should optimize the code."

Now the process is:

Observe
   ↓
Measure
   ↓
Hypothesize
   ↓
Test
   ↓
Fix
   ↓
Measure again

I thought React rendering was the main problem.

Then the Network tab showed me that an 834 KB thumbnail was a much bigger issue.

That was a useful reminder:

The thing that feels slow isn't always the thing that is actually expensive.

What I Learned

Profile before optimizing

React.memo() is useful when you can identify unnecessary renders.

The profiler gave me evidence to make the change.

Network payload matters

A frontend can have clean React code and still feel slow if the browser downloads unnecessary data.

Observability changes debugging

Sentry turned runtime errors into actionable issues instead of vague UI failures.

AI works best with verification

Gemini helped me investigate the MongoDB problem faster, but I still tested the hypothesis myself.

Not every metric needs to improve

A useful benchmark should report the actual result, including the numbers that didn't move in the desired direction.

What's Next for Rawbee?

The Bug Smash focused on performance, reliability, and debugging.

But Rawbee is still evolving.

The next direction is a more interactive social streaming experience.

Future work includes:

Live Rooms
WebRTC video/audio
Screen sharing
Real-time Socket.IO chat
Synchronized watch parties
Multi-user co-streaming
Host controls

The goal is eventually to let users watch, communicate, and participate together without needing a separate application for every part of the experience.

These are future roadmap features and are not included in the performance measurements above.

Final Result

The most important transformation was:

2.0 MB → 471 KB

A 76.5% reduction in network transfer.

The Load event changed from:

2.61 s → 1.60 s

A 38.7% improvement.

Along the way I also:

Reduced unnecessary VideoCard rendering
Optimized Cloudinary image delivery
Added route-level code splitting
Improved Sentry configuration
Diagnosed a MongoDB DNS/SRV failure
Used Sentry for runtime observability
Used Gemini to accelerate debugging

No rewrite.

No new framework.

Just:

Measure → Understand → Fix → Verify

Links

Rawbee Repository:
https://github.com/Pritam-mb/rawbee

Bug Smash Pull Request:
https://github.com/Pritam-mb/rawbee/pull/1

Thanks for reading.

And thanks to DEV and Sentry for giving me a reason to stop adding features for a moment and ask:

How well does the application I've already built actually work?

Slashing Network Payload by 76%: How I Used Sentry and Gemini to Optimize a Real-Time Streaming Platform

Pritam Patra — Sun, 16 Aug 2026 19:21:13 +0000

From 20+ Unnecessary Renders to a 76.5% Smaller Network Payload — How I Optimized Rawbee with Sentry + Gemini

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Project: Rawbee — Collaborative Real-Time Streaming Platform
Implementation: View the GitHub Pull Request
Repository: View the GitHub Repository

Rawbee is a full-stack video sharing and live streaming platform with traditional VOD features (uploads, subscriptions, watch history) alongside a WebRTC-based collaborative streaming engine for co-streaming, screen sharing, and in-browser voice/video chat.

The current stack includes:

Frontend: React 18, TypeScript, Tailwind CSS, Vite
Backend: Node.js, Express
Database: MongoDB
Media: Cloudinary
Observability: Sentry
AI debugging assistant: Google Gemini

For the Summer Bug Smash, I focused on improving the existing application rather than adding a new feature.

My goal was simple:

Find real problems → measure them → understand the root cause → fix them → measure again.

During the Bug Smash, I addressed frontend performance issues, a backend reliability problem, and runtime errors surfaced through Sentry.

Bug Fix or Performance Improvement

As Rawbee grew, the homepage started doing more work than necessary.

The first issue appeared while using the search bar. Updating the search state caused the parent component to re-render, and the video-card grid was repeatedly evaluated even when individual video data had not changed. React Profiler confirmed repeated VideoCard renders during the interaction, which led me to investigate whether those renders were actually necessary.

The second problem was visible directly in Chrome DevTools. The homepage was transferring a surprisingly large amount of data, with several individual image assets reaching hundreds of kilobytes.

The original production trace contained images such as:

834 KB PNG
433 KB JPEG
160 KB JPEG

I also found that the frontend was loading more JavaScript up front than necessary because page-level code was not being split efficiently.

On the backend, MongoDB was failing to connect in my Windows environment with:

querySrv ECONNREFUSED

Finally, Sentry was capturing frontend runtime errors that gave me useful visibility into failures occurring inside the application.

Controlled Before/After Benchmark

To make the performance comparison meaningful, I benchmarked the before and after production builds using the same setup:

Chrome
Fast 4G throttling
Browser cache disabled
Same homepage
Same machine
Same production preview workflow

Metric	Before	After	Improvement
Network transferred	2.0 MB	471 KB	76.5% reduction
Resources loaded	2.3 MB	767 KB	66.7% reduction
Load event	2.61 s	1.60 s	38.7% faster
Finish	2.82 s	1.81 s	35.8% faster
Requests	30	32	No improvement
DOMContentLoaded	593 ms	624 ms	Slightly higher

I am deliberately reporting the metrics that actually improved instead of dressing every measurement as a win. Request count went slightly up, partly because of a stale thumbnail returning 404, and DOMContentLoaded shifted marginally within measurement noise.

The headline result is the 76.5% payload reduction.
The biggest measurable gain came from reducing the amount of image data transferred to the browser.

Before: Production Benchmark

Production baseline before optimization. The homepage transferred approximately 2.0 MB, dominated by unoptimized image assets — including an 834 KB PNG, a 433 KB JPG, and a 160 KB JPG.

After: Production Benchmark

Same page, same throttling, same cache-disabled conditions. Payload dropped from 2.0 MB to 471 KB and Load time from 2.61 s to 1.60 s.

Code

The complete implementation is available in the GitHub Pull Request.

The main changes covered:

React.memo
Cloudinary image transformations
React.lazy / Suspense
MongoDB connection workaround
Sentry configuration improvements

1. Memoizing `VideoCard`

import { memo } from "react";

const formatDuration = (seconds: number) => {
  // ...
};

const formatViews = (views: number) => {
  // ...
};

const VideoCard = memo(function VideoCard({
  video,
}: VideoCardProps) {
  return (
    <div className="group cursor-pointer">
      {/* Video card UI */}
    </div>
  );
});

export default VideoCard;

The important optimization here is React.memo.

When the parent component updates, React can skip rendering the memoized VideoCard if the video prop remains referentially equal.

I also moved pure formatting helpers outside the component so they are not recreated as part of each component execution.

2. Cloudinary Image Optimization

This was the single biggest performance win in the benchmark. An 834 KB PNG for a card thumbnail was far larger than necessary for the displayed dimensions.

const getOptimizedCloudinaryUrl = (
  url: string,
  width = 500
) => {
  if (!url || !url.includes("cloudinary.com")) {
    return url;
  }

  return url.replace(
    "/upload/",
    `/upload/w_${width}/f_auto/q_auto/`
  );
};

Then:

<img
  src={getOptimizedCloudinaryUrl(video.thumbnail, 500)}
  alt={video.title}
/>

The w_500 resizes to display dimensions, f_auto serves modern formats (WebP/AVIF) where supported, and q_auto picks quality intelligently.

The before trace contained image responses of 834 KB, 433 KB, and 160 KB. The after trace shows the same images at 7.3 KB, 2.0 KB, 22.0 KB, and 2.6 KB. This single change is the primary contributor to the 2.0 MB → 471 KB reduction.

3. Route-Level Code Splitting

import { lazy, Suspense } from "react";

const Home = lazy(() => import("./pages/Home"));
const Login = lazy(() => import("./pages/Login"));

function App() {
  return (
    <Router>
      <Suspense
        fallback={
          <div className="flex h-screen items-center justify-center">
            Loading application...
          </div>
        }
      >
        <Routes>
          <Route path="/login" element={<Login />} />
          <Route path="/" element={<Home />} />
        </Routes>
      </Suspense>
    </Router>
  );
}

This moved page-specific JavaScript into route-level chunks instead of requiring every page to be part of the initial route workload.

4. Sentry Environment Configuration

// frontend/.env

+ VITE_SENTRY_DSN=your_dsn_here

// frontend/src/main.tsx

Sentry.init({
-  dsn: "your_dsn_here",
+  dsn: import.meta.env.VITE_SENTRY_DSN,
});

This makes the configuration easier to manage across different environments.

5. MongoDB DNS Failure

The backend was failing with:

querySrv ECONNREFUSED

I investigated the DNS behavior in the Windows environment and used:

Resolve-DnsName <mongodb-host>

to verify the DNS resolution problem.

I then switched to a direct MongoDB connection configuration as a workaround for the affected environment, restoring database connectivity.

My Improvements

1. Eliminating unnecessary React work

The first performance problem was component-level rendering.

A search update causes the Home component to update, but an individual video card does not necessarily need to update with it.

Before optimization:

Search state changes
        ↓
Home updates
        ↓
VideoCard repeatedly renders

After optimization:

Search state changes
        ↓
Home updates
        ↓
React.memo checks props
        ↓
VideoCard render skipped when props are unchanged

React Profiler Evidence

React Profiler evidence — before:

Before memoization: VideoCard renders repeatedly across the profiling session as parent state updates.

React Profiler evidence — after:

After memoization: the Profiler explicitly reports "Did not render on the client during this profiling session." The memoized component is skipped entirely when props are unchanged.

React Profiler evidence for the memoized component. The optimized VideoCard was skipped during the recorded interaction when its props remained unchanged.

I am intentionally not presenting the React commit count itself as the number of renders. The important result is that the profiler directly shows the memoized component being skipped.

2. Reducing image payload

The largest measurable performance improvement came from image delivery.

The original production trace contained image resources such as:

834 KB
433 KB
160 KB

After applying Cloudinary transformations, the optimized trace contained much smaller responses, including examples around:

7.3 KB
2.0 KB
22.0 KB
2.6 KB

This change was the main contributor to:

2.0 MB → 471 KB

or a 76.5% reduction in transferred data.

3. Reducing initial JavaScript work

The route-level React.lazy() change means that the browser no longer needs to load code for every page before the current route can operate.

Before:

Initial application
├── Home
├── Login
├── other route code
└── dependencies

After:

Initial route
├── shared dependencies
└── current page chunk

Additional page
└── loaded on demand

This keeps the initial route focused on the code it actually needs.

4. Backend reliability improvement

The MongoDB issue was not treated as a performance metric because it was fundamentally a reliability problem.

The debugging process was:

MongoDB connection fails
        ↓
querySrv ECONNREFUSED
        ↓
DNS investigation
        ↓
Resolve-DnsName verification
        ↓
Direct connection workaround
        ↓
Backend connectivity restored

This fix removed a development blocker that was preventing the API from connecting to the database.

Best Use of Sentry

I am submitting this project for the Best Use of Sentry category.

Sentry became part of the debugging workflow rather than simply being another dependency.

The workflow was:

Runtime problem
      ↓
Sentry captures the event
      ↓
Inspect issue + stack trace
      ↓
Locate affected code
      ↓
Fix
      ↓
Verify application behavior

During development, Sentry captured frontend runtime errors including:

ReferenceError: VideoSkeleton is not defined

Sentry provided:

issue details
event information
stack trace
browser/environment context
affected execution path

That helped me move from:

"Something is broken."

to:

"This specific code path is failing for this specific reason."

Sentry Evidence

Sentry became part of my debugging loop, not just a dependency in package.json. The workflow was consistent throughout the Bug Smash:

Runtime failure → Sentry captures event → inspect issue + stack trace + context → locate affected code → fix → verify.

One concrete example: during a refactor, I accidentally removed an import for VideoSkeleton. It didn't crash the build — it only threw at runtime when the loading state triggered. Without Sentry I'd have found it eventually when a user reported a blank page. With Sentry, I had it within minutes:

Sentry captured the ReferenceError with the full stack trace, release hash, browser and OS context, and event breadcrumbs. This turned "the page is broken sometimes" into a single actionable issue with a direct line to the failing code path.

What Sentry gave me that my terminal couldn't: the release hash tying the error to a specific build, the browser and OS the user hit it on, the URL and route where it happened, and the trace ID linking to surrounding events. That context is what turned a five-word error into a five-minute fix.

Importantly, I used Sentry for runtime observability and React Profiler for component rendering analysis — I didn't conflate them. Sentry told me what was failing; the Profiler told me how components were rendering. Keeping those two evidence streams separate gave me a cleaner picture of the application's actual behavior.

Best Use of Google AI

I am also submitting this project for the Best Use of Google AI category.

I used Gemini 3.1 Pro as a debugging partner during the Bug Smash rather than simply asking it to generate the implementation.

The clearest example was the MongoDB connection problem.

1. Problem

The backend returned:

querySrv ECONNREFUSED

and the application could not establish its database connection.

2. Gemini investigation

I provided Gemini with the error and information about my Windows environment.

Gemini analyzed the failure and suggested investigating DNS and IPv4/IPv6 resolution behavior.

3. Independent verification

I did not blindly copy the recommendation.

I ran the diagnostic myself:

Resolve-DnsName <mongodb-host>

and verified the DNS resolution problem.

4. Implementation

After confirming the issue, I changed the MongoDB connection strategy to use a direct connection configuration that avoided the failing SRV-resolution path.

5. Result

The backend was able to reconnect to MongoDB and resume normal operation.

The overall debugging loop became:

querySrv ECONNREFUSED
        ↓
Gemini analysis
        ↓
DNS hypothesis
        ↓
Resolve-DnsName verification
        ↓
Connection workaround
        ↓
Backend restored

I treated Gemini's response as a hypothesis, not as the final answer. I independently verified the DNS behavior before changing the MongoDB connection strategy.

Gemini Evidence

Use the screenshot showing Gemini analyzing the querySrv ECONNREFUSED problem and discussing the DNS/connection investigation.

Suggested caption: Gemini helped narrow down the MongoDB connection failure; I independently verified the suggested diagnostic path before implementing the workaround.

The important part for me was not simply generating code faster. It was shortening the path from an unfamiliar error to a testable hypothesis.

Final Impact

The clearest measured result was the reduction in network transfer:

2.0 MB → 471 KB

That's a 76.5% reduction.

The Load event changed from:

2.61 s → 1.60 s

which is a 38.7% reduction in Load time.

The total resource footprint changed from:

2.3 MB → 767 KB

which is a 66.7% reduction.

The React Profiler also showed that the optimized VideoCard could be skipped during the recorded search interaction when its props remained unchanged.

The MongoDB issue was resolved as a backend reliability fix, while Sentry and Gemini made the debugging workflow more observable and efficient.

What I Deliberately Did Not Claim

Not every metric improved.

Request count moved from 30 to 32, partly because a stale thumbnail returned 404. DOMContentLoaded moved from 593 ms to 624 ms, which I consider within the noise of this benchmark.

The strongest measured result is the reduction in transferred data from 2.0 MB to 471 KB, followed by the Load improvement from 2.61 s to 1.60 s.

The Sentry runtime event shown in this post was captured in development; validating the same workflow against production traffic is a next step.

Future Roadmap for Rawbee

The Bug Smash was focused on performance and reliability, but I also have a larger direction planned for Rawbee.

The next stage is to turn Rawbee from a traditional video-sharing application into a more interactive, social streaming platform.

Planned future work includes:

Live Rooms where users can create and join shared sessions
WebRTC video/audio calling
Screen sharing
Real-time room chat using Socket.io
Synchronized watch experiences
Multi-user collaborative streaming
Host controls and participant management

The goal is to let users watch and interact together without needing a separate Discord or video-call application.

These real-time features are future work and are not included in the performance measurements reported in this Bug Smash submission.

Conclusion

This Bug Smash started with a simple observation: Rawbee was getting slower as the application grew.

Instead of rewriting large parts of the project, I used measurement and debugging tools to identify where the actual problems were.

The result was a focused set of improvements:

React.memo
      ↓
Less unnecessary rendering

Cloudinary transformations
      ↓
Smaller image payloads

React.lazy + Suspense
      ↓
Route-level code splitting

DNS investigation + MongoDB workaround
      ↓
Backend reliability restored

Sentry
      ↓
Runtime visibility

Gemini
      ↓
Faster debugging investigation

The biggest measurable performance improvement was:

2.0 MB → 471 KB transferred

with the production Load event improving from:

2.61 s → 1.60 s

The main takeaway is simple:

Before optimizing code, measure what the application is actually doing.

That is what I tried to do throughout this Bug Smash: identify the real bottlenecks, fix them deliberately, and verify the results instead of relying on assumptions.

Implementation

GitHub Pull Request: View PR #1

Repository: View Rawbee on GitHub

Thanks for checking out my submission!

DEV Community: Pritam Patra

From 2.0 MB to 471 KB: Debugging Rawbee with Sentry + Gemini

I Thought Rawbee Was Slow — Then I Opened the Network Tab

The Project

The Moment I Realized Something Was Wrong

The Network Tab Changed Everything

Before: Production Baseline

Fix #1 — Stopping Unnecessary React Renders

React Profiler — Before

React Profiler — After

Fix #2 — The 834 KB Thumbnail

After: Optimized Production Build

Fix #3 — Why Load JavaScript for Pages the User Hasn't Opened?

Fix #4 — Cleaning Up Sentry Configuration

Fix #5 — When MongoDB Stopped Connecting

Best Use of Sentry

Sentry and React Profiler Answered Different Questions

Best Use of Google AI

The Final Benchmark

2.0 MB → 471 KB

2.61 s → 1.60 s

What Didn't Improve

What I'm Most Proud Of

What I Learned

Profile before optimizing

Network payload matters

Observability changes debugging

AI works best with verification

Not every metric needs to improve

What's Next for Rawbee?

Final Result

Links

Slashing Network Payload by 76%: How I Used Sentry and Gemini to Optimize a Real-Time Streaming Platform

From 20+ Unnecessary Renders to a 76.5% Smaller Network Payload — How I Optimized Rawbee with Sentry + Gemini

Project Overview

Bug Fix or Performance Improvement

Controlled Before/After Benchmark

Before: Production Benchmark

After: Production Benchmark

Code

1. Memoizing VideoCard

2. Cloudinary Image Optimization

3. Route-Level Code Splitting

4. Sentry Environment Configuration

5. MongoDB DNS Failure

My Improvements

1. Eliminating unnecessary React work

React Profiler Evidence

2. Reducing image payload

3. Reducing initial JavaScript work

4. Backend reliability improvement

Best Use of Sentry

Sentry Evidence

Best Use of Google AI

1. Problem

2. Gemini investigation

3. Independent verification

4. Implementation

5. Result

Gemini Evidence

Final Impact

What I Deliberately Did Not Claim

Future Roadmap for Rawbee

Conclusion

Implementation

1. Memoizing `VideoCard`