Tips to improve your application performance
Since speed is now used as a ranking factor for mobile searches I want to talk about how you can improve your product in order to get the highest ranking on Google Search possible. When real users have a slow experience on mobile, they’re much less likely to find what they are looking for or purchase from you in the future. For many sites this equates to a huge missed opportunity, especially when more than half of visits are abandoned if a mobile page takes over 3 seconds to load. In order to improve your website performance here are some tips that can give you an advantage amongst your opponents on www. This tips can apply to any programming language, both mobile or web application, or even desktop application:
1. Use optimistic queries
What does that mean? That means if your user is about to click a button and expecting some sort of a result, that request is going to a server whose response will affect some changes in user experience, change that based on optimism that the server will respond with the correct result. An example is on Instagram where if you click on the like button, what they will do is actually like and animate that button as if the action was completed successfully despite that server might not process that request properly. You can actually try that and turn off your network and you can see that they will undo that effect after a few seconds. So this is actually a good idea, optimistic queries. Change the user experience, send that request asynchronously and just move on, and if there is something on the server matching your state you are good, otherwise, but that is rare, you can adjust.
The idea of paging. Especially if you are listing pictures, comments and other things you need to do paging. You cannot do ‘SELECT * FROM TABLE’ and you have an unbound query which means there is no ‘WHERE’ clause. First it kills your database and this request responds with a huge payload. You cannot even show millions of results in your application, so what you do is when you open your app you will pull the first 10 of your pages and as you scroll down you will make another request to get the next 10 pages and so on. This way you reduce the load on the backend and also on the same time you have very few things to work with on frontend, plus as a human being we cannot really look at hundred pictures at the same time.
3. Lazy loading
Another popular property of performance of the application, and this goes a little bit with paging. If you are scrolling through an application, you want to display only pictures that are in your current viewport. You need to be pragmatic and don’t load the next 10 pictures. You already have the entire page with all the pictures, but you don’t want to load them because that will be a waste of memory, a waste of CPU resources. So, you display only what your user can see at the actual moment, maybe one step ahead.
4. Request what you need
Popular example is using GraphQL as a query language. So if you are populating for example a comment section on Instagram then what you need to do is only you request for actual text, user and you need how many times this comment has been liked and maybe a date. So you don’t request for example the followers for that user, it’s useless right? So these are obvious things, but if you design your user experience first, you will know that you design your backend based on what your frontend looks like. GraphQL is really nice for this application. It will simplify what you need and unlike REST API where you need to get everything right because REST API is kind of old. The worst thing you can do is ‘SELECT * FROM TABLE’ because if you are selecting certain fields from a table, make sure these fields are indexed, especially if you are selecting those fields frequently. So select only the things that are optimized by your query execution plan and your database provider.
5. Have a connection state
That means if you lose your internet connection, have information stored in your app so that you don’t waste resources to issue requests when you know that they will fail. Youtube does a great job for that, if I lose a connection I get this banner which says that I lost it, so anything I do I don’t see any requests triggering at all. However I can see all the thumbnails and titles that are preloaded.
6. Use LRU cache
Least Recently Used cache will prove very useful if you have a huge payload that comes from your REST API, or GraphQL endpoint, or gRPC endpoint and that have a lot content to show and user start scrolling all the way down and you load all this content in memory you will very quickly run out of RAM. What you need you need to do is to use is some kind of LRU cache so that as you starting loading stuff add them to the cache and as they are getting older just remove them from the cache in order to keep your memory.
7. Use HTTP/2 when applicable
That’s the most powerful thing if your client library programming language supports it. Multiplexing multiple requests in this case will have HTTP/2 have this single beautiful TCP connection between you and the server and you will start sending these requests in parallel as different streams instead of having multiple TCP connections. So if you are using gRPC you are covered, gRPC will take care of all that stuff for you because it is using HTTP/2 and will take care of all the streaming and requests and it does all of that for you. Again, use this if applicable, because sometimes your client is using Java HTTP client which does not support HTTP/2
8. Group notifications
If your application supports notifications at all, try to group these notifications as much as possible before throwing them at the user. Instagram is a perfect example for this. When you open Instagram you will see 128 people liked your picture and you have 28 comments. It is always better to group these informations and then ship them once instead of bothering the user and consuming these extra resources.
9. Avoid expensive queries
To give you an example, go to Twitter, Instagram or YouTube, there you cannot find a tool or a way that allows you to batch unfollow people, it doesn’t exist. The reason is that they don’t want people to just massively unfollow other people. Second is for performance reasons, because if you start having a tool to select multiple checkboxes and select them all to unfollow or follow people, first of all it is spammy, second of all that REST endpoint or that GraphQL endpoint will take a huge amount of processing power. What Instagram has is actually a really bad user experience, they have literally buttons that say follow, follow, follow, you have to click all of them. For them it’s actually easier to handle then if a flood of requests tell them to follow these 100 people simultaneously.
10. Minimize requests
Try to build your user experience so that you have the minimum number of requests to the server possible. So that if you open an application if you can group requests together and send one request, do that. But if that is not possible, you have to send multiple requests because one request will depend of the response of another request and you don’t have an option but always aim to minimize the number of requests.