In an effort to connect the next five billion, Facebook began to shift to a mobile-first company about two years ago. We trained hundreds of employees on mobile development, restructured internal teams to build for all platforms, and moved to a fast-paced release cycle.
However, our mission extends far beyond building and delivering the best experience on high-end smartphones and LTE networks. We want Facebook to work for everyone – no matter the region, network condition, or mobile device.
To help accomplish this goal, a team of product managers and engineers traveled to Africa in 2013 to examine mobile performance in developing countries. We purchased several different Android handsets to test the latest version of the Facebook app – and the testing process proved to be difficult. The combination of an intermittent, low-bandwidth network connection and a lack of memory space on the devices resulted in slow load times and constant crashes. We even burned through our monthly data plans in 40 minutes.
We returned to our offices in Seattle, London, and Menlo Park determined to enhance the Facebook experience on Android – and soon made major improvements in performance, data efficiency, networking, and application size.
Performance
In terms of performance, we wanted to improve slow start times on old devices. In the beginning, we focused on instrumenting the startup path and understanding the bottlenecks. There was no silver bullet in this process – we needed to carefully identify and remove each potential bottleneck.
For example, we found that start times were slower on single-core devices because too many features concurrently initialized themselves on application startup. We made sure to defer these initializations until after startup and, in some cases, until the features are used.
We also wanted the stories in News Feed to load faster. In order to rapidly display cached content on poor networks, we now fetch stories earlier in the process to allow more time to set up connections and download News Feed. The cold start path has been automated to ensure that we prevent further regressions in these areas.
These changes reduced start times by more than 50 percent in the six months following the trip to Africa.
Data efficiency
Next, we realized that data is extremely expensive in emerging markets, and purchasing more data is often a laborious process. Thus, there needed to be a concerted effort to reduce data consumption within the Facebook app. Interacting with photos is an important part of the Facebook experience, but it takes a sizable amount of data to download them. If we could optimize the download size, we could improve data savings and perceived app performance.
First, we investigated the use of alternative compression formats for image transmission. We built tools to evaluate the impact of several different compression formats on data sizes and eventually settled on WebP. It offered both great compression performance and efficient support from Android. The use of WebP for transmitting Facebook images resulted in data savings of 25 to 35 percent compared with JPG, and 80 percent compared with PNG. This all happened without perceived impact on quality.
The next step was to work on loading images at a resolution that devices had the ability to handle. In the past, we loaded images at maximum resolution to allow for the zoom-in feature. However, on these kinds of devices this feature was used infrequently. We changed the process of loading images to only request resolutions equivalent to the size of the viewport in which the images will appear. Instead of loading a full image, the device only loads the image it needs to show (such as a thumbnail, preview, or full image at lower resolution). Of course, if someone wants to zoom-in on an image, we then download a higher resolution image.
Finally, we looked over the process used to cache and reuse images. We tested a number of potential caching strategies, as well as sizes for our caches, and fine-tuned both to minimize the evictions for images that could be accessed again.
As was the case with performance, it was important to avoid regressing our data efficiency in the future. We built automated tests and an elaborate system that can attribute data usage to individual features. This allows Facebook features to understand their data usage in production and make adjustments if it increases unexpectedly.
The work on data efficiency resulted in a 50 percent reduction in data use compared with earlier last year.
Networking
We also invested heavily in improving the efficiency and reliability of our networking stack. It was important to implement more modern networking concepts in emerging markets because our stacks struggled to perform in regions with intermittent networks.
Facebook was an early adopter of OkHttp, a networking stack open-sourced by Square, and it’s now the stack used by the Android app. OkHttp allows us to support fast retries for intermittent network situations, take advantage of the SPDY protocol for faster concurrent network transmissions, and enable powerful instrumentation across the networking stack.
After switching to OkHttp, it became a goal to decrease the number of reports regarding failed image loads in News Feed. We fine-tuned our image pre-fetching algorithms and altered the process through which we queue images for download. The process now ensures that the images expected to be downloaded next are prioritized in the queue and that no images are stuck in the queue for too long.
In combination with better data usage for images, reports of slow or failed image loads dropped by almost 90 percent over the past year.
Application size
The most popular mobile devices in Africa have little disk space available, which is a significant barrier to installing app upgrades. This means that people in developing countries often use older versions of the app that don’t have up-to-date features or take advantage of the improvements described in this blog post.
Our colleagues in the Facebook London office focused on improving app size efficiency. They approached this problem by utilizing Google Play’s ability to upload multiple APKs for different Android OSes and screen resolutions. This allows us to exclude excess code for features or resources not supported on certain mobile devices.
As with the other areas, instrumentation and testability were important to making sure we could bring the app size down. We now have tools that calculate how each feature contributes to app size and analyze device size regressions.
In the end, the app size has been reduced by 65 percent compared with the beginning of the year.
What comes next?
Our trip to Africa really highlighted the importance of our work on mobile performance, data efficiency, networking reliability, and application size for emerging markets. We’ve made a concerted effort to improve in all these areas and achieved a significant amount of success in the past year.
The lessons learned have already impacted the development of new features. We test all major features and changes in poor networking scenarios. We have automated verification for various performance and efficiency characteristics, which allows the features team to receive immediate feedback on the impact of their code. We also expanded our playbook to other apps, such as Messenger and Instagram.
We will continue to innovate to make the Facebook experience better in emerging markets, and share tools and information that can help developers build apps that work well on different handsets, network environments, and operating systems.
Thanks to Florian Laplantif, Josh Guilfoyle, Alexandru Petrescu, Ragavan Srinivasan, George Wang, Erbil Karaman, Nicola D’Eila, and all the engineers and product managers in the Seattle, London, and Menlo Park offices who helped improve mobile quality on Facebook for Android.
