[Tracking] Callstack performance audit of the App

[mountiny]

Tracking issue for @adhorodyski and Callstack team performing performance audit of the app.

This is a performance audit of the Expensify app done by Callstack, following the DMAIC methodology. It will consist of 5 phases and result in a report summarising the whole audit.

In the first phase we have defined the following metrics:

• APK size in MB (App Size)
• JS bundle size in MB (App Size)
• App start time in MS (TTI)
• Report screen load time in MS (TTI)
• Sending a message in MS (TTI)
• Average FPS on LHN (FPS)
• Average FPS on Report screen load (FPS, CPU usage)
• Search screen load time in MS (TTI)

[adhorodyski]

Adam from Callstack here, I'd like to work on this.

[adhorodyski]

This is a performance audit of the Expensify app done by Callstack, following the DMAIC methodology. It will consist of 5 phases and result in a report summarising the whole audit.

In the first phase we have defined the following metrics:

• APK size in MB (App Size)
• JS bundle size in MB (App Size)
• App start time in MS (TTI)
• Report screen load time in MS (TTI)
• Sending a message in MS (TTI)
• Average FPS on LHN (FPS)
• Average FPS on Report screen load (FPS, CPU usage)
• Search screen load time in MS (TTI)

[adhorodyski]

Current status:

• @adhorodyski is working on the JS bundle size in MB metric
• @hurali97 is working on the APK size in MB metric

We've conducted the measurements (will post shortly) and are finishing up analysing them, you can expect separate comments with the findings.

[adhorodyski]

Metric: JS bundle size in MB
Phase: Measurements
Commit hash: c09a3fe

Platform	Size	Command	Artifact
Android	10.34 MB	npx react-native-bundle-visualizer@3.1.0 --platform android
iOS	10.92 MB	npx react-native-bundle-visualizer@3.1.0 --platform ios

[adhorodyski]

Metric: JS bundle size in MB
Phase: Analysis
Commit hash: c09a3fe

Below is the breakdown of our findings from the analysis process. To sum this up, if we take the associated actions the JS bundle size can be reduced by at least ~11%.

Name	Platforms	Before	After	% Impact	Notes	Actions
date-fns locale imports	All	915 KB	15 KB	8%	Locales are being imported from the date-fns/locale module using named imports. This causes unused ones to end up in the bundle.	Importing only 'en-GB' and 'es' separately from their respective paths, eg. date-fns/locale/es to only include the ones in use.
@formatjs polyfills	Native	353 KB	0 B	3%	Hermes ships Intl polyfills starting from RN 0.65 on Android and 0.70 on iOS.	For native platforms, polyfills bundled with Hermes can be used.
underscore	All	20 KB	0 B	-	Both lodash and underscore utilities are being used.	Underscore can be removed in favor of lodash.
assets/images	All	Android - 1.93 MB, iOS - 2.57 MB	-	-	High res (svg), but high size images are being used regardless the usecase.	Static assets that are not being animated can be optimised by serving in other, more optimised formats.
assets/emojis	All	425 KB	-	-	Current approach to emojis is custom made (maintenance and size cost).	Custom code can be replaced with the node-emoji dependency. A contribution to emojilib will be needed to support ‘es’ locale.

Unused / deprecated / vulnerable dependencies

Additionally, some unused/deprecated/vulnerable dependencies have been identified in the process.

Name	Notes	Actions
npm audit	49 vulnerabilities (26 moderate, 21 high, 2 critical)	Apply npm audit fix to fix vulnerabilities.
unused dependencies	-	Remove: @react-native-firebase/analytics, fbjs, save, react-native-image-pan-zoom, react-native-image-size
unused devDependencies	-	Remove: @babel/plugin-proposal-export-namespace-from, @vercel/ncc, diff-so-fancy, react-native-clean-project (replace with RN CLI clean)
metro-react-native-babel-preset	Soon to be deprecated plugin is being used.	Swap metro-react-native-babel-preset with @react-native/babel-preset before migrating to RN@0.73+.

[adhorodyski]

@mountiny Happy 2024!! 😊
Please feel free to invite anyone to the discussion here - we can now pick prioritised items from the list above to take actions right now or decide what's already taking place/can be postponed. We'd follow the same for all the metrics :)

[hurali97]

Metric: APK Size in MB
Phase: Measurement
Commit hash: 6365aeb

Measurements:

Baseline:

We gathered the following metrics on baseline ( without any improvements ) :

	APK Size MB	Download Size MB
All architectures	126.6	123

These metrics are gathered by generating a release APK using ENVFILE=.env.production ./gradlew assembleProductionRelease and then opening that APK in the APK Analyzer in Android Studio.

• All architectures means arm64-v8a, armeabi-v7a, x86_64 and x86. By default an APK has all these 4 architectures included.

If we take metrics for one architecture like arm64-v8a, here are the results:

	APK Size MB	Download Size MB
arm64-v8a	47.3	44.1

Given that, if we are able to reduce the size of the APK for all architectures, it's perceived that each architecture separately would benefit from it.

[hurali97]

Metric: APK Size in MB
Phase: Analysis
Commit hash: 6365aeb

Optimisations Round 1:

We will start with enabling the Proguard and removing any resources that aren't used in the app and in the app's library.

shrinkResources true
minifyEnabled true

Once this is done, we will measure the affect of it on the APK:

	APK Size MB	Download Size MB
All architectures	117.8	114.1

The above measurements uses the default proguard-android.txt which is generated by android build system itself.

With Optimisations Round 2:

We applied all the optimisations from previous round with one change. And that’s we used the default proguard-android-optimize.txt which is also generated by android build system but it’s different than proguard-android.txt as it has a few optimisations flags.

	APK Size MB	Download Size MB
All architectures	116.3	112.6

This is a great result, saving around 10-11 MB as compared to the results in Measurements phase, seems like magic 🪄

There are other things to consider here:

• Enabling Proguard requires extensive testing of the whole app even more when we use optimised version of Proguard.
• It seems that enabling Proguard is trivial as it's only 2-3 liner but there are a handful of issues which are already taken care of and are not stated here. But for an example, the images didn't appear in the app and the reason for that is expo-modules was being ripped off and couldn't show images. To fix that we whitelisted the whole package for Proguard. Moving forward, we will take a closer look at it and only whitelist what is essential in expo-modules package to make the app work as expected.

[roryabraham]

Importing only 'en-GB' and 'es' separately from their respective paths, eg. date-fns/locale/es to only include the ones in use

Ok, this is very interesting, since we have a best practice in place that we should do import * as MyLib from '@libs/MyLib';

When we introduced this best practice, I thought that we determined it would not have an effect on bundle size because babel would strip out the unused imports and end up only importing the named imports that are actually used in the final bundle.

If this is not true, then I'd surmise that our current best practice might actually a bad practice?

In short, I agree with the change to use default imports from the date-fns/locale sub-modules directly, but I would also like to discuss if there's a new best practice we can extract from that to help optimize our bundle size more holistically.

[roryabraham]

For native platforms, polyfills bundled with Hermes can be used

I'm all for removing any polyfills we don't need anymore. Just keep in mind all the JS engines we're exposed to – not only Hermes but also the modern browser landscape.