App performance: Core concepts

In order to make apps run faster, you need to first understand some core concepts.

Ideally, the users of an app should never need to wait for the app to sync data or react to inputs. A well-tuned AppSheet app can come close to achieving this ideal.

AppSheet apps run on a mobile device or browser. All the table data used in the app is maintained in a local copy on the device/browser. This local copy allows the app to be interactive, responsive, and run offline. The platform needs to ensure that this local data copy stays in Sync with the true source of the data which is in a cloud data provider (like Google Drive or Office365 or SQLServer). 

Latency versus throughput

When we refer to the performance of the app, we typically mean the responsiveness of the app as perceived by the end users of the app. The term latency means time spent waiting. App responsiveness is directly related to perceived latency. Our goal is to minimize latency perceived by end-users.

As you understand how AppSheet apps work, you'll see that there are different systems communicating with each other. Each communication involves the transfer of data between the systems. In this context, latency refers to the time a system takes to initially respond to a request. The term throughput refers to the amount of data that can be transferred per second. So for example, to fetch a spreadsheet from Google Drive, the overall latency is the sum of the initial latency to respond to the request and then the time taken to make the actual data transfer. 

How does Sync work?

The AppSheet app cannot directly connect to the cloud data provider. Instead, it communicates to the AppSheet backend service (the AppSheet server in the figure below) which then acts as an intermediary to communicate with the cloud provider. This tiering is necessary for the sake of security but also has performance benefits. 

Initially, let's consider the case of Sync in a read-only app. This behavior also occurs during initial launch of any app and in any app that has the Sync-On-Start option enabled.

  • Read Step 1: When the app on the mobile device starts a sync, it requests data from the AppSheet Server. The AppSheet Server in turn requests data from the Cloud Provider. 
  • Read Step 2: Once the AppSheet Server receives the data from the Cloud Provider, it computes any virtual columns defined and then returns the data to the app on the mobile device. The app stores the data on the mobile device. 

Note that in step 1, the AppSheet Server may have to fetch many tables from the same or different Cloud Providers. In step 2, all the data is sent together to the app. Later, we will discuss various optimizations that can reduce the data transferred and the time taken in these steps.

Now let's consider the case of an app that has made some data changes (to its local data copy) and is then invoking Sync. The app first sends each of the data updates in order to the AppSheet Server (steps 3 and 4 in the figure) and after that, it performs a read-only sync. 

  • Write Step 3: the app sends each of the added, updated, and deleted data rows to the AppSheet Server. If you captured photos, drawings, or signatures, they are sent along with the data rows.
  • Write Step 4: When the AppSheet Server receives this information, it writes the data back to the Cloud Provider. If there are any automations defined, they are also run (these will typically require that the updated rows be re-read from the Cloud Provider before executing the action).

How to improve read-only Sync performance

Conceptually, there are six ways to improve Sync performance:

  1. Choose an efficient data provider
  2. Reduce the amount of data transferred during Sync
  3. Reduce the amount of computation (for spreadsheet formulas and virtual columns) performed during Sync
  4. Fetch or compute data in parallel (relevant if there are many tables in the app or many expensive virtual columns)
  5. Use a fast network (this is relevant for the connection between the device and the AppSheet Server)
  6. Make Sync happen in the background so that the user does not need to wait for them to complete

See Improve the speed of Sync. As an app creator, you have many options to control these aspects of Sync performance.

How to improve Sync performance when there are data updates

Data captured or updated by the app on a device needs to be sent to the cloud provider backend. This can be one of the slowest aspects of the Sync process because the changes have to be made sequentially (to ensure correctness). Conceptually, there are four ways to improve this aspect of Sync performance:

  1. Reduce the number of updates
  2. Reduce the amount of data sent with each update (for example, images captured per row)
  3. Reduce the amount of computation (for example, automations) that must happen with each update
  4. Apply these changes in the background so that the user does not need to wait for them to complete

See Improve the speed of Sync with data updates. As an app creator, you have many options to control these aspects of Sync performance.

Improving app responsiveness after Sync

While we focus most of our attention on Sync, it is also useful to be aware of factors that can affect the interactivity and responsiveness of the app itself on a device. If the data set is very large, it can consume a lot of device memory which leads to slow rendering of UI. Likewise, if there are expensive format rules, there can be a lot of computation needed each time a screen is scrolled and this affects interactivity. 


Was this helpful?
How can we improve it?
Clear search
Close search
Google apps
Main menu
Search Help Center