The screen shows a few requests and a single button. Meanwhile, in the background, the application is loading historical records, reference data, information for hidden dialogs, and data from other systems. The user sees a simple application, but their device is handling a considerable amount of data traffic. Improving performance does not necessarily have to start with changing platforms. Sometimes, it is enough to stop preparing everything for everyone before the first click.
A technician on the production floor wants to confirm a completed inspection using their phone. They need to open a specific task, enter the result, and move on. Instead, the application first prepares data for the entire administrative system, including sections the technician has no reason to access at that moment.
From a developer’s perspective, every individual step may have a reasonable explanation. This list might be useful later, that one should probably be loaded into a collection, and another should be refreshed just in case. Together, however, these operations create work that someone with an entirely different task has to wait for. Good intentions contribute to loading times just as much as any other request.
A Hidden Dialog Is Not the Same as Inactive Logic
One of the less obvious areas to examine involves dialogs and dependencies between screens. Just because something is not visible does not automatically determine when related expressions are evaluated or when the required data is loaded. The actual behavior depends on how the application is designed. That is why it makes sense to monitor real data requests rather than focusing solely on the visibility of controls.
Among its performance recommendations, Microsoft highlights references to controls on screens that have not yet been loaded. These references can cause screens to load before the user actually needs them. Such dependencies may be insignificant in a small application, but as the solution grows, they can become an unnecessary burden.
The practical question is simple: do we need this data right now? A list of equipment for a selection dialog can wait until the dialog is opened. The details of an older inspection report do not need to be downloaded to a phone along with today’s tasks. Appropriate timing does not mean the application must start from scratch every time. It means that every operation should serve a specific purpose.
Collections Are Useful. Storing the Entire Company in One Collection Is Not.
Storing data locally can simplify operations and reduce repeated queries. However, it comes at a cost in terms of initial loading time, memory consumption, and the need to keep information up to date. If local storage becomes the default answer to every problem, the application gradually starts carrying far more data than it actually uses.
The same applies to excessive use of Refresh. Refreshing data may be necessary after a specific change. However, it does not have to be the appropriate response to every unexpected behavior in a form. If several data sources are refreshed whenever the user navigates between screens, it is worth examining which changes those refreshes are actually intended to capture.
Queries repeated for every row in a list also deserve attention. A list displaying ten items may seem modest, but if each item independently retrieves several additional pieces of information, the number of calls can increase rapidly. A different approach to handling relationships, a narrower data selection, or moving some processing closer to the data source may help.
Performance Is Part of the User Experience
Testing should follow the actual user journey: opening the application, finding a task, viewing its details, and saving the result. This should happen on a typical phone with an ordinary network connection, not just in the comfort of a development environment. The important thing is to identify where time is being lost and compare the same sequence of actions after making changes.
There is no need to automatically rewrite the entire application. Eliminating one unnecessary data query, correcting an inefficient dependency, or narrowing an overly broad data load may be a better starting point than a major rebuild. Measurement helps prioritize improvements and distinguish genuine benefits from changes that merely look technically interesting.
For users, the outcome is straightforward: the application does not get in the way of completing their work. At Evenaut, we therefore consider performance an integral part of usability, not a cosmetic improvement to address at the end of a project. After all, the fastest operation is often the one the application never needed to perform in the first place.
Do your employees spend more time waiting for your Power App than working with the form? Contact us at customers@evenaut.com.
