98% Faster Shipment Dashboard Modernization

Context

This was not a cosmetic refactor. The old customer shipment dashboard had become functionally broken at production scale. For larger accounts, initial page load was routinely 80-90 seconds, which meant users retried requests, opened duplicate tabs, or routed around the dashboard entirely. That defeats the whole point of self-service visibility.

I was working in a mixed environment with legacy PHP and jQuery patterns, domain-heavy shipment records, and understandable fear of breaking a workflow customers touched every day. The project quickly became both an engineering problem and a trust problem: improve the performance bottleneck without disrupting live operations, and do it in a way that made future iteration easier instead of stacking another patch onto brittle code.

Problem

The slowdown came from multiple bottlenecks reinforcing each other:

1. Runtime-heavy backend logic. The request path repeatedly decoded large JSON payloads and looped through nested structures on demand.
2. Unfriendly data shape. Important values were embedded in blobs instead of being query-friendly.
3. Frontend rendering limits. jQuery plus older DataTables patterns were not designed for large, frequently filtered datasets.
4. Re-render churn. Client-side interactions created too much DOM work and too little caching discipline.

No single optimization was going to fix this. Even if one layer got faster, the others still dragged response time down. The real fix required changing both data preparation and UI architecture so the stack worked with the workload instead of fighting it.

Constraints

• Existing users needed uninterrupted access.
• Business rules already encoded in legacy code had to remain accurate.
• Some skepticism toward JavaScript-heavy modernization meant I needed measured outcomes, not framework hype.
• Shipment volume was non-negotiable. We could not solve performance by exposing less data.

There was also an adoption constraint: even a technically better dashboard would fail if operators and customers lost confidence during rollout. Migration planning mattered as much as raw speed improvements.

What I changed

I split the modernization into backend and frontend tracks that could be validated incrementally.

On the backend side, I moved from decode-and-compute request paths toward preprocessed, flatter SQL-ready structures. Instead of dragging large JSON blobs through request loops, I pushed transformation earlier and made common dashboard queries cheaper. That reduced repeated compute and stabilized response behavior across larger datasets.

On the frontend, I rebuilt the dashboard in React with TanStack Table and TanStack Query. The important point was not “React because modern.” It was control. I could define clearer render behavior, caching strategy, and table virtualization for a workload that had already outgrown the older jQuery/DataTables approach.

The performance work included:

• row virtualization to keep mounted row count small
• selective memoization for expensive subtrees
• query caching and refetch discipline with TanStack Query
• lazy loading for non-critical modules
• bundle cleanup to reduce startup cost

I also changed the rollout mechanics. Instead of a hard cutover, I used staged deployment and parallel validation so we could compare behavior on real data before switching over fully.

Validation

Validation started with baseline measurement on real heavy-account views, then repeated measurement after each major change.

Directional before and after:

• Before: 80-90 seconds initial load on heavier shipment views.
• After: generally under 2 seconds initial load on equivalent views.

That is the basis for the directional 98% claim. I am intentionally keeping it directional here because I am not publishing a full historical p95 or p99 benchmark set yet.

I also validated interaction performance, not just first load. Sorting, filtering, and paging stayed responsive on larger tables because virtualization kept DOM work bounded. Profiling during the refactor confirmed we were rendering what users could actually see instead of paying the cost for off-screen rows.

Release behavior improved too. The codebase became easier to change because the dashboard moved toward clearer component and state boundaries instead of one intertwined script path. Internal notes point to roughly a 50% improvement in deployment cadence after the modernization work, but that number should still be treated as directional until tied to audited release history.

Outcome

The practical outcome was straightforward: people started using the dashboard instead of routing around it.

• Users got status faster and with fewer retries.
• Teams spent less time working around visibility gaps manually.
• Engineering iteration improved because the stack was more modular and the bottlenecks were easier to reason about.

There was also a strategic benefit. We were no longer trying to explain away visible legacy friction in a customer-facing workflow. The modernization reduced technical debt and improved product credibility at the same time.

Tradeoffs and lessons

Legacy performance problems almost always span architecture boundaries. If I had only replaced the frontend without changing the backend read model, the improvement would have been smaller and less durable. If I had only optimized backend processing but kept the old rendering model, the UI still would have struggled at scale.

I also came away with a stronger view on incremental modernization. In production systems with real users, the hard part is not deciding that the old stack is imperfect. The hard part is creating a path that improves the system without disrupting the people who depend on it today.

There are tradeoffs in a preprocessing and flattened-data approach. You gain runtime speed and simpler reads, but you also take on more up-front modeling work and have to be deliberate about freshness, invalidation, and where derived state should live.

What I’d improve next

If I were taking this to a second modernization pass, I would focus on three things:

• building a more formal benchmark harness so future claims are tied to repeatable test cases
• adding stronger regression checks around heavy-table rendering and slow-query detection
• documenting the read-model and frontend performance patterns so similar legacy surfaces can be upgraded faster

If you need someone who can modernize legacy systems without breaking live operations, let’s talk.