The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A SaaS client's dashboard was taking 4.2 seconds to render every time a user logged in.
The user base was growing, but user retention was dropping. Users were literally refreshing the browser thinking the app had frozen.
Here is how we diagnosed and fixed the issue in a single afternoon dropping query times from 4,200ms to 85ms:
The Diagnosis (Laravel Debugbar & Telemetry) We ran a query trace on the dashboard endpoint. The culprit? A classic nested Eloquent loop pulling customer transaction metrics. Instead of 1 optimized query, the server was executing 180+ database queries per request (the dreaded N+1 problem).
The Fix: Eager Loading & Database Aggregates
Replaced individual loop queries with Eloquent's with() for eager loading.
Replaced memory-heavy PHP array manipulation ($user->orders->sum()) with native database aggregation using withSum() and withCount().
Strategic Indexing We checked the MySQL execution plan (EXPLAIN) and found the transactions table was running full-table scans across 500,000+ rows because user_id and created_at lacked composite indexing. Added a single composite index: $table->index(['user_id', 'created_at']);
The Result:
Database Queries: Reduced from 184 to 3.
Page Response Time: Dropped from 4.2s to 85ms.
Server Load: CPU usage dropped by 65%.
You rarely need expensive server upgrades or a complete system rewrite to fix a slow application. Most of the time, you just need to fix how your code talks to your database.
How fast is your primary user dashboard loading right now?
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
400 renders. Zero manual errors. 🚀
A recent client needed 400 product variants for their Wix store. The problem? Wix randomizes filenames on upload, making bulk organization a nightmare.
I solved this by building a procedural pipeline in Blender to handle the volume and using a strict SKU-based naming system for the files. To bypass the Wix glitch, I hosted the images on a temporary static site to serve them by their original names.
The result: a perfectly synced store and a process that turned days of manual data entry into a seamless technical win.
Hi Zak, let's connect. Useful approach, thanks. Where did you host them? Cloudflare or Cloudinary? Or maybe something else?
How do you show someone where to look on a busy dashboard?
For a manufacturing platform, we tried two ways. A zooms straight into the real interface and highlights what matters. B steps away from the screen and tells the same idea with a simple visual story.
Which one would make you understand it faster, A or B?
5 voted
31%
11 voted
69%
16 votes
Closed
Really interesting comparison! For me, A works faster because it shows the real interface and instantly highlights what matters, so I don't have to guess. B is great for storytelling, but when it's a busy dashboard, seeing the actual UI makes it click right away. Both are beautifully executed though, great thinking behind this!
Our own homepage scored 54 on mobile. Here is how we got it to 99.
We build fast sites for clients. Then we ran PageSpeed on our own homepage and got 54 on mobile.
Three things were doing most of the damage:
1) An autoplaying 4K hero film. It was about 21 MB of a 22 MB page.
2) Google Tag Manager. It alone blocked the main thread for around 4 seconds.
3) A booking widget loading its scripts and cookies on every visit.
What we changed:
• The film became a small poster image. The video now starts on the visitor's first interaction.
• Tags load on first interaction or after 5 seconds. No tag was removed.
• The booking widget is gone.
• Images are served as AVIF and WebP in the right size.
Result on the mobile homepage: 54 to 99. Page weight went from about 22 MB to about 0.5 MB. Total Blocking Time went from 4,740 ms to 30 ms.
One caveat: lab scores move. The same page scored between 86 and 99 on the same day, so we report the median of three runs.
Full write-up with every number: https://codevibe.in/case-studies/website-speed-optimization
If your site feels slow, the hero video and the tag manager are the first two places I would look.
codevibe.in
Website Speed Case Study: PageSpeed 54 to 99 | Codevibe
How Codevibe took its own Next.js site from 54 to 99 on mobile PageSpeed and 100 on desktop: 22,563 KiB to 530 KiB, blocking time 4.7 s to 30 ms.
54 to 99 is wild. the cobblers kids have no shoes thing is so real lol