Performance testing: where a mobile app loses users
The app consistently passes the demo on a test bench, but for a user on a mid-range device and a mobile network, the screen responds with a delay, the feed stutters while scrolling, and on a weak signal the session drops. These are not "minor bugs" — they are mobile app bottlenecks that only surface under real load.
Performance testing as a separate discipline is needed precisely because lab conditions reproduce neither the diversity of devices, nor network behavior, nor competition for resources with other apps on the phone.
The cost of this blind spot is measurable: a user leaves if the interface does not respond for more than a couple of seconds, and the share of drop-offs grows with the depth of the scenario.
A drop in app performance rarely has a single cause — usually it is a combination of heavy requests at startup, unnecessary screen redraws, memory leaks during a long session, and the absence of caching on repeat navigations.
A pinpoint fix in one place shifts the problem but does not eliminate it: the bottleneck moves to a neighboring scenario.
Interface response delays and growing load on the mobile app manifest as a cascade. While the user waits for a response, they repeat the action — and the app receives a doubled stream of requests that finishes off an already overloaded area.
On a weak channel this turns into timeouts and retries, and on the server into spikes that are not visible in a calm profile.
That is why performance testing of a mobile app begins not with code fixes but with measurements: exactly where time is lost, under which device and network profile, how memory behaves during a long session.
Next, we break down how this is addressed — from profiling real scenarios to the thresholds by which a release passes or fails.
What performance testing provides and what verification modes exist
Profiling: where exactly time is lost
Profiling a mobile application breaks down the rendering frame layer by layer: how much time goes into data preparation, input/output, network waiting, and storage operations.
The engineer sees not "the app is slow," but a specific section — for example, synchronous reading from the local database on the main thread while building a list. Fixing one such spot eliminates frame drops during scrolling by a factor, not by percentages.
Load testing: behavior under peak
Load testing of mobile applications reproduces a real traffic profile: cold start, login, mass requests to a single screen, connection loss mid-operation. We check what happens to the request queue and cache when thousands of devices operate simultaneously.
The result is a known limit: at what number of concurrent sessions the response time remains within norm, and where failures begin.
Production monitoring: response metrics on live devices
Production performance monitoring collects application response metrics from real devices: time to first frame, duration of key operations, share of freezes and crashes.
A lab bench does not reproduce the diversity of models, OS versions, and network quality — production shows what share of users experience operations exceeding acceptable time. This closes the loop: a finding from production returns to profiling.
| Mode | When it fits | Limitations |
|---|---|---|
| One-time check | Before a major release, when there are complaints about speed | Does not catch regressions between releases |
| On-demand profiling | Localizing a known slowdown | Requires a reproducible scenario |
| Load testing | Before audience growth, a sale, a campaign | Requires a realistic traffic profile |
| Continuous monitoring | Ongoing operation of the app in production | Requires metric instrumentation in the code |
Android Profiler and similar tools provide a frame-by-frame picture, but value emerges when measurements are regular and comparable between releases. Then a response slowdown is visible before users notice it, rather than after a spike in failures.
How we conduct performance testing: stages of engineering work
Performance testing begins not with launching a profiler, but with an audit of the application's performance: we collect metrics of startup, interface response, and resource consumption on real devices and in emulators, and record a baseline.
Without it, any further measurement is just numbers without a point of comparison, and the argument "did it get better or worse" turns into a matter of taste.
Next, we build a load testing scheme for the profile of real users: which scenarios dominate, where the peak spikes are, how the network behaves with a weak signal and when switching between Wi-Fi and mobile internet.
- Audit of the current state. We run the key user paths, capture metrics of cold and warm startup, list response, scrolling smoothness, memory and battery consumption. The result is a map of problem areas with reproducible measurements.
- Building the load scheme. We define the scenarios, intensity and duration of runs, the set of devices and system versions. The scheme must replicate real conditions, not a synthetic maximum — otherwise we optimize something the user does not do.
- Setting up profiling. We deploy metric collection on the test bench and on engineers' devices, set up automated scenario runs and storage of measurements between builds. This enables comparison of versions, not a one-off snapshot.
- Checking bottlenecks. We localize the cause: blocking operations on the main thread, unnecessary re-renders, memory leaks, heavy requests to the network or database. We confirm the hypothesis with a measurement before and after the fix, not with an eyeball estimate.
- Repeated runs and regression. After the fixes, we run the same set of scenarios and compare against the baseline. This is how we confirm that the improvement is real and has not broken adjacent paths.
- Handing over the testing results. We deliver to the client's team a report with before/after metrics, reproducible scenarios, and a list of remaining risks, so that the checks can be repeated on their own.
Describe your task — we will come back with an estimate and a plan tailored to your load profile and stack.
How does testing on real devices differ from emulators?
An emulator reproduces the application's logic, but not the physics of the device. It executes code on the workstation's processor, substitutes graphics with software rendering, and has no real modem, gyroscope, camera, or battery.
Therefore, performance testing on an emulator answers the question "does the logic work," but not the question "will we fit within the frame and memory budget on a live device." The gap shows up where hardware dictates behavior: throttling under load, behavior when memory is full, real write speed to storage.
Performance differences start with the processor and memory. A desktop chip holds a stable frequency, while a mobile one goes into thermal throttling after a few minutes of load — an application that is smooth on an emulator drops frames on a phone specifically in long scenarios.
The emulator allocates the host's memory to the application and does not show how the system evicts background processes: on a device with a small amount of memory, the garbage collector triggers more often, and the system may kill the application when switching tasks.
Network conditions in tests are the second source of discrepancies. The emulator provides a steady channel through the host machine, whereas a real network changes connection type, loses packets, and switches between generations of communication on the fly.
Scenarios like "weak signal," "transition between networks," "return from background with data reloading" are reproduced only on a physical device, because they depend on the modem and power-saving policies.
Hardware limitations add what is not emulated in principle: a real screen with high pixel density, sensors, camera, biometrics, different manufacturers of chips and firmware.
Hence the practice: emulators cover fast regressions and logic checks across many configurations, while testing on real devices is the final measurement before release on a matrix of several models of different classes.
Physical devices are indispensable where frames under load, battery consumption, behavior under a weak network, and stability on weak hardware matter.
Case study: how we reduced response time and eliminated crashes in the app
A delivery service came to us: the app worked, but on the order list screen, "white" cards appeared during scrolling, and when returning from the background, the session dropped and the user had to log in again.
Measurements on real devices showed: cold start was dragging on, and on low-end models the app crashed when loading images in the feed.
The problem was not a single bug, but the absence of a system — performance was not measured regularly, so regressions accumulated from release to release.
What the measurements showed before the changes
We captured a profile on a mid-range and a low-end device, and ran through the scenarios: launch, login, feed scrolling, checkout, return from background.
It turned out that the bottleneck was synchronous loading and decoding of images on the main thread: the interface was blocked, frames dropped, and the lack of memory on low-end models led to forced closure.
Separately, a leak surfaced: screens did not release listeners, and after ten navigations, memory consumption grew linearly.
What we changed
- Moved image loading and decoding to background tasks with limited concurrency and caching by screen size.
- Rewrote the screen lifecycle: listeners are removed on exit, state is restored after returning from the background.
- Introduced a performance budget into the build: checking launch time, scrolling smoothness, and memory on every change.
- Set up automatic scenario runs on real devices before release.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Cold start | 4.1 s | 1.6 s |
| Dropped frames during scrolling | 18% | 2% |
| Crashes on low-end devices | 6.4% of sessions | 0.3% of sessions |
| Memory growth over 10 navigations | +140 MB | +8 MB |
The failure class "crash during content loading" disappeared completely, and "interface freeze" was reduced to isolated cases. Regressions are now caught before release, not in reviews.
We built the measurement methodology and performance budget thresholds on the Firebase Performance Monitoring approach — it provides a snapshot from users' real devices, not just from test benches.
Doubts and what you get in hand after performance testing
Before the start, customers usually ask the same questions: will the release environment have to be rewritten, what about rollback if changes degrade the metrics, and what access is needed on your side.
We answer directly: performance testing is measurements and a load profile, not rewriting the product. We work on a copy of the stand or on a dedicated profile, the release branch remains untouched, and any change is first verified on an isolated build.
What if the test environment does not match production? Then the numbers will lie, so the first step is to verify the configuration: dependency versions, data schemas, network limits, and backend behavior under load.
We record discrepancies in the report — you see which metrics carry over to prod and which require re-verification.
What if the identified bottlenecks require code changes?
We provide a prioritized list with an estimate of impact on response time and load headroom, not "redo everything." Changes are made as separate modifications, each can be rolled back independently — without rolling back the entire release.
What access is needed for testing?
A test stand, an account with limited rights, and access to metric collection systems are sufficient. Production data and full administrative rights are not required — we work on anonymized datasets.
What you get in hand:
- a load profile with a description of scenarios and target values;
- a report on bottlenecks with priorities and impact estimates;
- configurations and run scripts for re-execution;
- a metrics scheme: what is captured and where, how to read the graphs;
- performance documentation with thresholds and regression rules;
- a rollback plan for each proposed change;
- a procedure for repeated runs before release.
Describe your task and current stack — we will get back to you with an estimate and work plan.
Timeline of Mobile App Performance Testing Stages
The timeline depends on how ready the app already is for load testing: whether there is a stable release, scripted scenarios, and access to builds with profiling. Below is a guideline for the implementation stages, without being tied to calendar dates. This is a work schedule for a typical project; on a call we clarify the scope and adjust.
The duration of the audit and the time to set up the stand are the most predictable parts: they almost do not depend on the code. The main variability is in the optimization stage: if there are many bottlenecks, the "fix — measure" cycle repeats, and the timeline grows. That is why we build the work schedule in iterations — after each run it is clear how much is left.
Android Studio Profiler and similar tools allow capturing profiles directly on the device, so measurements are based on real behavior rather than synthetic data.