Make your app load 10x faster with this one simple trick
How using the H2 protocol can give you the speed boost you were looking for
When you accessed this webpage from your computer, your web browser used a protocol called HTTP to access information stored on my webserver and transferred it to your computer for display.
HTTP has been around since the beginning of the Internet and, up until recently, most websites transferred information using version 1.1 of the protocol.
In 2015 a new version of the protocol was developed to increase security and efficiency, HTTP/2 (or H2 for short). It included several improvements specific to web browsers — things like server push and header compression — and it also added streams and connection reuse. And while server push isn’t very relevant for APIs, connection reuse is a big deal.
Any time a mobile app uses HTTP/1.1 to request information from a webserver it needs to setup a connection. This is actually quite time consuming, and if you’re making several requests, much of the time is spent doing this. Before each request you must negotiate encryption and then setup the connection. After each request you must tear down the connection.
H2 does not have this limitation. Instead, it provides a mechanism to send all requests over the same connection.
Similar to H2, websockets allow you to reuse a single connection, but they are limited on platforms like iOS. Long running connections like long polling or websockets are killed when an app is not running in the foreground.
If an app needs to download a lot of data on iOS it has to hand over a list of requests to the operating system — in this way the operating system will continue to perform the requests even when the app isn’t running. The app creates an `NSURLSession` and adds requests to the session. Websockets don’t work for this. But H2 does. When the server supports H2 the `NSURLSession` will open a connection and multiplex requests over the connection.
The best part about this is how client support works on iOS. If you are already using `NSURLSession` you can take advantage of H2 without any code changes. The OS will automatically reuse the connection.
The result is a considerable decrease in the average amount of time needed to service a request.
The original experiment
In order to understand how this plays out in a real app, in real conditions we built out an iOS app to use for testing. We setup two APIs for the app: one HTTP/1.1 API and one H2 API that were identical except for the protocol.
We want to call attention to the fact that the iOS code is completely identical for the two configurations. No extra work is required as long as you’re already using NSURLSession.
A simplistic model of the time it takes to make a request would be:
time = connection + server_logic + transmission • data
where the time is equal to the connection time plus the time it takes the server to perform its calculations plus a transmission speed factor times the amount of data being sent.
We wanted to observe the change in time associated with the protocol and isolate the other factors that affect the variables. We used a small, constant amount of data and calculation time to ensure that those factors didn’t come into play. We collected several runs of data under typical conditions and then averaged the results.
After completing testing on iOS we decided that we should run the same experiment for Android.
Special considerations on Android
To bring the experiment to Android we developed an app using the Square OkHttp library. Similar to iOS we set the app to connect to the two APIs: HTTP1.1/ and H2.
We started running tests and immediately realized that something suspicious was going on. Android was about two times faster than iOS at making HTTP/1.1 requests, but its performance was much poorer on H2 requests. It was clear that additional steps were needed for Android to properly leverage H2. This resulted in us performing two optimizations that Android requires when you move to H2.
First, you only get five simultaneous requests in OkHttp by default. You should bump this number to something larger. Talk to the author of your API or try it out to see what gives you the best results. For this test we increased it to 50.
Second, OkHttp’s async queue is too fast for its own good. It starts firing requests all willy-nilly before it realizes it can reuse the connection. You end up opening multiple connections to sites that support H2. To get around this we issued a single request to the site first and then waited for the response before we ran the test. This was done to mimic the real world by simulating an auth request to obtain a JWT or other token before you start using an API. By sending the initial request OkHttp knows that the server supports H2 and only a single connection is opened.
It’s not as simple as iOS, but the changes make sense and don’t feel contrived.
The Results
The data that we collected is displayed on the charts below. We ran the app through a varied number of API requests using different network technologies and then plotted the results to highlight the differences.
As one might expect, the more API requests required, the more benefit you will see from H2. If an API makes around 10 requests to get data required for an app you can expect H2 to be about 2 times faster than HTTP/1.1. If an app makes 100 requests H2 is closer to 10 times faster.
The other interesting thing you should note from the chart, is that under poor network conditions like 3G, H2 outperforms HTTP/1.1 more than in ideal network situations.
Conclusion
Moving to H2 will speed up your API.
If your iOS developers use NSURLSession then you will get this improvement without any client side code changes.
On Android, minor changes may be required depending on your API. Typically an API will require authentication before subsequent requests can be sent — which is what we modelled our Android tests after. If your setup is different, you may need to tune things on Android.
The performance gains you get from using H2 will depend on factors like the number of requests an app typically makes and the network conditions of your users. The great news is that the worse the conditions, the more H2 outperforms HTTP/1.1.
If server-side calculations and operations have already been optimized, this seems like the next best place to look for a boost of speed for an API.
Don’t believe us? Try it out
We’ve put together a small test application that allows you to try out an H2 API from your app. Check it out here. 🤖
Got another minute? You may also like:
