Performance work is easiest to prioritise when it is connected to a repeated task. A visually impressive homepage matters less to an internal team than a customer search that pauses on every keystroke. Start with the journeys staff perform frequently and the conditions in which they use them. Then agree measurable expectations and use them to evaluate additions to the application.
Measure the ordinary working day
Imagine a Bendigo parts supplier whose counter staff search for a customer, locate a product and create a quote while speaking with a caller. Measure those steps with a realistic catalogue and customer list. A demonstration with twenty records may conceal delays that appear with years of business history. Include the usual office connection, common browsers and realistic concurrent activity. Record where people wait and whether the interface explains what is happening. A short pause with clear feedback may be less disruptive than an unexplained screen that appears frozen.
Set budgets with an operational purpose
The web.dev performance budget guidance describes setting limits on measures that affect performance and checking changes against them. Apply that idea to your important tasks. You might set an agreed expectation for when search results become usable, then investigate changes that make it worse. Choose limits from your actual baseline and needs rather than copying a target without context. Include the size of the data being tested. A budget that is only met with an empty database does not describe the experience the team will have.
Spend effort where it changes the workflow
Possible improvements include loading only the records needed, reducing unnecessary requests, making a slow report run in the background or simplifying a heavy screen. Each has a tradeoff. A background report needs progress and completion feedback. Cached information needs a clear freshness rule. A shorter result list needs useful filtering. Ask the implementer to explain the user-visible consequence of a proposed optimisation. Avoid measuring only the first page load while ignoring the repeated actions that dominate the working day, such as switching between jobs or saving a long form.
Keep a small regression check
Choose three representative journeys and repeat their measurement after material changes. Retain the test conditions so comparisons remain meaningful. Review outliers as well as typical results; the occasional very slow save can create uncertainty and duplicate submissions. Record:
- The task, data size, browser and connection used in the check.
- The agreed performance expectation and observed result.
- Whether the interface remains usable while work is processing.
- Any freshness, pagination or background-processing tradeoff introduced by the improvement.