Perf Feedback - What's slowing down Mobile Facebook

Hi,

Following the recent announcements[1] we (Facebook) made about rebuilding
our iOS app using more native technology, we have had a lot of requests to
provide detailed feedback on the performance issues we encountered while
building for the mobile Web. Here it is. Comments welcomed.

1. Tooling / Developer APIs
---------------------------

The lack of tooling in mobile browsers makes it very difficult to dig down
and find out what the real issues are. Hence tooling, or rather,
lack-thereof is a key issue.

The biggest issues we've been facing here are memory related. Given the
size of our content, it's not uncommon for our application to exhaust the
hardware capabilities of the device, causing crashes. Unfortunately, it's
difficult for us to understand exactly what's causing these issues. GPU
buffer exhaustion? Reaching resource limits? Something else? hard to say.

### What's missing? ###

Mainly, dev tools on the device and/or easily accessible remotely.

Things we'd want to know more about as we develop:

#### Down memory lane ####

- Heap size,
- Object count,
- GC cycles,
- GPU buffer size,
- resource limits.

Some of those are very much useful outside of the development phase,
however. E.g.: Linkedin uses UA string sniffing[2] to determine how many
pictures can be kept in memory before hitting the device's limit, an API
to the device's memory resource would be a much more appropriate (albeit
finger-printable) way of doing that.

#### FPS ####

- The ability to measure fps at the hardware level. This is essential for
testing[3], but would also be very useful to determine whether to use
infinite scrolling or pagination, for example. Same fingerprinting caveat
as above.


2. Scrolling performance
------------------------
I've already started sharing some of it with the W3C WebPerf WG[4]. Will
continue bringing it to other relevant WG in the upcoming weeks.

This is one of our most important issues. It's typically a problem on the
newsfeed and on Timeline which use infinite scrolling (content is
prefetched as the user scrolls down the app and appended) and end up
containing large amounts of content (both text AND images). Currently, we
do all of the scrolling using JS, as other options were not fast enough
(because of implementation issues).

### QoI Issues

- Inconsistent framerates, UI thread lag (stuttering).
- GPU buffer exhaustion due to size of content and number of images.
- Native momentum scrolling has a different feel across operating systems.
JS implementation end up being tailored for one OS and feels wrong on
other ones (uncanny valley).
- Perf issue with touch events on Android devices (latency, not enough
events) which makes JS implementations of scrolling more brittle there.

### Requirements:

- Scrolling must be fast and smooth (this is really important for
engagement).
- It must trigger a given set of events so content can be prefetched,
computed and appended as the user scrolls towards the bottom of the loaded
content.
- It must allow i/o and computation in the background (without affecting
the smoothness).
- It must allow appending fresh content to the main content while
scrolling (again, without affecting the smoothness).
- It must reliably handle scrolling though a lot of content, including
lots of images.
- It must be possible to capture touch events during scrolling.

### new API suggestions:

- A standardized way to enable momentum scrolling across browsers.
- `onscroll` events triggered *during* scrolling.
- Structured cloning of rootless document fragments (for building doc
fragments in workers and moving them back to the main thread to be
appended).
- Simple way to implement pull to refresh (via dedicated off-bound-scroll
events?). 


3. GPU
------

Currently, the GPU is a black-box (which from what I understand is what
vendors would like to keep it as). In truth however, developers rely on
tricks[5] to force given content to be hardware accelerated. So it
basically a black-box with a clunky API to add things to it. Given the
size of GPU buffers relative to the size of content consumed on devices
nowadays, I doubt well get to a place where managing GPU can be left
strictly to the browser in a reasonable amount of time.

Think there's value in at least discussing the pros and cons of providing
some form of API to the GPU, if that's possible at all.


4. Other
--------

- Better touch tracking support, especially on Android.
- Smoother animations are always an asset.
- Better caching.
- AppCache is soooooo busted we stopped using it[6].

Best,

--tobie

---
[1]: 
https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuildi
ng-facebook-for-ios/10151036091753920
[2]: 
http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-
scrolling-html5
[3]: http://lists.w3.org/Archives/Public/public-coremob/2012Aug/0014.html
[4]: http://www.w3.org/2012/09/12-webperf-minutes.html
[5]: http://davidwalsh.name/translate3d
[6]: https://etherpad.mozilla.org/appcache-london

Received on Saturday, 15 September 2012 07:41:31 UTC