Blog #34: My Machine Runs Smooth, the User's Machine Smokes
When Frontend tries to do the Backend's job by processing tens of thousands of records directly in the user's browser.
2 min read
Monday morning, real user data starts flowing in. Our reporting system begins receiving a wave of complaints: "The website freezes for about 5 seconds every time I click to filter data." I open it up on my machine; everything is still a smooth 60 FPS. I forgot that I'm using a high-spec Macbook, while my users are on dusty old office laptops.
I had made a "conceited" decision earlier: Fetch all 10,000 records to the client so users could filter and sort "smoothly" without calling the API multiple times. I was proud of reducing server resource load.
1. What happened?
Application performance dropped severely on mid-to-low spec devices because the Frontend was carrying too much heavy data processing logic (Data transformation, filtering, sorting).
2. What I thought the cause was
I assumed the JavaScript sort() algorithm was slow or that React components were rendering too much. I went to the trouble of wrapping everything in useMemo, but results barely improved.
3. How I debugged it
I opened the Performance Tab in Chrome DevTools and used the CPU Throttling (6x slowdown) feature to simulate a weak device. The moment I clicked the filter button, the CPU chart showed a long, solid yellow bar (Long Task).
4. The moment of realization
The CPU stayed at 100% for 5 seconds just executing sort() and filter() commands on the massive data array. Frontend isn't the place for large-scale raw data processing. I was too confident in the power of the browser and forgot about the diversity of user hardware.
5. The fix
- Quick patch: Use a Web Worker to move the calculation to a background thread, preventing the browser from freezing (non-blocking), though processing speed remains slow.
- Real fix: Acknowledge the architectural mistake. Move all filtering, sorting, and pagination to the Backend. The Frontend should only receive exactly the 20-50 records needed for display.
6. Looking back
Never turn your user's browser into a miniature database. Respect their computer's resources and keep the Client as lightweight as possible. If I were designing it again, I would prioritize a Server-side Filtering architecture as soon as the project hit the 1,000-record mark.