Managing Application Size as it Relates to Performance

Managing Application Size as it Relates to Performance

Application performance is hugely important to providing your users with an acceptable user experience. Many app builders only discover their apps are non-performant after users report issues, but ideally a system should be thoroughly tested before launch to ensure it can handle the anticipated load and scale.

What Affects App Performance?

Performance is determined by several interconnected factors. Because of this, different applications will tolerate different caseloads on different devices, which is why it's imperative that any project conduct performance testing of their own application on their own devices before launching.

Application Performance is determined by several factors, including

  • Case Load (Number of Cases)

  • Case Size and Properties

  • App Complexity

  • The hardware (specifically amount of internal storage and RAM/ processor speed)

Because of this, different applications will be able to tolerate different caseloads of different devices. That is why it is imperative that any project conduct performance testing of their own application on their own devices before launching a project.

1. Case Load (Number of Cases)

This refers to the number of cases a mobile worker's device is syncing and storing locally.

Why it matters: The more cases a user has on their phone, the more time it takes to sync, open case lists, and load forms that reference those cases. The sync time with the server is affected by the total number of cases on the phone, making the first sync slower (though subsequent syncs will be faster and less likely to time out).

What to watch for: If users are syncing more than several hundred cases at a time, performance may start to decline. In our experience:

  • Technically feasible: 10,000 cases

  • Best practice: 1,000 cases

A rough rule of thumb is that every 25 cases will add approximately one additional second to the sync process.

2. Case Size and Properties

Case size refers to the amount of data and metadata associated with a particular case within the application. Each case stores a set of properties (like name, age, visit_date, etc.).

What contributes to case size:

  • Number of Case Properties: More properties mean larger case size

  • Data Types (e.g., text, integers, dates, multimedia): For example, text fields typically consume more space than integer fields.

  • Case History: CommCare tracks changes to case properties over time. A detailed case history with many updates can increase the overall size of the case.

  • Case Relationships: Parent-child relationships add metadata to cases

  • Multimedia Attachments: Images, audio recordings, and other files significantly increase case size

  • Form Submissions: The number and complexity of linked form submissions affect case size

Why it matters: More properties mean more data the app has to process every time a form loads or a case is updated.

What to watch for: After about 500 case properties, you're definitely at risk of mobile performance issues. Keep case structures lean (20–50 properties, maximum of 100 core properties) to help reduce load times. Remember that high numbers of case properties also slow down other parts of CommCareHQ like data exports, data dictionary, and the form builder.

3. App Complexity

CommCare allows for incredibly complex apps employing multiple data types, advanced functions, repeat groups, lookup tables, and more. This complexity includes:

  • Number of modules and forms

  • Number of questions per form

  • Logic like display conditions, validation conditions, and complex calculations

  • References to lookup tables, organizational hierarchy, or the case database

  • Extensive use of repeat groups (particularly if nested within each other)

  • Use of heavy multimedia like large videos or images

Why it matters: The more complex the app, the more work the phone has to do to evaluate logic and render forms. Complex apps can result in redundancies, complex hierarchies, and an increase in the number of data fields that need to be stored.

What to watch for: Around 500 questions per form is where risk of issues exists due to the variety of question types available and complexity of calculations. However, it's also important to consider what healthcare workers and clients can handle—many projects report that users cannot handle more than 100-200 questions in a form at once, meaning you'll likely hit human capacity issues before technical ones.

4. Hardware and Device Type

This refers to the mobile device being used—its processing power, memory (RAM), internal storage, and processor speed.

Device considerations:

  • Internet speed affects syncing

  • Device speed and memory impact overall performance

  • Web Apps vs Mobile: Web Apps may sync faster due to more continuous syncing (vs syncing everything at once) and typically run on devices with better specifications

Why it matters: Older or lower-end phones may struggle with apps that run smoothly on newer devices. Limited RAM can especially affect form loading times and increase crash likelihood.

What to watch for: Test your app on the same devices your field team uses. If performance is poor, consider devices with more internal storage and higher RAM.

 

Common Performance Questions

How many Cases are too many?

As discussed above, this depends on all the factors mentioned, but generally:

  • Technically feasible: 10,000 cases

  • Best practice: 1,000 cases

The only way to be certain is to test your specific app on your devices at the anticipated load.

How many Case Properties can I save?

There's no definitive answer due to application variety, but after about 250 properties you're at risk of performance issues. If your app is complex, even 250 may be too many. More information here is available on limits.

How many questions can I have in my Form?

Again, no definitive answer exists due to varying question types and calculation complexity. 1000 questions is where risk exists, but consider user capacity as well.

 

Introducing Speedy

Hi there! I’m Speedy, a performance-minded koala here to help you build CommCare apps that run smoothly and efficiently in the field.

While most koalas spend their days napping in trees, I’ve got a different kind of mission: spotting slow logic, heavy case loads, and anything else that might slow down your mobile app. Whenever you see me, I’ll be sharing tips, reminders, and best practices to keep your app running at top speed — no matter where it’s used.

Check out my best practices for enhancing mobile performance below.

Best Practices for Optimal Performance

Reduce Case Load:

  • Archive or close old cases—only open cases sync to the app

  • Organize cases so users can sync all needed cases before their next sync

Optimize Case Properties:

  • Only save data necessary for case identification or follow-up forms as case properties. More information here is available on limits

  • All collected data will be in your forms regardless

  • Avoid updating case properties if the form doesn't change existing values—this keeps case history concise

Manage Multimedia Wisely:

  • Upload small multimedia files

  • Adjust device camera settings to take smaller photos (<1 MB)

Streamline App Structure:

  • Carefully review your app to ensure efficient data gathering without redundancies

  • Try using question groups rather than lists

  • Wrap queries in if statements so calculations only run when needed

  • Take advantage of multiple follow-up forms rather than creating overly long single forms

Test Thoroughly:

  • Test your specific scenario using cases created with the Excel importer tool

  • Test on the actual devices your field team will use

  • Test at anticipated load levels before launch

How to Test Performance

We recommend testing your particular scenario with cases created using the Excel importer tool. This allows you to simulate real-world conditions and identify potential issues before deployment.

If you have a CommCare Pro Plan or above you can also use load testing. This feature allows you to load test the size of your CommCare application by multiplying a test user’s cases by a load test factor you can specify. When the mobile worker syncs, each case in the payload will have that many copies. So if the loadtest factor is set to 20, and the mobile worker has 5 cases, then a total of 100 cases will be sent to their device.

Whether you're building a new application or managing one already in use, keeping performance in mind can make a big difference for your field teams and the people they serve. Regular testing and optimization ensure your CommCare app continues to provide a smooth, reliable experience for all users.