A dashboard that once loaded in two seconds now takes fifteen. Staff refresh reports repeatedly, customer service waits for account screens, and managers wonder whether the whole application needs replacing. Usually, the right first move is smaller: measure where the time goes, fix the highest-impact bottleneck, and verify the improvement against a repeatable baseline.
Start with the workflow, not the technology
Choose two or three screens that people use every day. For each, document the action, typical data volume, expected result, and actual waiting time. A customer lookup that takes eight seconds deserves more attention than an obscure administrative report that runs once a quarter. Ask users what happens while they wait: do they retry, abandon the task, or export data into spreadsheets?
Record a baseline at the same time of day and with comparable data. Measure the median and the 95th-percentile response time rather than relying on a single fast test. Separate initial page load from a filter change or export. These distinctions keep the project focused on business impact.
Find the slowest link in the request
A typical dashboard involves the browser, an API, a database, and sometimes a third-party service. Use browser network timing and application logs or tracing to determine whether the delay is in downloading a large response, waiting for an API, running a query, or rendering thousands of rows. Add request identifiers so a slow browser action can be correlated with its server-side work. Avoid logging customer records, passwords, or tokens.
Check for common patterns: an API returning every record when the screen displays only twenty; repeated queries for related records; expensive counts on large tables; filters that bypass useful indexes; serial third-party calls; or charts recalculated on every interaction. Each suggests a different fix. Rewriting the frontend will not solve a database query that consumes twelve seconds.
Make targeted improvements
Limit the data. Use server-side pagination, reasonable page sizes, and filters that match how staff search. For large changing datasets, cursor-based pagination can be more stable than deep offsets, but it requires a consistent sort order and careful API design.
Improve query plans. Inspect actual execution plans before adding indexes. A well-chosen index can help frequent filters, but each index also adds storage and write overhead. Confirm improvements using representative production-like data, not an empty development database. For a broader discussion of query tuning, see our guide to database indexes and query performance.
Cache selectively. Reference lists and expensive summaries may be good cache candidates. Define how fresh the data must be, who is allowed to see it, and what invalidates it. Do not cache sensitive customer-specific responses under shared keys.
Render less. Virtualize long tables, defer secondary charts, and avoid unnecessary repeated requests. Test on the devices and connections your employees actually use. Faster APIs help, but perceived speed also depends on what the interface does while waiting.
A realistic two-week performance audit
A fixed-scope engagement can target one application and two or three high-value workflows. In the first few days, inventory the screens, capture timings, review logs and query plans, and identify the leading bottlenecks. Next, implement one or two low-risk improvements behind normal code review and testing. Finish with before-and-after measurements, a rollback plan, and a prioritized backlog for larger work.
Useful deliverables include a baseline report, annotated bottleneck findings, changes with automated regression coverage where practical, a short deployment checklist, and a 30-day monitoring recommendation. Agree on acceptance criteria before coding: for example, improve the 95th-percentile response time for a specific customer search under a defined test dataset, without changing results or access permissions. A percentage target should be based on the measured baseline, not promised in advance.
Know when not to optimize
If a screen is rarely used, the cost of tuning may outweigh the benefit. If the problem is unreliable or inconsistent source data, performance work may not be the right first project. And if a slow report can run asynchronously with a notification when ready, that may be better than forcing it into a synchronous page request. A good audit makes these tradeoffs explicit.
Keep improvements from fading
Set a small number of meaningful metrics, review them after releases, and flag regressions before users start complaining. A part-time engineering retainer can maintain those checks, tackle the next bottleneck, and support incremental improvements without requiring a full-time hire. Pair this with a practical release checklist so a performance fix does not introduce new risk.
Need a business application to feel responsive again? Contact Code Etcetera about a focused performance assessment. We can help identify the highest-value fix, define a bounded implementation, and support follow-up work as needed.