Cutting Dashboard Latency and Hosting Cost

Diagnosing why the dashboard felt slow in development, and why hosting bills were higher than the traffic justified, then cutting both.

• Measured
• Found the root causes
• Fixed both the latency and the cost drivers

• Measure first

  Warm navigations took 0.07–0.14 s and the backend answered in 15–120 ms, so it was cleared immediately. Cold on-demand route compilation (2–11 s) was the entire cost.

• Remove needless revalidation

  39 pages revalidated hourly. Only 4 read the CMS; the other 35 read static data (1,421 combination pages) that only changes at deploy, so their revalidation was removed.

• Build only the main branch

  About 300 pushes across 40 branches each triggered a preview build. Previews are now opt-in.

• Drop a duplicate add-on

  A paid observability add-on was turned off, since error tracking was already covered.

1. 1.Compile time doubled

   The build cache had reached about 5 GB, plus several GB of old working copies, on a 16 GB machine already deep in swap. Stale dev servers had been running for 10–11 days.

2. 2.Cleaning isn't free

   Wiping the cache can break the app if a remote font fetch fails.

3. 3.Collaborative boards

   Realtime providers are cached in a small LRU, so switching boards no longer rebuilds connections, with a cross-tab logout flush.

• Teachers route: 11.0 s → 3.8 s
• Expenses route: 6.8 s → 1.6 s
• Availability route: 4.2 s → 1.9 s
• Hourly regenerations for static pages: 35 pages → 0
• Monthly hosting spend: $24.83 → [X], with ISR writes ($8.93) and build CPU ($6.27) as the top two targets
• Production LCP / INP on key pages: [X → Y]

• "Slow" is a hypothesis. Time the cold and warm paths separately before touching code.
• A revalidate interval on content that only changes at deploy is a standing bill.
• Dev-environment hygiene (stale processes, cache size) is part of performance.