We cut a dashboard's load time from 6 seconds to 1.2 — without a rewrite

What the dashboard was doing wrong

First load was 6.1 seconds on a mid-range laptop over decent wifi. On 4G it was 11. Users were complaining. The CEO thought the stack was the problem — 'maybe we should move off Next.js' — which is almost never the right answer.

We asked for two days of read-only access instead of a rewrite quote. They agreed. Here's what we found.

The four things that mattered

Every page was client-rendered. The team had adopted Next.js but was treating it like a create-react-app project. Every route started with a blank shell, then waterfalled through three API calls before a single pixel of real content appeared. Moving the main dashboard to a server component dropped time-to-content by 2.8 seconds on its own.

The chart library was 340kb. They were using a full-featured charting package for two bar charts. Swapping it for a 12kb alternative cut the main bundle by a third. The charts look identical.

Images were being served at 4000×3000. The avatar component was loading the original upload from S3 and resizing it in CSS. One line change to route through an image optimizer — the images are now 80kb each instead of 2MB.

The API was doing an N+1. Every row in the main table triggered a separate call for the user's team name. Classic. One join fixed it. P95 on that endpoint went from 1.8s to 140ms.

What we did not do

• Change frameworks
• Rewrite the data layer
• Introduce a new caching system
• Add a CDN they already had

Total engineering time: four days. Total cost: less than 10% of the rebuild quote they were about to sign.

The lesson

Almost every 'we need a rewrite' conversation we've had in the last two years turned out to be a performance audit in disguise. Rewrites feel decisive. They're also 12 months of risk for problems you could fix in a week.

Before you approve a rebuild, get someone to open the network tab for an afternoon. It's the cheapest consulting engagement you'll ever pay for.