Engineering & performance / DIJION
Measuring loading: from the first frame to usable content
A mobile measurement record separating startup, data and interaction milestones for comparisons under consistent conditions.
A visible logo does not mean someone can begin their task. A list may be drawn while its content or response to touch is not ready. Evaluate loading with separate milestones for the first useful frame, required information and a working action.
Define the timeline
Android’s startup guidance distinguishes initial display from full usability. In a product flow, you can additionally define when the data needed for the task becomes available. Do not substitute an automatically reported metric for task duration when their definitions differ.
Scroll the table horizontally to see all columns.
| Field | Definition to record |
|---|---|
| Starting condition | Cold start, return from background or screen transition |
| First display | When the first useful screen appears |
| Required content | When the task data becomes available |
| Action ready | When the primary action responds correctly |
| Conditions | Device, build, connection, cache and power state |
Compare like with like
Comparing a warm cache with a clean installation does not isolate a code change. Record the device, network and amount of data. Other heavy tests running during measurement can also affect results. Do not treat one successful run as representative of every experience.
Make the indicator reflect the work
Avoid a precise percentage when it does not represent real progress. A skeleton can preserve the content layout, but the action state still needs to be understandable if the screen appears ready. Check whether repeated taps during loading generate additional requests.
Distinguish waiting from failure
A disconnected request should not leave a spinner running indefinitely. Define the conditions for failure and retry alongside the actual request behavior. If partial content remains usable, consider explaining freshness and missing information rather than hiding everything. Do not automatically initiate another submission while the first outcome is uncertain.
Run a focused improvement experiment
- Write down the start and end events of the slow task.
- Record several starts under comparable conditions.
- Change one bottleneck, such as deferring an image unnecessary for the initial screen.
- Check timing, failure handling and correct interaction again in the same task.
State which conditions were not measured alongside the report. This article provides neither a benchmark nor speed results for a Dijion product. It proposes a way to make the measurement definition clear before collecting results.