Making your meteor app fly part-1: Meteor app size optimization(A journey of reducing the size of the bundle by 50%)
We have been developing Fasal app in meteor from past 2 years, and though we had always kept an active watch on the size of the app, by every new release it was getting slightly bigger.
In a recent expo which happened in the outskirts of Pune, where Fasal participated, we realised that the increased size of the app has started affecting user acquisition. We serve farmers and the network connection at the farms are not very good. And for us as a company this is something which is not at all acceptable. So we decided to trim the size of our application to bring it down to less than 5 mb. And here’s journey of achieving that goal.
For solving any problem 1st you have to identify root cause of the problem :)
So we started digging which resources are making the app size bigger.
For meteor project you can use bundle visualizer. Once you visualise you can checkout which are the component occupying higher space.
For running bundle-visualizer run following command:
meteor --extra-packages bundle-visualizer --production --settings settinngs.jsonOnce the build has finished and your application is running you will see something like this one you app:
Once you have information of the packages you can start evaluation on the base:
1. Unused packages and code in the application
Sometimes being a developer is hard. You have to make sure application is up and running and healthy all the time and also backward compatible. For that we avoid removing unused packages from the application and some times even old code files or code portion. It will also increase maintainability and readability as unwanted code is gone.
But at some point one must take the courage to figure out and remove unused codes, one block at a time. Once you have removed them test it out in a suitable environment (Regression testing and smoke testing is must once you have done changes).
If you are not using lazy loading feature of meteor, make sure you start following folder structure they have suggested. It will surely improve your client bundle size as some files will be imported only once they are needed.
2. Packages which are not being used in client side and still included in client bundle.
I have found out that we were using some packages which are included in both server and client bundle but actually required on server side only.
For example, we were using aws-sdk from the atmosphere(Meteor Package registry) and after visualization we came to know that it’s being shipped along with client code (I have raised a PR to make it lazy load which eventually solved the issue).
If you have same issue you can refer meteor lazy loading package feature which can make it lazy load on client (only includes if you have required it on client).
3. Some libraries are included but in project you are using only portion of the library.
Sometime you don’t need the whole code of the third party package or library. Even if you are using only tiny portion of the package it’s still included in bundle.
Let’s take an example, For charting we are using echarts.
It has support of multiple chart types and features so if you add it as a dependency it will have some unused code(Which you don’t want to include it in client bundle). In such case you have two options.
- Custom build of the package or library.
- Fork the project trim it down and maintain private registry to use.
In option one if your package has custom build support, you can go for it and download only portion of it which you actually need for the application(this needs to be documented as if you want to add more feature you will need to know about the previous build to make sure it includes already used features).
In second option you will be managing separate package or library for private use in your private registry. This will require additional management of the project and sync from original one if there’s new release in original one(keeping forked project upto date).
Trust me if you follow the process it will increase development complexity but surely you will be getting huge size difference here.
Once you are done with code and packages next you have static file like images, fonts, etc.
4. Alternate for some packages.
For us we saw that we have included font awesome at start of the project as we didn’t wanted to design our own icon set. But at this point in time it was consuming almost 900 kb of bundle files. Which would be almost 25% of our project(after optimization). So we asked ourselves that do we really need it or we can find alternate of the package. We end up using glyphicon instead of font-awesome as it was already part of the project at the time (there were other options as well like http://fontello.com/ and https://icomoon.io/ etc which provide smaller package size by giving you flexibility to include only selected icons. but you do need to maintain it so it’s up to your choice).
So if you feel that tread of between size and usability is really huge try to find out alternate ways how can you achieve it by not affecting the end goal. If you feel you need something which is not available in market feel free to contribute to the community :)
Image optimization for the project
Your public folder files directly gets bundled up while building client bundle.
So make sure that you have only static file like fonts and images and other resource in public folder of the project. If you have any unused resource make sure you remove it.
If you are using images, make sure you have compressed it and the size is minimal(this can bring down app size around 10–15% if you have really big size images).
Once you have taken care of public folder you should also check res folder:
Follow the same process for all the files in same because most of the times we ignore such resource and forget to optimise them.
For android application you can distribute Android application bundle instead of APK.
I have written separate blog for the process to follow for the same.
If you use app bundle, you will be able to reduce size of the app by at-least 1 mb more.
Hurray!!!
Above techniques should take care - most of the app size optimization of any meteor project. If you have any another idea or suggestions do let me know \m/.
Also read—
