Tobias Glöckler Agentic Engineer

How I Cut a Data-Heavy SaaS Dashboard's Load Time by 72%

Tobias Glöckler

Tobias Glöckler

Agentic Engineer

A growing SaaS was buckling under its own data, list pages took seconds to load and the founder was about to pay for a bigger backend plan. The real bottleneck was elsewhere. I found it, fixed it, and saved him the upgrade.

  • Page loads up to 72% faster
  • Lighthouse score: 97
  • Saved the cost of a plan upgrade
  • Lower backend bill going forward
Before-and-after bar chart showing dashboard server response dropping from 1.63s to 0.46s, 72% faster

The Situation

As this SaaS grew, its users generated a lot of data, and the pages that had to show it slowed to a crawl. The main list views were taking two to three seconds to load, and the app felt heavy to everyone using it.

That kind of delay quietly costs a business. A Google-commissioned study by Deloitte found that trimming mobile load times by as little as 0.1 seconds lifted conversions through the buying funnel and increased how much shoppers spent by 9.2%. Slow software gets used less.

The founder had concluded the backend was simply too slow and was ready to upgrade to a more expensive plan to fix it. Before he spent that money every month, he asked me to take a look.

What I Did

I started with measurement, not guesswork. Using Lighthouse, I profiled the slow pages and found the backend plan wasn’t the problem at all, the app was just asking it to do far more work than it needed to. So I cut the waste:

  • Only load what’s on screen. Pages were pulling entire database tables on the first load. I changed them to fetch small summaries and just the first visible page of results, with pagination for the rest.
  • Stop recalculating everything. One key figure was being counted by looping through full records in code. I moved that work into the database and used pre-computed counters, so the count comes back instantly.
  • Run requests side by side. Independent lookups were happening one after another, including the login, permission, and data checks on admin pages. I made the ones that don’t depend on each other run at the same time.
  • Reuse the login, don’t repeat it. The app was re-checking the user’s session and token multiple times per page. I validated it once and reused it.
  • Defer the rest. Detail data now loads only when someone opens a case, and large product images were replaced with compact thumbnails that load as you scroll.

The Results

The dashboard’s server time dropped from 1.63s to 0.46s, 72% faster. The two heaviest pages followed: the Cases view went from 2.84s to 1.20s (58% faster) and Products from 3.07s to 1.24s (60% faster). Lighthouse now scores the app 97 for performance.

Lighthouse performance score of 97 out of 100 after the optimization

Just as importantly, the founder didn’t need the bigger backend plan. The slowness was never about capacity.

On the pages I optimized, the app now reads an estimated 50–90% less data from the database, which keeps that recurring bill down as the product keeps growing. He got a faster product and saved money he was about to spend every month for no benefit.

Is your product getting slower as it grows?

If your app feels sluggish under real user data, and you're wondering whether the fix is a bigger plan or better engineering, let's find the actual bottleneck before you spend a cent more.

Let's talk
Share:
Copied article link
Tobias Glöckler

Tobias Glöckler

Agentic Engineer

Building AI automations, custom software, and web products.