Skip to main content
A performance report compares your pull request build (head) with the build it merges into (base), on the same real phone. Both builds run app startup and your flows many times each, in random order, so the result is a measured difference rather than one lucky or unlucky run.

Prepare builds for performance testing

Set up your iOS and Android CI so the report can name the functions that got slower.

​
What a report answers

  1. Did the check pass?
  2. Which metrics moved, and was it your code or the network?
  3. For the metric you care about: is the change real, how big is it, and where did the time go?
  4. What should you hand your coding agent to fix it?

​
Your code or the network

Every metric runs twice:
  • Mocked network. Responses recorded from the base build are replayed, so only the app code differs between the two builds. This is the precise measurement.
  • Live network. The app talks to your backend, which is what your users wait for.
Base and head share the backend at the same time, so backend drift cancels out. Comparing the two modes tells you where a change comes from:

​
Verdicts

Each metric gets the median of each build, the change in milliseconds and percent, and a 95% interval for that change. A change counts when it is at least 5% of the base median or 20 ms, whichever is larger. “No change” is a claim backed by the data, not the absence of a result.

​
What you see depends on what you upload

See Prepare builds for performance testing for the setup.

​
Reading a report

  • Counts at the top: how many metrics regressed, improved, stayed the same or are inconclusive, and one sentence on the check.
  • Comparison table, worst first: mocked and live side by side, each with the change, its interval against the threshold, and base and head medians.
  • Detail for one metric: every iteration of both builds, the run order to spot drift, main-thread changes from the trace, and the network requests that changed.

​
Hand it to your coding agent

Each report comes with a pull request comment in Markdown and a JSON export (mobileboost-perf/v1). Copy either into your coding agent, and it gets the regressions, their cause and the slower functions in one place.

​
Also in every functional run

  • Test runtime. Each test reports the time it spent on a device, and each run reports its wall-clock time. GET /runs/{runId} returns both as runtimeSeconds.
  • Crashes. Run reports show app crashes that happened during a test.