An enjoyable and efficient app depends not only on function but also on speed.  This study explores the performance of the Driver Training App on different traditional and mobile network types.

Technology Background

Like most apps, the Driver Training App’s code is loaded to the mobile device (computer, tablet or phone) once when initially installed or initially loaded in a browser.  Once code is distributed to the device, network activity is limited to two-way operational data and imagery.

The result is that once you’ve loaded the app on your device, the main indicator of app speed is the duration of (a) the transit of data to and from your device and the server, and (b) the time the server takes to process the data.

Test Methodology

Our experiment consisted of a real-world style series of app operations run on fibre optic, 5G and LTE networks.  Particularly, we focused on the 3 most common interactions an instructor would perform on a mobile device while away from a traditional wired or wireless office internet: view a calendar with 10 events, view the details of one event, and submit time entries for an event.

LTE test was performed with full network reception on an iPhone.

5G test was performed in a controlled Encqor 5G testbed at Communitech.

Hard wired test was performed at a home office.

See below Speedtest results of each network at the time of testing for reference.

Download (Mbps)Upload (Mbps)Latency (ms)
Hard Wired125.611.912.0

Figure 1 • Speed Test Results

Test Results

The table below illustrates the breakdown of the average speed of standard mobile API requests by transit and wait times. 

TotalTransitWaitTransit % of Total
LTE509.9 ms63.4 ms446.5 ms12.44%
5G192.6 ms1.5 ms191.1 ms0.79%
Hard Wired294.0 ms1.2 ms292.9 ms0.40%

Figure 2 • Test Results: Average duration of an API request


We were surprised that the variance of wait times across different tests resulted in a far greater effect on total time than transit times.  Given the correlation between a network’s download speed (see figure 1) and wait time (see figure 2) we hypothesize that network speed may somehow be impacting wait times as well as transit times.  This requires further study.

That aside, we found 3 outcomes important: 

  1. For transit time 5G performed 28% slower than hard wired and 98% faster than LTE.
  2. For total time: 5G performed 34% faster than hard wired and 62% faster than LTE.  
  3. All 3 networks performed at or under 0.5 seconds.

Finally, we questioned whether 5G lab results at the Communitech testbed were representative of what a real-world user would experience.  Given the variance of 5G network hardware, protocols, proximity and obstructions we expect that real-world testing may result in lower speeds for app users.


Variation between different instances of the same API request and the server’s time to process that request appears to impact the overall time as what we measured as transit time.  This points to a need to further understand and optimize non-transit API efficiency.

5G offered substantial overall and transit time improvements over LTE, and exceeded on some measures that of our hard-wired environment.  This is promising for app users who may expect the same experience both in office and on the road.

Overall, the app appears to perform satisfactorily on all 3 networks.  We expect that suboptimal network access will be the primary issue for mobile app usage regardless of mobile network.  As a result, we anticipate the need to create an “offline mode” that allows for the queuing of data when a request fails.